On Sat, 5 Sep 2009, Dimitar Dimitrov wrote:

> Maybe this is known, but I didn't find any reference to it. I've been trying
> to go the socket_action way (curl-7.19.6) and run into the following
> problem:
>
> Reaching the speed limit, curl_multi_socket_action calls the socket
> callback, removing the sole socket for the easy handle, so even calling it
> again with CURL_CSELECT_IN doesn't do anything.

Right, but it should also set a timeout so that after a given time it should
call your timer callback, you call libcurl and it should put the socket back
in the game again. If not, it bugs.

> - change multi_getsock [lib/multi.c:779] to return the non-empty bitmask in
> case of CURLM_STATE_TOOFAST

How is that a fix? How does libcurl then tell the app that it shouldn't care
about traffic on that particular socket for now since it is "too fast" ?

> which if I understood the source correctly, will cause curl_multi_fdset to
> feed too many descriptors for selecting

The *_getsock() functions are used for the multi interface to know what
sockets it deals with right now and for what reason. As it is also used for
the _socket() API it can obviously not only be for select reasons.

> Any suggestions?

Can you see why the timeout doesn't trigger, or if it does trigger why it
doesn't put the socket back in the game correctly?

Can you provide us with a small app that repeats this problem?

-- 
  / daniel.haxx.se