On Wed, 11 Jun 2008, Josh Handley wrote:

> I'm using the curl_multi_socket interface and at the same time limiting the
> transfer speed with CURLOP_MAX_RECV_SPEED_LARGE and I can't get it to work
> correctly. From what I can tell, when the transfer rate goes above the max,
> I get a socket callback with the "what" parameter set to CURL_POLL_REMOVE.
> After that I never get another socket callback so I never pass my socket to
> curl_multi_socket_action and my request never completes.

This certainly sounds like a bug. Using 7.18.2?

> I had assumed that calling curl_multi_socket_action with CURL_SOCKET_TIMEOUT
> would eventually give me another socket callback with the "what" parameter
> set to CURL_POLL_IN, CURL_POLL_OUT or CURL_POLL_IN_OUT but it never does.

No, you shouldn't need to do that and I believe the bug won't be "repaired" by
you doing that.

> The only way I can get the transfer started again is to repeatedly call
> curl_multi_socket_all over and over again after I get the CURL_POLL_REMOVE.
> While this works, I don't have any indication how long I need to wait before
> making the call so I end up with a busywait - calling curl_multi_socket_all
> in a tight loop. Is there a way to find out from libcurl how long to wait
> before calling curl_multi_socket_all so I can give some other parts of my
> system a few CPU cycles while I'm waiting.

There's no answer to that since you're suffering from a bug and you're doing a
work-around for it. The proper fix is to make sure that you get the socket
re-added once libcurl deems it suitable to continue transferring on the
socket.

> By the way, the regular multi interface has the same problem.

Interesting. That makes this a regression since I recall us having tested this
using the regular multi API in the past!

> I have attached small test program that illustrates the problem.

Great! I'll dig into this problem as soon as I get some time over!

-- 
  / daniel.haxx.se