On Aug 6, 2008, at 11:24 PM, Daniel Stenberg wrote:
> On Wed, 6 Aug 2008, Albert Lee wrote:
>
>> It appears that our curl stack was actually not handling timeouts
>> correctly - it is not entirely clear from the documentation, and
>> unfortunately several other consumers of libcurl have
>> misinterpreted it as well. We used on the CURLM_TIMERFUNCTION
>> callback to synchronously schedule timeouts for us, and so we
>> completely forgot the timeout when the value didn't change.
>
> Well, in my mind event-based systems such as the multi_socket API
> are all about only telling about changes - so unless something
> changes the former situation still stands. Sort of...

There seems to be some disagreement about what a timeout refers to.

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. If the timer needs to be reset at some point, libcurl needs
to request that. For instance, this is also how libcurl's hiper/
hipev.c works, it never resets the timeout except from the timeout
callback, so it will fire no more than once unless the callback is
triggered again.

If libcurl expects the timeout interval to be reset regularly, it
needs to be clear about how this should be done. Is it to be reset
every time the timeout fires, to the same interval as previously,
making it a "tick" of sorts that fires at regular intervals
regardless of what happens during the interval? Or is it to be reset
whenever we call curl_multi_socket_action, making it an inactivity
timeout instead?

The docs don't mention anything about when or how the timeout should
be reset. Hence one can but assume that libcurl would take care of
that by calling the timeout callback as appropriate. Though from the
discussion now it seems the timeout should be reset whenever it
fires, or did I misunderstand it again?

When you come from the select() kind of framework though, you'd
expect the timeout to refer to an interval that's "automatically"
reset whenever you call select(). However for event based frameworks
for which curl_multi_socket_action is useful, a timer is something
you set once, and that fires when the given future time is reached
(if you haven't cancelled it before). So in that mindset you would
actively need to reset the timer after each curl_multi_socket_action
call, if you expect it to work like it did in the select() case.
Though this would be a relatively expensive operation when you have
many sockets with many events, even when the timeout is implemented
using a priority queue.

Either way, please clarify how libcurl expects timers to be reset. It
would be good though if it doesn't have to happen too often.

-- 
Josef Drexler
josef_at_ttdpatch.net