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.

--

 / daniel.haxx.se
 | Commercial curl support up to 24x7 is available!
 | Private help, bug fixes, support, ports, new features
 | https://www.wolfssl.com/contact/
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Reply via email to