[Python-Dev] PEP 418: Add monotonic clock (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Mar 28 18:14:11 CEST 2012

On Thu, Mar 29, 2012 at 1:47 AM, Guido van Rossum <guido at python.org> wrote:

Where in the stdlib? (I'm aware of threading.py. Any other places?)

Victor had at least one other example. multiprocessing, maybe? I believe the test suite may still have a few instances as well.

But now consider a caching clock, and consider that the system clock made a jump backwards before this function is called. The cache prevents us from seeing it, so the initial call to now() returns the highest clock value seen so far. And until the system clock has caught up with that, now() will return the same value over and over -- so WE STILL WAIT TOO  LONG.

Ouch. OK, I'm convinced the caching fallback is worse than just falling back to time.time() directly, which means the naming problem needs to be handled another way.

My conclusion: you can't win this game by forcing the clock to return a monotonic value. A better approach might be to compute how many sleep(eps) calls we're expected to make, and to limit the loop to that -- although sleep() doesn't make any guarantees either about sleeping too short or too long. Basically, if you do sleep(1) and find that your clock didn't move (enough), you can't tell the difference between a short sleep and a clock that jumped back. And if your clock moved to much, you still don't know if the problem was with sleep() or with your clock.

With your point about the problem with the naive caching mechanism acknowledged, I think we can safely assign time.monotonic() as the name of the OS provided monotonic clock.

That means choosing a name for the version that falls back to time() if monotonic() isn't available so it can be safely substituted for time.time() without having to worry about platform compatibility implications. I don't like Victor's current "hires" (because it doesn't hint at the fallback behaviour, may actually be the same res as time.time() and reads like an unrelated English word). My own suggestion of "try_monotic()" would get the job done, but is hardly going to win any API beauty contests.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list