On Tue, 11 Mar 2008, Raf Nulens wrote:

>> But what kind of event layer is this? libcurl said it wants to write on
>> this socket so it wants to be called when the socket is writable. How come
>> your event layer doesn't tell you the socket is writable if it is?
>
> We're using winsock2.

Do you happen to know if there's any good docs online on how the event-driven
winsock2 API works?

> Problem is that we seem to set our read/write event flags too late.

So it is entirely edge-trigged and no chance for level-trigged? It just seems
so weird!

> 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.

> This is wat we want to happen:
>
> 1) socket_callback ( write )
> ::WSAEventSelect
> 2) connect
> *connect happens asynchronously*
> 3) ::WaitForMultipleObjects -> this should wait until the "write/connect"
> event happens

This would require the code to work quite differently than it does today...
And quite frankly, it doesn't make sense to me.

If the socket_callback and connect happened in the same call to
curl_multi_socket(), there would be no difference to you as when the function
returns you need to wait for that activity on the said socket. Or are you
running that event system in a separate thread?

If it would report socket_callback(write) and do the connect in two separate
curl_multi_socket() invokes, then the first socket callback would be a blatant
lie...

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html