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

Reply via email to