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: Daniel Stenberg via curl-library <>
Date: Sat, 3 Apr 2021 00:01:58 +0200 (CEST)

On Fri, 2 Apr 2021, Henrik Holst wrote:

>> What "very same thing" is it that happens?
> For epoll, the "very same thing" is that if a non-curl socket is added to
> the epoll efd then epoll_wait() would just like poll() enter a situation
> where it might not return 0 to indicate timeout.

libcurl doesn't need you to invoke it because of a timeout. It gives you the
timeout for when to call it again *at the latest*. If you call it before that,
perhaps because of activity on a socket, that's fine and you'll see that it
will then often update the timeout accordingly.

If you miss the timeout moment and instead call libcurl a little late, libcurl
will deal with the timeout actions then instead and all you loose is accuracy
in things that are time based (timeouts, speed limits etc).

> for epoll I would pass that on as the timeout argument for epoll_wait().

But in that case there's really no difference compared to receiving that
value with the timeout callback as then you'd just use the most recently set
timeout callback value in the epoll_wait() call. (You just have to deduct the
passed time in case you loop without the timeout having been updated etc)

This said, curl_multi_timeout() will work. It's just not intended for
socket-based event loops.

  | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
Received on 2021-04-03