classification
Title: NewGIL should use CLOCK_MONOTONIC if possible.
Type: behavior Stage:
Components: None Versions: Python 3.3, Python 3.2
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: anacrolix, haypo, lemburg, naoki, neologix, pitrou
Priority: normal Keywords: patch

Created on 2011-08-23 07:43 by naoki, last changed 2012-03-15 01:22 by haypo.

Files
File name Uploaded Description Edit
use_monotonic_clock.patch naoki, 2011-08-23 07:43 review
Messages (9)
msg142789 - (view) Author: INADA Naoki (naoki) * 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 (haypo) * (Python committer) Date: 2011-08-23 07:59
See also #10278.
msg142856 - (view) Author: Charles-Fran├žois Natali (neologix) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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 (haypo) * (Python committer) 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) * (Python committer) 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 (haypo) * (Python committer) 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 (haypo) * (Python committer) Date: 2012-03-15 01:22
See also #14222. Python 3.3 has a new time.steady() function.
History
Date User Action Args
2012-03-15 01:22:35hayposetmessages: + msg155837
2011-11-28 23:54:44hayposetmessages: + msg148529
2011-11-28 23:52:36pitrousetmessages: + msg148528
2011-11-28 23:46:55hayposetmessages: + msg148525
2011-11-26 01:09:19anacrolixsetnosy: + anacrolix
2011-08-23 19:15:12lemburgsetnosy: + lemburg
messages: + msg142859
2011-08-23 19:03:42pitrousetnosy: + pitrou
messages: + msg142858
2011-08-23 18:54:28neologixsetnosy: + neologix
messages: + msg142856
2011-08-23 07:59:58hayposetmessages: + msg142791
2011-08-23 07:59:35hayposetnosy: + haypo
2011-08-23 07:43:36naokicreate