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: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Mon, 5 Apr 2021 17:33:18 +0200 (CEST)
On Mon, 5 Apr 2021, Henrik Holst wrote:
> On a side note (and perhaps I should have written this in a separate mail) I
> did notice that the timer function callback returns far too low values for
> long polling http servers if the user haven't set CURLOPT_TIMEOUT. Caveat
> here is that I have only tested this with 7.58 and 7.68 as of yet and not
> with HEAD.
As I mentioned before, we've removed the need for polling since then so a lot
of the really low-value timeouts are gone for a normal build. Now libcurl
waits on a socket even during a threaded name resolve.
> Here is one such run with CURLOPT_VERBOSE set, unfortunately the server is
> not public so replication might be hard:
If this problem was widespread/common, then you wouldn't need to use a private
server to reproduce surely?
Simply based on the fact that libcurl is fairly well used and nobody (else) is
reporting "100% cpu use", I don't think this is a common problem. But I'm also
sure there are bugs still to fix and I'm also sure that we've fixed bugs since
the versions you run. Some of those might change these things.
Date: Mon, 5 Apr 2021 17:33:18 +0200 (CEST)
On Mon, 5 Apr 2021, Henrik Holst wrote:
> On a side note (and perhaps I should have written this in a separate mail) I
> did notice that the timer function callback returns far too low values for
> long polling http servers if the user haven't set CURLOPT_TIMEOUT. Caveat
> here is that I have only tested this with 7.58 and 7.68 as of yet and not
> with HEAD.
As I mentioned before, we've removed the need for polling since then so a lot
of the really low-value timeouts are gone for a normal build. Now libcurl
waits on a socket even during a threaded name resolve.
> Here is one such run with CURLOPT_VERBOSE set, unfortunately the server is
> not public so replication might be hard:
If this problem was widespread/common, then you wouldn't need to use a private
server to reproduce surely?
Simply based on the fact that libcurl is fairly well used and nobody (else) is
reporting "100% cpu use", I don't think this is a common problem. But I'm also
sure there are bugs still to fix and I'm also sure that we've fixed bugs since
the versions you run. Some of those might change these things.
-- / 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.htmlReceived on 2021-04-05