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: Sun, 4 Apr 2021 16:34:17 +0200
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
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-04-04
Date: Sun, 4 Apr 2021 16:34:17 +0200
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
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-04-04