msg142789 - (view) |
Author: Inada Naoki (methane) * |
Date: 2011-08-23 07:43 |
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. |
|
|
msg142791 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2011-08-23 07:59 |
See also #10278. |
|
|
msg142856 - (view) |
Author: Charles-François Natali (neologix) * |
Date: 2011-08-23 18:54 |
> 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? |
|
|
msg142858 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2011-08-23 19:03 |
The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC is supported at build time. |
|
|
msg142859 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2011-08-23 19:15 |
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. |
|
|
msg148525 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2011-11-28 23:46 |
> 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". |
|
|
msg148528 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2011-11-28 23:52 |
Marc-Andre is right, a runtime check is probably also needed. (for example with mismatching kernel/libc) |
|
|
msg148529 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2011-11-28 23:54 |
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." |
|
|
msg155837 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2012-03-15 01:22 |
See also #14222. Python 3.3 has a new time.steady() function. |
|
|
msg334621 - (view) |
Author: Inada Naoki (methane) * |
Date: 2019-01-31 11:19 |
ref: https://bugs.chromium.org/p/webrtc/issues/detail?id=9269 macOS and iOS don't support pthread_condattr_setclock yet. |
|
|
msg334623 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2019-01-31 11:33 |
See also bpo-23428: "Use the monotonic clock for thread conditions on POSIX platforms". |
|
|
msg336032 - (view) |
Author: Inada Naoki (methane) * |
Date: 2019-02-20 01:00 |
New changeset 001fee14e0f2ba5f41fb733adc69d5965925a094 by Inada Naoki in branch 'master': bpo-12822: use monotonic clock for condvar if possible (GH-11723) https://github.com/python/cpython/commit/001fee14e0f2ba5f41fb733adc69d5965925a094 |
|
|
msg336061 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2019-02-20 10:36 |
Thanks INADA-san for fixing this old issue! |
|
|