Daniel Stenberg wrote:

>> If the following can happen, there is a problem:
>>
>> 1) connect
>> 2) socket_callback ( write )
>> *connect happens asynchronously*
>> ::WSAEventSelect -> too late
>> 3) ::WaitForMultipleObjects -> this should wait until the
>> "write/connect" event has happened, but the event was triggered before
>> ::WSAEventSelect
>
> This is what happens. libcurl will tell you the state of the socket that
> it already has and what ready-state it wants in the socket (recv and/or
> send). It never sets a "mode" that it is about to change to before it
> has actually happened.
>

I've tested following scenario:

::WSAConnect (non-blocking socket)
sleep 10000 * socket connect happens here *
::WSACreateEvent
::WSAEventSelect ( sock, handle, FD_CONNECT )
::WaitForMultipleObjects -> immediately returns because of FD_CONNECT
event happened

So it seems that we can set WSAEventSelect after the socket connect
happened.

There was a misinterpretation of following phrase
(http://msdn2.microsoft.com/en-us/library/ms741576(VS.85).aspx):

<< Issuing a WSAEventSelect for a socket cancels any previous
WSAAsyncSelect or WSAEventSelect for the same socket and clears the
internal network event record. For example, to associate an event object
with both reading and writing network events, the application must call
WSAEventSelect with both FD_READ and FD_WRITE, as follows... >>

So we thought that setting WSAEventSelect cleared the events that
already happened. But it actually only means that the previous set
flags (FD_CONNECT/FD_WRITE/FD_READ/FD_CLOSE) are overwritten.

The problem seems to be in our code and the way we're keeping track of
the socket events.
Received on 2008-03-13