cURL / Mailing Lists / curl-library / Single Mail


Re: curl_multi_timeout vs CURLMOPT_TIMERFUNCTION

From: Daniel Stenberg <>
Date: Sat, 17 Nov 2007 11:57:57 +0100 (CET)

On Sat, 17 Nov 2007, Nathan E. Moore wrote:

> The timeouts provided by curl_multi_timeout and CURLMOPT_TIMERFUNCTION do
> not always match. Sometimes multi_timeout will return 0, indicating that an
> immediate call to socket_all is wanted, however this value is never reported
> from the callback. I am also seeing a timeout of 299 from the function, but
> not from the callback. However, most of the time they match.

Hm, that sounds like a bug. They should be the same as they get the timeout
values using the same internal logic. Of course, the timeout being relative
from "now" the timeout values will differ slightly depending on when you ask
for them, but that's obviously not the explanation to what you see.

299ms? It also sounds like a (different) bug, since we have a 300 second (not
millisecond) default timeout for name resolves and connects, but then it
should return something like 299000 to start with and not 299...

> I am looking for a little clarification if I use the callback, do I still
> need to handle the 0 case?

When you use the callback you should get called with updated timeout values
(whenever libcurl updates the value internally), so if you get 0 then you
should timeout at once...

> Are these differences caused by going too long without calling a socket_*
> function (not giving the callback a chance to update?)?

Well, if you do something a long time outside of libcurl so that you can't get
a callback and then ask for curl_multi_timeout() you will of course get the
updated time. But still, since you didn't call libcurl for long it shouldn't
have been able to do any operation that would change the timeout value...

> This last idea seems suspect to me since the only thing my test code does
> between calls to poll is remove completed easy handles from the multi stack.

Right, and the removal of easy handles could cause the timeout callback to get

> I am using 7.16.4, but there don't appear to be any major changes to multi.c
> between then and now

No, this stuff hasn't been touched for a while.

Is this discrepancy easy to provoke/repeat for you? If so, can you provide an
example source code we can try in our ends?

  Commercial curl and libcurl Technical Support:
Received on 2007-11-17