Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: curl_multi_timeout and the multi_socket API
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Henrik Holst via curl-library <curl-library_at_cool.haxx.se>
Date: Sat, 3 Apr 2021 23:13:05 +0200
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
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-04-03
Date: Sat, 3 Apr 2021 23:13:05 +0200
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
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-04-03