Nick Coghlan wrote:
Completely unintuitive and unnecessary. With the GIL taking care of
synchronisation issues, we can easily coerce time.time() into being a
monotonic clock by the simple expedient of saving the last returned
value:
[snip]
Here's a version that doesn't suffer from the flaw of returning a long stream
of constant values when the system clock jumps backwards a significant amount:
class MockTime:
def __init__(self):
self.ticks = [1, 2, 3, 4, 2, 3, 4, 5, 7, 3, 4, 6, 7, 8, 8, 9]
self.i = -1
def __call__(self):
self.i += 1
return self.ticks[self.i]
time = MockTime()
_prev = _prev_raw = 0
def monotonic():
global _prev, _prev_raw
raw = time()
delta = max(0, raw - _prev_raw)
_prev_raw = raw
_prev += delta
return _prev
And in use:
>>> [monotonic() for i in range(16)]
[1, 2, 3, 4, 4, 5, 6, 7, 9, 9, 10, 12, 13, 14, 14, 15]
Time: [1, 2, 3, 4, 2, 3, 4, 5, 7, 3, 4, 6, 7, 8, 8, 9]
Nick: [1, 2, 3, 4, 4, 4, 4, 5, 7, 7, 7, 7, 7, 8, 8, 9]
Mine: [1, 2, 3, 4, 4, 5, 6, 7, 9, 9, 10, 12, 13, 14, 14, 15]
Mine will get ahead of the system clock each time it jumps back, but it's a
lot closer to the ideal of a *strictly* monotonically increasing clock.
Assuming that the system clock will never jump backwards twice in a row, the
double-caching version will never have more than two constant values in a row.
--
Steven
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com