BUG: Select() Fails to Block on a Blocking Socket (177346)
The information in this article applies to:
- Microsoft Win32 Application Programming Interface (API), when used with:
This article was previously published under Q177346 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.
Modification Type: | Major | Last Reviewed: | 10/29/2003 |
---|
Keywords: | kbAPI kbBug kbnetwork kbWinsock KB177346 |
---|
|