On Mon, 18 Aug 2008, Josef Drexler wrote:

>> 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.

Eh, yes. As that's the defined behavior. What else would libcurl do?

> 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.

That's rather pointless since libcurl won't do anything to stalled connections
after 60 seconds, 600 seconds or 6000 seconds even if you call the timeout
action. Unless you set one of the options that will make it care, and then it
should also set the timout...

-- 
  / daniel.haxx.se