Re: curl_multi_timeout and the multi_socket API

From: Henrik Holst via curl-library <curl-library_at_cool.haxx.se>
Date: Sat, 3 Apr 2021 00:16:09 +0200

Den lör 3 apr. 2021 kl 00:01 skrev Daniel Stenberg <daniel_at_haxx.se>:

> On Fri, 2 Apr 2021, Henrik Holst wrote:
>
> >> What "very same thing" is it that happens?
> >
> > For epoll, the "very same thing" is that if a non-curl socket is added
> to
> > the epoll efd then epoll_wait() would just like poll() enter a situation
> > where it might not return 0 to indicate timeout.
>
> libcurl doesn't need you to invoke it because of a timeout. It gives you
> the
> timeout for when to call it again *at the latest*. If you call it before
> that,
> perhaps because of activity on a socket, that's fine and you'll see that
> it
> will then often update the timeout accordingly.
>
I know, but that requires you to keep track of the time remaining yourself.
My point was that the naive implementation would be to call curl only on
read/write/error events from the event handler (epoll/poll in this case)
and then also when said event handler returns due to timeout but if the
event handler handles other events besides curl then you might end up in a
situation where you will never receive any event at all and also no timeout
event at all.

I'm not saying that there is something wrong with curl, just that the docs
as written could lead to some very naive implementation that works just
fine as long as it only handles curl events but as the application is
expanded all of the sudden curl seams to just die which is then due to the
naive implementation and not curl itself.

>
> If you miss the timeout moment and instead call libcurl a little late,
> libcurl
> will deal with the timeout actions then instead and all you loose is
> accuracy
> in things that are time based (timeouts, speed limits etc).
>
> > for epoll I would pass that on as the timeout argument for epoll_wait().
>
> But in that case there's really no difference compared to receiving that
> value with the timeout callback as then you'd just use the most recently
> set
> timeout callback value in the epoll_wait() call. (You just have to deduct
> the
> passed time in case you loop without the timeout having been updated etc)
>

the difference is that the callback might never be called due to
epoll_wait() never returning with events for curl nor returning on timeout
(since some other socket is having events so often that epoill never times
out). So you then either have to keep track of the elapsed time yourself
(which of course isn't that hard, but calling curl_multi_timeout() before
each call to e.g epoll is way easier) or you will have to call
curl_multi_socket_action() each time epoll returns which I guess would be
quite some overhead?

I'm not really arguing anything here more than pointing out that
curl_multi_timeout() have it's place even in the multi socket API :)

/HH

>
> This said, curl_multi_timeout() will work. It's just not intended for
> socket-based event loops.
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://www.wolfssl.com/contact/
>


-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-04-03