RetroSearch Browse

Fri Apr 6 04:23:07 CEST 2012 · https://mail.python.org/pipermail/python-dev/2012-April/118545.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-April/118545.html below:

[Python-Dev] PEP 418 is too divisive and confusing and should be postponed