On Aug 7, 2008, at 12:43 AM, Daniel Stenberg wrote:
> On Thu, 7 Aug 2008, Josef Drexler wrote:
>
>> I too understand a timeout to be a one-time event. Once the timer
>> event has fired and libcurl needs another, libcurl needs to
>> request a new one.
>
> Yes, that's how it works and that's how I view timeouts to function
> as well!
>
>> Though from the discussion now it seems the timeout should be
>> reset whenever it fires, or did I misunderstand it again?
>
> 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. Unless libcurl makes sure to
always set a new timeout when called with CURL_SOCKET_TIMEOUT,
returning without setting one can easily make libcurl stall
completely if no more data arrives on any of the handles. Then you
will probably not see any new events at all until an existing
connection times out at the TCP level and causes an error event on
the socket. That can take a very long time though. So libcurl must
always make sure that the appropriate timeout is pending,
particularly when it is called with CURL_SOCKET_TIMEOUT which
indicates that a timeout has just fired.

> Of course, in most normal situations the timeouts never fire but
> instead you just keep changing the timer when the callbacks update it.

Yeah. Though DNS lookups will regularly time out, and connection
attempts too when the server or the network is down. But then I don't
understand the problem Albert was having (he and I are both working
on getting rtorrent to use libcurl's socket interface). 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?

-- 
Josef Drexler
josef_at_ttdpatch.net