Help and Support

Article ID: 177346 - Last Review: November 21, 2006 - Revision: 2.1

BUG: Select() Fails to Block on a Blocking Socket

This article was previously published under Q177346
Expand all | Collapse all

SYMPTOMS

The Winsock select() API might fail to block on a nonblocking socket and return WSAEWOULDBLOCK as an error code when either send() or recv() is subsequently called. For example, select() may return indicating there is data to read, yet a call to recv() returns with the error code WSAEWOULDBLOCK, indicating there is no data immediately available. Windows NT 4.0 does not exhibit this behavior.

RESOLUTION

You can any of the following techniques to work around this problem on Windows 95:
  • The simplest workaround is to explicitly ignore the WSAEWOULDBLOCK error code and simply call recv() again after waiting a small amount of time (this would be polling).
  • Use WSAAsyncSelect() instead of select(). This API allows asynchronous notification of socket activity by delivering a Windows message associated with the socket.
  • Use WSAEventSelect() instead of select() (only if Winsock2 for Windows 95 is installed). This API allows asynchronous notification of socket activity by signaling the event associated with the socket.

STATUS

Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this bug and will post new information here in the Microsoft Knowledge Base as it becomes available.

APPLIES TO
  • Microsoft Win32 Application Programming Interface, when used with:
    • Microsoft Windows 95
Keywords: 
kbapi kbbug kbnetwork kbwinsock KB177346
Retired KB ArticleRetired KB Content Disclaimer
This article was written about products for which Microsoft no longer offers support. Therefore, this article is offered "as is" and will no longer be updated.

Article Translations