On Thu, 2008-08-07 at 00:43 +0200, 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!
>

The timeout callback code evolved from multi_timeout which is tied to
the event loop, however.

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

This was a source of confusion that I was referring to in the docs.
Thanks for clarifying. The problem I have been observing the is
definitely related to the timeout callback invocation - perhaps there is
an incorrect optimisation carried over from multi_timeout? A slightly
ugly workaround that does work is to make the application store the
relative timeout value and reset the timer after each multi_socket call
if it has not already been made pending by the callback.
>
> Of course, in most normal situations the timeouts never fire but instead you
> just keep changing the timer when the callbacks update it.
>

This is what I meant by "scheduling the timeout inside the callback", as
opposed to scheduling it at the next iteration of the event loop. Sorry
that didn't make sense - I should should have said "timer" instead of
"timeout". It wasn't clear to me that curl was storing the absolute time
for the timeout to fire internally so it was safe to update an already
pending timer as well (instead of storing the relative timeout value and
using it to set the next timer).

-Albert
Received on 2008-08-09