Buy commercial curl support. 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 Daniel himself.
High CPU usage associated to busy loop in curl_timediff_us()
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stephane Cruchon via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 10 Sep 2025 13:15:28 +0000
Hello all,
We've observed a situation where curl_timediff_us() seems to spin in a tight loop when libcurl runs inside a container. This leads to high cpu usage.
Version : libcurl-8.10.1 running in a container ( Debian 12 slim )
Context : used in multi threading calls where each thread associated to this busy loop will be illustrated to a new step
[cid:50609fe1-a0b7-4087-8620-bdbfa39a1abc]
Symptoms
*
Inside Docker (or other container runtime), libcurl enters what looks like a busy loop.
*
CPU usage spikes, as curl_timediff_us() keeps recalculating deltas without yielding.
*
This does not reproduce on bare-metal, only inside containers.
Possible causes
*
Clock behavior inside containers: lack of a stable clock_gettime or drift in the container’s time namespace could cause libcurl to believe a timeout has already expired, re-evaluating it in a tight loop.
*
API multi usage: in some cases curl_multi_perform()/multi_wait() rely on timediff_us and can fall into busy looping if time deltas are computed as zero or negative repeatedly.
Related history
*
In libcurl 7.55.0, a bug was reported when time_t was unsigned (e.g. on QNX), causing infinite loops in timeout checks. This was fixed by introducing a signed timediff_t type and better underflow/overflow handling. GitHub issue #2004<https://github.com/curl/curl/issues/2004?utm_source=chatgpt.com>.
*
Other discussions report similar high-CPU loops in multithreaded scenarios, which were mitigated in later releases (>= 7.76.0 and in 8.x). Example: GitHub discussion #12642<https://github.com/curl/curl/discussions/12642?utm_source=chatgpt.com>.
Open questions
*
Is this still a known/expected issue when running libcurl in containers with isolated clocks?
*
Would upgrading to >= 8.15.0 be the recommended solution, or is there a known workaround for container environments?
*
Has anyone else seen curl_multi_perform / curl_timediff_us spin specifically inside Docker or similar runtimes?
Thanks for any insights,
Stéphane Cruchon.
[Logo]<https://www.actility.com/> [Logo]
Stephane Cruchon
R&D team Manager Support
Buy hardware in ThingPark Market<https://market.thingpark.com/>, try (free) on ThingPark Community<https://community.thingpark.org/>, deploy with Actility<https://www.actility.com/>
[Banner]<https://www.actility.com/timeline-of-events/>
The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. Actility.
Received on 2025-09-10
Date: Wed, 10 Sep 2025 13:15:28 +0000
Hello all,
We've observed a situation where curl_timediff_us() seems to spin in a tight loop when libcurl runs inside a container. This leads to high cpu usage.
Version : libcurl-8.10.1 running in a container ( Debian 12 slim )
Context : used in multi threading calls where each thread associated to this busy loop will be illustrated to a new step
[cid:50609fe1-a0b7-4087-8620-bdbfa39a1abc]
Symptoms
*
Inside Docker (or other container runtime), libcurl enters what looks like a busy loop.
*
CPU usage spikes, as curl_timediff_us() keeps recalculating deltas without yielding.
*
This does not reproduce on bare-metal, only inside containers.
Possible causes
*
Clock behavior inside containers: lack of a stable clock_gettime or drift in the container’s time namespace could cause libcurl to believe a timeout has already expired, re-evaluating it in a tight loop.
*
API multi usage: in some cases curl_multi_perform()/multi_wait() rely on timediff_us and can fall into busy looping if time deltas are computed as zero or negative repeatedly.
Related history
*
In libcurl 7.55.0, a bug was reported when time_t was unsigned (e.g. on QNX), causing infinite loops in timeout checks. This was fixed by introducing a signed timediff_t type and better underflow/overflow handling. GitHub issue #2004<https://github.com/curl/curl/issues/2004?utm_source=chatgpt.com>.
*
Other discussions report similar high-CPU loops in multithreaded scenarios, which were mitigated in later releases (>= 7.76.0 and in 8.x). Example: GitHub discussion #12642<https://github.com/curl/curl/discussions/12642?utm_source=chatgpt.com>.
Open questions
*
Is this still a known/expected issue when running libcurl in containers with isolated clocks?
*
Would upgrading to >= 8.15.0 be the recommended solution, or is there a known workaround for container environments?
*
Has anyone else seen curl_multi_perform / curl_timediff_us spin specifically inside Docker or similar runtimes?
Thanks for any insights,
Stéphane Cruchon.
[Logo]<https://www.actility.com/> [Logo]
Stephane Cruchon
R&D team Manager Support
Buy hardware in ThingPark Market<https://market.thingpark.com/>, try (free) on ThingPark Community<https://community.thingpark.org/>, deploy with Actility<https://www.actility.com/>
[Banner]<https://www.actility.com/timeline-of-events/>
The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. Actility.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
(image/png attachment: image.png)