[Python-Dev] PEP 418: Add monotonic clock (original) (raw)

Victor Stinner victor.stinner at gmail.com
Wed Mar 28 10:48:04 CEST 2012

Scott> monotonicclock = always goes forward but can be adjusted Scott> steadyclock = always goes forward and cannot be adjusted

I don't know if the monotonic clock should be called time.monotonic() or time.steady(). The clock speed can be adjusted by NTP, at least on Linux < 2.6.28. (...) You are right that CLOCKMONOTONIC can be adjusted, so the Boost implementation is wrong. I'm not sure that CLOCKMONOTONICRAW is right either due to suspend -- there doesn't appear to be a POSIX or Linux clock that is defined that meets the "steady" definition.

The term "adjusted" should be clarified. A clock can be adjusted by setting its counter (e.g. setting the system date and time) or by changing temporary its frequency (to go faster or slower). Linux only adjusts CLOCK_MONOTONIC frequency but the clock is monotonic because it always goes forward. The monotonic property can be described as:

t1=time.monotonic() t2=time.monotonic() assert t2 >= t1

In that case, I don't think time.trymonotonic() is really needed because we can emulate "time.monotonic()" in software if the platform is deficient.

time.hires() is needed when the OS doesn't provide any monotonic clock and because time.monotonic() must not use the system clock (which can jump backward).

As I wrote, I don't think that Python should workaround OS bugs. If the OS monotonic clock is not monotonic, the OS should be fixed.

I can't imagine a scenario where you would ask for a monotonic clock and would rather have an error than have Python fill in the gap with an emulation.

Sorry, I don't understand what you mean with "fill in the gap with an emulation". You would like to implement a monotonic clock based on the system clock?

Victor

More information about the Python-Dev mailing list