Repository navigation
concurrent.interpreters.Queue.get()/put() mishandle the timeout argument #153005
Description
concurrent.interpreters.Queue.get() and Queue.put() mishandle their
timeout argument in three related ways.
-
The value is converted with
int(timeout), which truncates a floating-point
timeout to whole seconds. A timeout in the interval[0, 1)becomes a
non-blocking call, and e.g.timeout=1.9waits for only about one second.
queue.Queue, which this queue is meant to be compatible with, accepts a
floating-point number of seconds. -
Because of the same
int()conversion, a small negative float such as
timeout=-0.5is truncated to0and passes thetimeout < 0check
instead of raisingValueError. -
The deadline is computed with
time.time()(the wall clock), while
queue.Queueusestime.monotonic(). The timeout can therefore over- or
under-wait if the system clock is adjusted (NTP step, manual change) during
the call.
Reproducer (3.14.5)
import time
from concurrent.interpreters import create_queue
q = create_queue(maxsize=1)
q.put(b"x") # fill it
start = time.perf_counter()
try:
q.put(b"y", timeout=0.5) # expected: block ~0.5s, then QueueFull
except Exception as exc:
print(type(exc).__name__, f"{(time.perf_counter() - start) * 1000:.1f} ms")
# -> QueueFull 0.0 ms (expected ~500 ms)
q2 = create_queue()
start = time.perf_counter()
try:
q2.get(timeout=0.9) # expected: block ~0.9s, then QueueEmpty
except Exception as exc:
print(type(exc).__name__, f"{(time.perf_counter() - start) * 1000:.1f} ms")
# -> QueueEmpty 0.0 ms (expected ~900 ms)For comparison, queue.Queue().get(timeout=0.5) blocks for about 500 ms.
The fix is to use the timeout value as given, reject a negative or NaN timeout
with ValueError, and base the deadline on time.monotonic().
Linked PRs
- gh-153005: Fix timeout handling in concurrent.interpreters.Queue #153006
- gh-153005: Use a monotonic clock for concurrent.interpreters Queue timeouts #154156
- [3.15] gh-153005: Use a monotonic clock for concurrent.interpreters Queue timeouts (GH-154156) #155967
- [3.14] gh-153005: Use a monotonic clock for concurrent.interpreters Queue timeouts (GH-154156) #156018
- [3.13] gh-153005: Use a monotonic clock for concurrent.interpreters Queue timeouts (GH-154156) #156019
Activity
Merge branch 'main' into fix-pythongh-153005-interpreters-queue-monot…
gh-153005: Use a monotonic clock for concurrent.interpreters Queue ti…
pythongh-153005: Use a monotonic clock for concurrent.interpreters Qu…
[3.14] gh-153005: Use a monotonic clock for concurrent.interpreters Q…
[3.13] gh-153005: Use a monotonic clock for concurrent.interpreters Q…
[3.15] gh-153005: Use a monotonic clock for concurrent.interpreters Q…
aisk commentedon Oct 13, 2026
@picnixz on #153006 (comment):
The other queues in the stdlib all accept a float timeout and none of them truncate it:
queue.Queue.get(): https://github.com/python/cpython/blob/83dbe6ae9f47/Lib/queue.py#L202-L212queue.SimpleQueue.get(): https://github.com/python/cpython/blob/83dbe6ae9f47/Modules/_queuemodule.c#L384-L397multiprocessing.Queue.get(): https://github.com/python/cpython/blob/83dbe6ae9f47/Lib/multiprocessing/queues.py#L96-L111I checked the code, and
concurrent.interpreters.Queuecan support a float timeout. The tests added with the original implementation also use a float as the timeout: https://github.com/python/cpython/blob/83dbe6ae9f47/Lib/test/test_interpreters/test_queues.py#L314. So I guess theint()conversion was just intended to check the type of the timeout, andfloat()would have worked as well.