[Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
Guido van Rossum
guido at python.org
Sun Apr 8 03:49:53 CEST 2012
On Sat, Apr 7, 2012 at 6:26 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> Just to clarify my previous post.
> It seems clear that benchmarking and timeout logic would benefit from a clock that cannot be adjusted by NTP.
> I'm unclear on whether time.sleep() will be based on the same clock so that timeouts and sleeps are on the same basis.
I made the same suggestion earlier but I don't know that anyone did
anything with it. :-( It would be nice to know what clock sleep() uses
on each of the major platforms.
> For scheduling logic (such as the sched module), I would think that NTP adjusted time would be what you want.
In my view, it depends on whether you are scheduling far in the future
(presumably guided by a calendar) or a short time ahead (milliseconds
> I'm also unclear on the interactions between components implemented with different clocks
> (for example, if my logs show three seconds between events and a 10-second time-out exception occurs, is that confusing)?
I don't think this is avoidable. The logs will always use time.time()
or a local time derived from it; but we've accepted that for
benchmarking, timeouts and short-interval scheduling, that's not a
good clock to use.
--Guido van Rossum (python.org/~guido)
More information about the Python-Dev