Den lör 3 apr. 2021 kl 00:01 skrev Daniel Stenberg <dan...@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
