Re: curl_multi_timeout and the multi_socket API

Den lör 3 apr. 2021 kl 18:41 skrev Fulup Ar Foll <fulup.arfoll_at_iot.bzh>:

Henrik,

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 https://github.com/fulup-bzh/libcurl-mainloop/blob/main/glue-libuv.c 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().

/HH

Fulup

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

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

Henrik,

I wrote an example using either sytemd or libuv main loop, it might eventually help you https://github.com/fulup-bzh/libcurl-mainloop

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.

/HH

Fulup

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

Den fre 2 apr. 2021 kl 23:05 skrev Daniel Stenberg <daniel_at_haxx.se>:

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
curl_multi_poll).

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?

/HH

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html