Greg Ewing wrote:
Cameron Simpson wrote:
A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
polls of the clock. On its own it says nothing about steadiness or
correlation with real world time.
No, no, no.
This is the strict mathematical meaning of the word "monotonic",
but the way it's used in relation to OS clocks, it seems to
mean rather more than that.
A clock whose only guarantee is that it never goes backwards
is next to useless. For things like benchmarks and timeouts,
the important thing about a clock that it *keeps going forward*
That would be a *strictly* monotonic clock, as opposed to merely monotonic.
And yes, a merely monotonic clock could just return a constant value, forever:
9, 9, 9, 9, 9, ...
and yes, such a thing would be useless.
Various people have suggested caching the last value of time() and re-using it
if the new value is in the past. This will give a monotonic clock, but since
it can give constant timestamps for an indefinite period, it's usefulness is
limited.
I earlier put forward an alternate implementation which gives no more than one
such constant tick in a row. If you know the hardware resolution of the clock,
you can even avoid that single constant tick by always advancing the timestamp
by that minimum resolution:
_prev = _prev_raw = 0
_res = 1e-9 # nanosecond resolution
def monotonic():
global _prev, _prev_raw
raw = time()
delta = max(_res, raw - _prev_raw)
_prev_raw = raw
_prev += delta
return _prev
Even if time() jumps backwards, or stays constant, monotonic() here will be
strictly monotonic.
--
Steven
_______________________________________________
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
