On Thu, 22 May 2014, Robert Wojciechowski wrote:

> I am using libcurl multi interface. There is a loop that use
> curl_multi_wait() function to wait for sockets to be ready with bandwidth
> limits enabled. Problem appears when bandwidth limit is small,
> curl_multi_wait() returns immediately. Then the effect is a busy loop.

The busy loop is yours though, not libcurl's. And I re-read the documentation
for curl_multi_wait now and it does mention this case, although it isn't that
easy for someone to tell that a bandwidth limit would lead to it.

> In my code I use: curl_multi_timeout(e->multi, &timeout); I get expected
> timeout that I should wait, and then I do curl_multi_wait(e->multi, NULL, 0,
> timeout, &numfds); and this function returns immediately with numfds set to
> 0.
>
> According to docs numfds is set to 0 what would mean no sockets to wait for.
> But actually there are running socktes, but curl is exceeding bandwidth
> limit.

Since libcurl has deemed the bandwidth to be out of bounds it doesn't care
about that socket (for the moment) and thus there is no sockets for it to wait
for.

If there's nothing to do and nothing to wait for, what should libcurl do? I
decided that it would be better for libcurl to return immeditely then to allow
the application to do something else or wait or whatever.

In libcurl's own code for curl_easy_perform() it actually uses
curl_multi_wait() itself and for that we check how quickly it returns and if
it returns quickly more than twice in a row we sleep (and we increase the
sleep time for each subsequent fast loop until a maximum).

> Is'n it a confusing behavior? I think curl_multi_wait() should handle this
> particular case.

You mean it should handle it _differently_ because it does in fact handle it
already. Just not the way you expected it to.

> Use sleeping instead of select() and do not return immediately or at least
> return an error code or set a message, because using too high bandwidth does
> not mean that there are no sockets to wait.

Sure it does. It can't wait for anything on that socket, since surely it'll be
readable again before it gets down to the speed threshold.

You can probably achieve your desired effect by providing another "fake" file
descriptor of your own that never gets readable...

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html