--On Saturday, November 17, 2007 11:57 AM +0100 Daniel Stenberg
<daniel_at_haxx.se> wrote:
> 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...

This one is not a bug in curl but rather a omission in my initial message I
am seeing a 299 seconds, not milliseconds.

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

Yes this is very easy to get. I post some example code as soon as I get a
standalone example written. My current example depends on ~1500 lines of
python and as such is not really suitable to post here.

Thanks
Nathan E. Moore
Received on 2007-11-18