Repository navigation
threading.Condition.wait(timeout) should use a monotonic clock: use pthread_condattr_setclock(CLOCK_MONOTONIC) #57031
Description
Activity
Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL
because settimeofday() may break the pthread_cond_timedwait().Attached patch uses CLOCK_MONOTONIC and clock_gettime. But I don't know
how to write appropriate configure script.
"-lrt" is also needed to use clock_gettime() but I don't know how to add
it to LIBS.- addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Aug 23, 2011 See also bpo-10278.
Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL
because settimeofday() may break the pthread_cond_timedwait().Indeed.
A couple remarks:- regular locks and conditions variables exposed by the threading module suffer from the same problem
- POSIX semaphores are also affected, but you can't select an alternative clock source
- actually, CLOCK_MONOTONIC is affected by NTP adjustements: while it's guaranteed not to go backward, its rate can be affected
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:
The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC is supported at build time.
I think we need both: a check at build time to avoid
compiler errors and a check at runtime whether the deployment
platform supports the clock, plus a fallback solution in case
it is not available.The patch is ok on the principle, but we do need a check
that CLOCK_MONOTONIC is supported at build time.timemodule.c is now using "#ifdef CLOCK_MONOTONIC".
Marc-Andre is right, a runtime check is probably also needed.
(for example with mismatching kernel/libc)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
macOS and iOS don't support pthread_condattr_setclock yet.- addedinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)3.8 (EOL)end of lifeend of life
on Jan 31, 2019 See also bpo-23428: "Use the monotonic clock for thread conditions on POSIX platforms".
Thanks INADA-san for fixing this old issue!
- changed the title
[-]NewGIL should use CLOCK_MONOTONIC if possible.[/-][+]threading.Condition.wait(timeout) should use a monotonic clock: use pthread_condattr_setclock(CLOCK_MONOTONIC)[/+]on Oct 1, 2021
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: