curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: curl_multi_timeout and the multi_socket API

From: Fulup Ar Foll via curl-library <>
Date: Sat, 3 Apr 2021 22:56:29 +0200

I posted this sample on github because I lost too many hours searching for curl logic in the documentation. You have to respect curl_timeout, nevertheless if your mainloop works well, it should be call only once per download. In my case I do not wait 1ms before initial call and everything works perfectly well.

Add a "fprintf" to my sample printing curl requested timeout within corresponding function and you will understand the logic. It took me a while to understand how to interface correctly libcurl with a mainloop, but outside of an "uncommon logic" it works perfectly well.


On 03/04/2021 19:02, Henrik Holst wrote:
Den lör 3 apr. 2021 kl 18:41 skrev Fulup Ar Foll <>:

Curl timeout and mainloop timer as in my sample with libuv, epool, ... are completely independent. Curl handle its own timer to remind you when you're supose to do some action. But as soon transfert start you only handle communication go through the main event loop.

In order to use epool, you only need to map what I did for livuv, nothing more nothing less. You only need to write the 'epoll' version of and you should only call one curl_multi_timeout()

As I wrote earlier, usually when you call curl_multi_add_handle(), the Timer Function CB is called once by curl with timeout set to 0. Then when you call curl_multi_socket_action() with CURL_SOCKET_TIMEOUT the Timer Function CB is usually called once more but this time with a timeout set to 1. If you do not call curl_multi_socket_action() again with CURL_SOCKET_TIMEOUT after 1ms then curl stalls indefinitely since there will be no read or write events triggering the event handler to return events, in fact you won't even get a call to your Socket Function CB before you handle that first 1ms timeout.

Now I might have misread what you wrote, but some external timer is still needed so the question at hand is if having such a timer is more or less complexity/overhead than simply calling curl_multi_timeout().



On 03/04/2021 16:08, Henrik Holst wrote:

Den lör 3 apr. 2021 kl 10:40 skrev Fulup Ar Foll <>:

I wrote an example using either sytemd or libuv main loop, it might eventually help you
Thanks, I can see that you use the timer functionatilty in libuv and systemd to avoid the problems that I'm talking about. The main question then is if a call to curl_multi_timeout() before each call to epoll_wait() / poll() / select() is more or less overhead than using timers.



On 02/04/2021 23:08, Henrik Holst via curl-library wrote:

Den fre 2 apr. 2021 kl 23:05 skrev Daniel Stenberg <>:
On Fri, 2 Apr 2021, Henrik Holst via curl-library wrote:

> for (;;)
>  int ret = poll (fds, nfds, timeout);
>  if (ret == 0) {/* timeout */
>     curl_multi_socket_action (curlm, CURL_SOCKET_TIMEOUT, 0,
> &running_handles);
>  } else if (ret != -1) { /* events */
>    if (fds[0].revents != 0)
>      curl_multi_socket_action (curlm, fds[0].fd, fds[0].revents,
> &running_handles);
>    else if (fds[1]).revents != 0)
>      ...
>  }
> }

This is a typical example of an event loop that should rather use
curl_multi_perform() or perhaps even just curl_multi_poll(). And yes, for such
an event loop you want curl_multi_timeout (at least unless you use

If you use poll() then the multi socket API is probably the wrong choice. The
multi socket API is for event-based handling.
Okey, but the very same thing happens with epoll, or are we only defining event-based handling as say libevent, libev and libuv?


Received on 2021-04-03