(original) (raw)

I believe we should make a monotonic\_time method that assures monotonicity and be done with it. Forward steadiness can not be guaranteed. No parameters.

On Mar 20, 2012 2:56 PM, "Steven D&apos;Aprano" <steve@pearwood.info> wrote:
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

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
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/anacrolix%40gmail.com