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

Scott Dial scott+python-dev at scottdial.com
Wed Mar 28 11:37:34 CEST 2012

On 3/28/2012 4:48 AM, Victor Stinner wrote:

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 CLOCKMONOTONIC 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

I agree. The point I was making is that implication of "steady" is that (t2-t1) is the same (given that t2 and t1 occur in time at the same relative moments), which is a guarantee that I don't see any platform providing currently. Any clock that can be "adjusted" in any manner is not going to meet the "steady" criterion.

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. 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 sympathize with this, but if the idea is that the Python stdlib should use time.monotonic() for scheduling, then it needs to always be available. Otherwise, we are not going to use it ourselves, and what sort of example is that to set?

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?

If "time.monotonic()" is only sometimes available, then I don't see the added clock being anything more than an amusement. (In this case, I'd rather just use clock_gettime() and friends directly, because I have to be platform aware anyways.) What developers want is a timer that is useful for scheduling things to happen after predictable interval in the future, so we should give them that to the best of our ability.

-- Scott Dial scott at scottdial.com

More information about the Python-Dev mailing list