cURL / Mailing Lists / curl-library / Single Mail


RE: CURLMOPT_TIMERFUNCTION not called when last timer cancelled

From: Daniel Stenberg <>
Date: Mon, 23 Jun 2008 23:25:36 +0200 (CEST)

On Mon, 23 Jun 2008, David Lasker wrote:

> curl_multi_socket_action calls update_timer
> update_timer calls multi_timeout
> multi_timeout sets timeout_ms to -1, since multi->timetree is NULL
> update_timer returns without calling the timer callback
> (multi.c line 1937), since timeout_ms < 0
> As a result, my timer callback function is never called after the final
> connection is made. This creates problems, since my code erroneously
> continues to use the result from libcurl's previous call to my timer
> callback.

Right, but why is that so bad? That should only result in one too many calls
to curl_multi_socket() when the timeout fires, and if libcurl has nothing to
do then it returns very quickly. I believe I reasoned like that when I fiddled
with this code. There's a lot more work to disable the timeout, and in most
cases there will also be other timeouts that will get updated anyway before it
would fire.

> I would like to get one final call of my timer callback function with
> timeout_ms set to -1.

Yeah, that would be the cleaner way to do it. You up to providing a patch for

> I believe that update_timer should check for this, and call multi->timer_cb
> the first time that multi_timeout sets timeout_ms to -1.
> I have worked around this problem by abandoning the timer callback
> mechanism, calling curl_multi_timeout directly just before my select, and
> taking appropriate action when it sets timeout_ms to -1.

You use curl_multi_socket() with select() ?

Received on 2008-06-23