Den lör 3 apr. 2021 kl 18:41 skrev Fulup Ar Foll <fulup.arf...@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.arf...@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 <dan...@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 >> >> >> >
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
