On Aug 18, 2008, at 10:30 PM, Daniel Stenberg wrote:
> 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...

But they are, CURLOPT_TIMEOUT is set to 120 and
CURLOPT_CONNECTTIMEOUT is set to 60 (sorry for not mentioning this
earlier). Should not always at least the former cause a permanent
timeout to be active? Or have I misunderstood how CURLOPT_TIMEOUT works?

Even with those set, it seems to not reset the pending timeout after
it fires occasionally. When I then ask curl_multi_timeout what the
timeout should be, it's usually around ~80-100ms. But this seems
awfully short, so I'm not sure if that isn't bogus somehow.

-- 
Josef Drexler
josef_at_ttdpatch.net