On Thu, Mar 29, 2012 at 1:47 AM, Guido van Rossum <gu...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
