curl / Mailing Lists / curl-library / Single Mail
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

From: Fulup Ar Foll via curl-library <>
Date: Mon, 5 Apr 2021 18:39:16 +0200

I confirm what Daniel said. If you take 100% of CPU your logic is obviously wrong.

If you run with a main loop, it is up to your your code to select which socket is ready for reading. From your mainloop callback your should call curl_multi_socket_action with the corresponding socket-fd and action. If you do so timeout callback will only be called once per get resquest. You may run my sample on your private server, you will see that it takes only few % of CPUs, this even when you have 50 parallel ongoing requests.


On 05/04/2021 17:33, Daniel Stenberg wrote:
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.

Received on 2021-04-05