On Aug 7, 2008, at 9:11 AM, Daniel Stenberg wrote:
> On Thu, 7 Aug 2008, Josef Drexler wrote:
>>> No, when it fires you don't set another timeout by yourself, but
>>> you should pretty soon get a new timeout callback for the next
>>> timer.
>>
>> How? If no other events happen, libcurl's socket interface won't
>> be called again after the timeout expires.
>
> No, but when one timeout fires you call libcurl again and if there
> is a pending next timeout the callback will be called with an
> updated timer. If there is no pending timeout, well then there
> simply is no more timeouts.

But to not set a timeout only makes sense when there are no more
active handles. However, with libcurl 7.18.2 it regularly happens
that the CURL_SOCKET_TIMEOUT call returns without having set a new
timeout, despite there being multiple active handles. If all of those
handles stall, libcurl won't be called again and they'll just be...
stuck. Unless I manually abort them. Or, as I've been doing now, add
a timeout of 60 seconds just so libcurl sees *some* action in the
future.

>> I know that rtorrent will call libcurl with CURL_SOCKET_TIMEOUT
>> exactly once for every time the timeout callback is triggered
>> (unless a timeout was already pending, in which case it is
>> replaced with the new value). They are in fact scheduled
>> asynchronously, contrary to what he wrote in an earlier message.
>> When the timeout value is zero, the CURL_SOCKET_TIMEOUT call
>> doesn't happen until all other pending events have been handled.
>> Then it will be called just before we'd wait for new events to
>> happen (unless of course a different timeout value has been set
>> because of handling the other events). But that should be fine,
>> right?
>
> Yes, that sounds like a description of how things should work! What
> libcurl version are you using?

7.18.2

-- 
Josef Drexler
josef_at_ttdpatch.net