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/archive%40mail-archive.com
