RetroSearch Browse

Tue Mar 20 07:54:57 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-March/117822.html

On Mon, Mar 19, 2012 at 01:35:49PM +0100, Victor Stinner wrote:

> Said differently: time.steady(strict=True) is always monotonic (*),
> whereas time.steady() may or may not be monotonic, depending on what
> is avaiable.
> 
> time.steady() is a best-effort steady clock.
> 
> (*) time.steady(strict=True) relies on the OS monotonic clock. If the
> OS provides a "not really monotonic" clock, Python cannot do better.

I don't think that is true. Surely Python can guarantee that the clock 
will never go backwards by caching the last value. A sketch of an 
implementation:

def monotonic(_last=[None]):
    t = system_clock()  # best effort, but sometimes goes backwards
    if _last[0] is not None:
        t = max(t, _last[0])
    _last[0] = t
    return t

Overhead if done in Python may be excessive, in which case do it in C.

Unless I've missed something, that guarantees monotonicity -- it may not 
advance from one call to the next, but it will never go backwards.

There's probably even a cleverer implementation that will not repeat the 
same value more than twice in a row. I leave that as an exercise :)

As far as I can tell, "steady" is a misnomer. We can't guarantee that 
the timer will tick at a steady rate. That will depend on the quality of 
the hardware clock.

-- 
Steven

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

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

Add an optional strict argument to time.steady(), False by default