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
Use time.steady() to implement timeout #58430
Comments
Queue.get([block[, timeout]]) uses time.time() for calculations of the timeout. If someone changes the system time this breaks. If a timeout of 1 second is set and someone (on a unix system) uses date to set the time 1 hour back, Queue.get will use 1 hour and 1 second to time out. I'm guessing the fix is just to use another library function to measure time, but I don't know if one exists that works on all platforms. |
Well, in 3.3 we could use clock_gettime(CLOCK_MONOTONIC) where available. |
It's better to use time.monotonic().
Yep, it may be used for lock.acquire(timeout=timeout) for example. It |
queue_monotonic.patch: simple patch using time.monotonic(), with a fallback to time.time() if monotonic failed or is not available. |
threading_monotonic.patch: similar patch for the threading module. Drawback of these patchs: they now call time.monotonic() when the module is loaded (another useless syscall?). |
Random thoughts:
That being said, it's probably a good idea. As for the patches, I don't really like the idea of having to use this try: |
New changeset d97ae725814c by Victor Stinner in branch 'default': |
Yo, I had marked this as something I was going to review once the python-dev discussion to complete. FWIW, I'm the maintainer of the Queue module. |
And so, do you agree with the change? |
Other modules that should use a monotonic clock instead of the system time:
|
I don't think *trace* and *timeit* should be changed. |
Why do you think monotonic time is needed for the Queue module? If time.time() goes backwards for some reason, the only consequence is that the timeouts take longer to cross the timeout boundard. On the other hand, it monotonic is used, then time won't go backwards but it won't go forwards either, so the consequence is the same. AFAICT, this patch doesn't fix any bug and doesn't make the module better in any observable way. |
The duration of a timeout of N seconds should be N seconds even if the system clock is updated (e.g. a daylight saving time (DST) change). This feature is checked by an unit test in the patch attached to the isuse bpo-14428 (implementation of the PEP-418): + def test_monotonic_settime(self): You can imagine a similar patch for Queue timeout. |
Oops: You can imagine a similar *test* for Queue timeout. |
[Victor]
IIRC, time.time() is not a local time and it is unaffected by a DST change. |
I'm closing this one. The "not subject to adjustment" property is more desirable than not. The "undefined reference point" property isn't harmful in this context (the start time isn't exposed). I'll follow the python-dev thread and re-open this if it becomes clear that there are any issues for steady() being used for timeout logic. |
So you're closing the issue while you're in agreement with it? |
This still appears to be an issue in Python 2.7. Queue.get routinely hangs for a very long time on the Raspberry Pi as it doesn't have a clock battery and often ends up significantly adjusting its system time soon after startup. |
You should upgrade to python 3.3! The PEP-418 mentions different available |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: