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
Don't block on Queue get/put when time is moved back #44783
Comments
When Queue get and put methods are called with a timeout, they effectively store the end time and might block until that end time is reached. This breaks if the system time is moved back. The attached patch breaks out of the wait if it detects the time has been moved back. |
I am unsure if this is a sufficient or correct patch, but the functionality is desirable. |
When a system moves time backwards, it breaks a host of invariants, not just the one in the queue module. I would not want some variant of this code used everywhere time differences are computed. Another thought is that the use case is somewhat exceptional and that the solution (readjusting endtime) isn't necessarily the right thing to do. |
I agree that it would be better to fix this everywhere we can. But unless we start replacing the generic versions of everything that uses a timeout for platform-specific versions (that have guarantees regarding specified timeouts and notifications), about all we can really do is to patch each item as we go along. I suppose a good first step would be to write a generic "wait for" function that would sit in threading, _Condition.wait() is a good start. From there, one could write platform variants (Windows could use WaitForSingleObject, etc.) that don't change the end time, calling them on a platform if they exist. |
I was recommending against "fixing" this everywhere. See related comments on pathc bpo-1607149: Condition.wait timeout fails on clock change. Recommend closing this patch. The problem is not the responsibility of every client accessing time() or sleep(). The clients do not have enough information to reliably detect changes and to know how much the time changed. Even if those are known, it is not clear that adjusting the timeout is the always right thing to do. Also, this "problem" is somewhat obscure. Lowering the priority to 1 and recommending that the patch (and all like it) be rejected. |
Rejecting this patch for the same reason bpo-1607149 was rejected. |
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: