[Python-Dev] PEP 418: Add monotonic clock

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


>> Scott> monotonic_clock = always goes forward but can be adjusted
>> Scott> steady_clock = 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 CLOCK_MONOTONIC can be adjusted, so the Boost
> implementation is wrong. I'm not sure that CLOCK_MONOTONIC_RAW 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.try_monotonic() 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