Re: curl_multi_timeout and the multi_socket API

Den lör 3 apr. 2021 kl 22:56 skrev Fulup Ar Foll <fulup.arfoll_at_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