On Sun, 1 Jun 2008, Nathan E. Moore wrote:

> I just tried with cvs. With the changes to ignore CURLM_BAD_SOCKET, this
> obviously never happens, but if I don't ignore CURLM_BAD_SOCKET it does.

I don't get it. I've removed the previous way it returned CURLM_BAD_SOCKET for
curl_multi_socket() so you shouldn't ever get it. In your patch you
re-introduce it and then you get the error code. Why do you re-introduce it?

> calling curl_multi_socket with fd=28
> STATE: PERFORM => DONE handle 0xb80a9038; (connection #21)
> socket callback: s=28 e=0xb803da78 what=REMOVE
> multi_timer_cb: Setting timeout to 1 ms
> calling curl_multi_socket with fd=28
> ERROR: event_cb: curl_multi_socket returns CULRM_BAD_SOCKET

See, you're getting the exact same procedure I was talking about: libcurl asks
your app to remove fd 28 yet just milliseconds later you call
curl_multi_socket with action on that very same file descriptor. libcurl then
knows nothing about it anymore. In current CVS that's not a reason for failure
since I believe the above happens due to some weird effect/behavior of
libevent and besides I don't see any particular reason for libcurl to be that
picky.

-- 
  / daniel.haxx.se