Henrik,
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.
Fulup
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.
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
