On 3/27/2012 8:36 PM, Victor Stinner wrote: > Scott wrote: > 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. > > I don't know if other clocks used by my time.monotonic() proposition can > be adjusted or not. > > If I understand correctly, time.steady() cannot be implemented using > CLOCK_MONOTONIC on Linux because CLOCK_MONOTONIC can be adjusted? > > Does it really matter if a monotonic speed is adjusted?
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. I am not familiar enough with Windows or Mac to know for certain whether the Boost implementation has the correct behaviors either. With that in mind, it's certainly better that we just provide time.monotonic() for now. If platform support becomes available, then we can expose that as it becomes available in the future. In other words, at this time, I don't think "time.steady()" can be implemented faithfully for any platform so lets just not have it at all. 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. 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. -- Scott Dial sc...@scottdial.com _______________________________________________ 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
