On Mon, 10 Mar 2008, Raf Nulens wrote:

> "curl_socket_callback: fd=2792, index=0, event=2"
>
> ** we set the write flag for socket 2792
>
> "curl_multi_timer_callback: timeout=14798" // set the timeout
> "curl_multi_socket: fd=2796, code=0 CURLM_OK, descr=no error, count=1"
> "curl_multi_socket: done, code = 0" // end perform multi socket (2)
>
> now we dont get a write event, but instead we get a timeout after 15 seconds.
> The connection itself has been set up, but already timed out after those 15
> seconds wait.

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?

> When we get a socket_callback is it possible that the socket in question is
> already connected and write enabled so that we dont get a write event?

Yes of course. But if your event layer works that way, then you need to fix it
or use it differently as libcurl will of course always use some CPU time
before it returns back and there will be moments where it has told the
callback that it wants to know when the socket is writable before it returns.

Of course I may not understand your issue correctly.

> We suspect that when we set the write flag for socket 2792 in the
> curl_socket_callback, we are too late to receive the event. Could this be
> possible?

I don't know how you "set the write flag" nor do I know how you receive
events, so I really can't tell unless you tell us more. And of course I know
very little windows details so I'm probably not the person to ask for windows-
specific details, but I'm willing to offer insights and advice on how libcurl
works and assumes the app to behave when using the multi_socket() API.

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