-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
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
threading.Condition.wait(timeout) should use a monotonic clock: use pthread_condattr_setclock(CLOCK_MONOTONIC) #57031
Comments
Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL Attached patch uses CLOCK_MONOTONIC and clock_gettime. But I don't know |
See also bpo-10278. |
Indeed.
Did you really encounter this problem, or is this just a theoretical concern? |
The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC is supported at build time. |
Antoine Pitrou wrote:
I think we need both: a check at build time to avoid |
timemodule.c is now using "#ifdef CLOCK_MONOTONIC". |
Marc-Andre is right, a runtime check is probably also needed. |
pthread_condattr_setclock() result should be checked. "The pthread_condattr_setclock() function may fail if: EINVAL The value specified by clock_id does not refer to a known clock, or is a CPU-time clock." |
See also bpo-14222. Python 3.3 has a new time.steady() function. |
ref: https://bugs.chromium.org/p/webrtc/issues/detail?id=9269 |
See also bpo-23428: "Use the monotonic clock for thread conditions on POSIX platforms". |
Thanks INADA-san for fixing this old issue! |
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: