>> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
