Re: curl_multi_timeout and the multi_socket API

Den sön 4 apr. 2021 kl 12:28 skrev Daniel Stenberg <daniel_at_haxx.se>:

On Sat, 3 Apr 2021, Henrik Holst wrote:

(Let me just add some meat to this and explain this described behavior.)

> As I wrote earlier, usually when you call curl_multi_add_handle(), the Timer
> Function CB is called once by curl with timeout set to 0. Then when you call
> curl_multi_socket_action() with CURL_SOCKET_TIMEOUT the Timer Function CB is
> usually called once more but this time with a timeout set to 1.

This description matches how libcurl *did* behave. More recent versions don't
need to poll the name resolve results from the threaded resolver so the
timeout pattern will be slightly different.

Ah, yeah I'm on 7.68 and 7.58 (Ubuntu 20.04 and Ubuntu 18.04).

The application should of course still be prepared to deal with the timeouts
libcurl asks for.

> If you do not call curl_multi_socket_action() again with CURL_SOCKET_TIMEOUT
> after 1ms then curl stalls indefinitely since there will be no read or write
> events triggering the event handler to return events,

... because in that scenario libcurl waits to get called so that it can poll
if the name resolve is done, and if you don't call libcurl then it won't
notice that and it can't continue to perform its transfer until that's done!

Exactly, which is why my stupid naive implementation worked fine in 100% of all cases until I started to put other sockets into my event handler. I hope no one has seen this as any form of critique of either curl or others (besides my own implementation), it was basically just me having to write it down somewhere to get a discussion going to get out of the whole "home blindness" and be able to fix my own implementation in a better way. Sometimes one just needs that kind of ball plank, sorry if I've wasted any ones time due to this, but then on the other hand some day in the future some one else with the same problem will google and find this discussion and perhaps learn something :-)

/HH