- /* Check any pending events. This both avoids starting the thread
- unnecessarily, and handles stray FD_READ events (see below). */
- if (WaitForSingleObject (state->sock_event, 0) == WAIT_OBJECT_0)
- {
- WSANETWORKEVENTS events;
- int any = 0;
-
- /* Enumerate the internal network events, and reset the object that
- signalled us to catch the next event. */
- WSAEnumNetworkEvents (scb->fd, state->sock_event, &events);
-
- /* You'd think that FD_READ or FD_CLOSE would be set here. But,
- sometimes, neither is. I suspect that the FD_READ is set and
- the corresponding event signalled while recv is running, and
- the FD_READ is then lowered when recv consumes all the data,
- but there's no way to un-signal the event. This isn't a
- problem for the call in net_select_thread, since any new
- events after this point will not have been drained by recv.
- It just means that we can't have the obvious assert here. */
-
- /* If there is a read event, it might be still valid, or it might
- not be - it may have been signalled before we last called
- recv. Double-check that there is data. */
- if (events.lNetworkEvents & FD_READ)
- {
- unsigned long available;
-
- if (ioctlsocket (scb->fd, FIONREAD, &available) == 0
- && available > 0)
- {
- SetEvent (state->base.read_event);
- any = 1;
- }
- else
- /* Oops, no data. This call to recv will cause future
- data to retrigger the event, e.g. while we are
- in net_select_thread. */
- recv (scb->fd, NULL, 0, 0);
- }
-
- /* If there's a close event, then record it - it is obviously
- still valid, and it will not be resignalled. */
- if (events.lNetworkEvents & FD_CLOSE)
- {
- SetEvent (state->base.except_event);
- any = 1;
- }
-
- /* If we set either handle, there's no need to wake the thread. */
- if (any)
- return;
- }
-
- start_select_thread (&state->base);