Re: Bug in curl multi DONE->COMPLETED state transition?
Date: Tue, 19 Aug 2008 00:36:00 +0200
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
> 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.netReceived on 2008-08-19