cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: curl_multi_wait changes timeout to 0 and returns immediately

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Fri, 19 Dec 2014 14:46:10 +0100 (CET)

On Tue, 16 Dec 2014, Alex Lyakas wrote:

> I always specify one "extra_fd", which most of the time is not readable,
> and a timeout of 30,000 msec.
>
> What I see is that curl_multi_wait appears to always change this value to 0
> ms, and as a result it's poll() call returns immediately. This results in a
> busy loop in the calling thread. Is this something expected?

No. That sounds like a possible bug.

> As an experiment, I tried to specify timeout=-1 to the curl_multi_wait
> API. In this case, the timeout value is not overridden, and everything
> works as expected. However, I am bit worried to use timeout=-1,

You should be. It is not documented to work. Maybe it should be, but you're
relying on undocumented behaviors right now.

> because as I learned from email thread "curl_multi_wait returns immediately
> when using bandwidth limit" in
> http://curl.haxx.se/mail/lib-2014-05/0224.html, in some cases, the code may
> decide that the state of the SessionHandle is not appropriate for returning
> any socket. In that case, it may happen that the only socket that libcurl
> will wait on, will be my extra socket.

Not only during that situation, so yes it can certainly happen.

> Am I missing something? What the caller is expected to do if curl_multi_wait
> returns immediately?

I've been thinking about either adding a curl_multi_wait() replacement, or an
additional helper function to provide more information to the application in
the case when 'numfds' is zero on return. Did it then return due to timeout or
due to there being no file desciptors to wait for? Currently you basically
need to time the function to figure that out and I find that a bit disturbing.

If there are no file descriptors to wait for, the application better either
add file descriptors or wait a little while before it loops back and waits
again as otherwise it'll just busy-loop until a descriptor shows up.

> I see that in curl_easy_perform, there is some code which sleeps if that
> happens (depending on the number of times that it happened). Is this the
> recommended approach?

The curl_multi_fdset() has some language for this and it says: "How long to
wait? We suggest 100 milliseconds at least, but you may want to test it out in
your own particular conditions to find a suitable value. "

> Or should I drop the curl_multi_wait approach and try to use the
> curl_multi_socket_action API?

I can't really tell since it depends on many factors. Sure you can but you
don't _have to_.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Received on 2014-12-19