On Wed, Mar 28, 2012 at 7:17 AM, Nick Coghlan
On Wed, Mar 28, 2012 at 8:56 PM, Victor Stinner
wrote: 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.
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?
There is time.hires() if you need a monotonic clock with a fallback to the system clock.
Completely unintuitive and unnecessary. With the GIL taking care of synchronisation issues, we can easily coerce time.time() into being a monotonic clock by the simple expedient of saving the last returned value:
def _make_monotic: try: # Use underlying system monotonic clock if we can return _monotonic except NameError: _tick = time() def monotic(): _new_tick = time() if _new_tick > _tick: _tick = _new_tick return _tick
monotonic = _make_monotonic()
Monotonicity of the result is thus ensured, even when using time.time() as a fallback.
If using the system monotonic clock to get greater precision is acceptable for an application, then forcing monotonicity shouldn't be a problem either.
That's a pretty obvious trick. But why don't the kernels do this if monotonicity is so important? I'm sure there are also downsides, e.g. if the clock is accidentally set forward by an hour and then back again, you wouldn't have a useful clock for an hour. And the cache is not shared between processes so different processes wouldn't see the same clock value (I presume that most of these clocks have state in the kernel that isn't bound to any particular process -- AFAIK only clock() does that, and only on Unixy systems). -- --Guido van Rossum (python.org/~guido)