8000 Queue get timout parameter does not use a monotonic timer · Issue #104509 · python/cpython · GitHub
[go: up one dir, main page]

Skip to content

Queue get timout parameter does not use a monotonic timer #104509

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
fdirosa4188 opened this issue May 15, 2023 · 6 comments
Open

Queue get timout parameter does not use a monotonic timer #104509

fdirosa4188 opened this issue May 15, 2023 · 6 comments
Labels
3.11 only security fixes 3.12 only security fixes pending The issue will be closed if no feedback is provided stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@fdirosa4188
Copy link

It is clear looking at the source code that the Queue class uses time() and other non-monotonic timing sources. So if a queue get function is called with a timeout value and the system time is changed during that get it could end up waiting in the get for potentially days. The easiest way to reproduce is to set the timeout in the get to 5 minutes and which it is waiting on the queue to get an entry set the system clock back a few years. You will notice it will not exit the get.

@fdirosa4188 fdirosa4188 added the type-bug An unexpected behavior, bug, or error label May 15, 2023
@arhadthedev arhadthedev added stdlib Python modules in the Lib dir 3.11 only security fixes 3.12 only security fixes labels May 15, 2023
@arhadthedev
Copy link
Member

@rhettinger (as a queue module expert)

@Agent-Hellboy
Copy link
Contributor
Agent-Hellboy commented May 16, 2023

do you have a reproducible code?
it's monotonic

from time import monotonic as time

As the issue template suggests you should share the reproducible code and the execution environment as well

@fdirosa4188
Copy link
Author
fdirosa4188 commented May 17, 2023

I am using Python 3.8.6 on Linux.
Attached is python code that reproduces this problem. I set a specific date/time before the queue.get blocking call with a 10 second timeout and then change the date/time to a different date/time during the queue.get and it does not return after 10 seconds.

There is a variable in the attached script called Make_It_Fail that is set to True. You can set it to False to see how the script works without date/time changes then set it to True to see how queue.get does not return after 10 seconds has elapsed.
queue_timeout_test.py.txt

@aludwig98
Copy link

This seems to have been resolved in Python 3.9, 3.10.

See here: #85876

@fdirosa4188
Copy link
Author

I tried my queue_timeout.test.py script on Python 3.11 and it still does not timeout after 10 seconds. The queue.get() function blocks and seems to still be effected by changes to the system time on Linux.

@duaneg
Copy link
Contributor
duaneg commented May 24, 2025

I can't reproduce the bug on current HEAD (v3.15-alpha), but then I can't reproduce it on v3.11.0 either. In both cases it produces the correct, expected output:

Date/Time before queue.get(): 05/18/2024 23:34:43
Calling queue get with blocking and 10 seconds timeout
Date/Time during queue.get(): 05/18/2023 18:34:43
10.00 seconds has elapsed and it is not blocked

As @Agent-Hellboy says, the queue code itself uses a monotonic clock, and after #28662 so does the underlying lock the condition variable waits on.

@fdirosa4188 please re-test and close if confirmed.

@picnixz picnixz added the pending The issue will be closed if no feedback is provided label May 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.11 only security fixes 3.12 only security fixes pending The issue will be closed if no feedback is provided stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

6 participants
0