Den sön 4 apr. 2021 kl 00:06 skrev Fulup Ar Foll <fulup.arf...@iot.bzh>:
> I'm not sure to understand your logic. If you have to call > curl_multi_timeout() at each iteration of your mainloop your logic should > be wrong. > I never said that I had to, just that one could (in order to avoid having a timer, aka if the latency requirement is not that high then logic is easier and loc is smaller by just calling curl_multi_timeout() on each iteration). > > I also mix curl-socket with multiple other classes of sockets and do no > call call curl_multi_timeout() at each iteration. > > In my sample the eventloop call 'glueOnSocketCB' as soon as a curlsocket > is readable. 'glueOnSocketCB' map mainloop event-names to curl-events > name before calling 'httpOnSocketCB' that finally call > curl_multi_socket_action to do the job. If you do so, you do not have to > call curl_multi_socket_action. The secret is to map your main loop > event-name to curl-names. > > In my code 'glueOnSocketCB' is attached to mainloop within glueSetSocketCB > that is called from multiSetSockCB. This last one is call from curl with " > curl_multi_setopt(httpPool->multi, CURLMOPT_SOCKETFUNCTION, > multiSetSockCB);" > > For the timer you do not need an external lib, you may use timerfd and > epool is just as find as any other mainloop. In my case I use systemd > mainloop, because this what the rest of the application uses. I did libuv > to make sure my code was independent of the mainloop, in case app > developper would like to change in the future. I did not port for > epool/timerfd, but I'm sure that it would not take more that few hours. > yes you are correct that timerfd would work fine here, don't know why I never thought of timerfd. /HH > > On 03/04/2021 23:13, Henrik Holst wrote: > > > > Den lör 3 apr. 2021 kl 22:56 skrev Fulup Ar Foll <fulup.arf...@iot.bzh>: > >> Henrik, >> >> 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. >> > I was not speaking about waiting 1ms before the initial call, it was just > an observation that the timer function callback was very often being called > with timeout=0, timeout=1, timeout=-1 and that timeout=1 was the cause of > my initial troubles since calling epoll_wait with 1ms timeout made it never > return 0 to indicate timeout (since some other sockets that I had in the > same epoll had recv traffic more often than that). Relying on epoll_wait() > returning 0 works flawless if one only have curl sockets in the epoll so it > was faulty logic when the application was expanded beyond handling only > curl requests. > > Anyway I've redone the logic anyway to minimize the overhead penalty of > calling curl_multi_timeout() on each iteration of the main event loop and > now actually uses the timer callback but instead of relying on epoll_wait() > returning 0 I calculate when the timeout have timed out against the > wallclock (clock_gettime() + timeout from the callback), and check that > instead which I of course should have done from the beginning. That way the > overhead is minimized (just a call to clock_gettime() wich for this > specific implementation is overhead that I can live with) and there is no > need for any external timers or event libs, just bog standard epoll. > > /HH > > >
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html