[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)
cs at zip.com.au
Sun Apr 8 06:00:14 CEST 2012
On 07Apr2012 18:49, Guido van Rossum <guido at python.org> wrote:
| 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.
Except for calendar programs setting alarms:-) I suppose they wake up
regularly and consult local time anyway.
| > 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.
I saw it but didn't know what I could do with it, or even if it can be
found out in any very general sense.
Looking at nanosleep(2) on a recent Linux system says:
POSIX.1 specifies that nanosleep() should measure time against the
CLOCK_REALTIME clock. However, Linux measures the time using the
CLOCK_MONOTONIC clock. This probably does not matter, since the
POSIX.1 specification for clock_settime(2) says that discontinuous
changes in CLOCK_REALTIME should not affect nanosleep():
Setting the value of the CLOCK_REALTIME clock via clock_settime(2)
shall have no effect on threads that are blocked waiting for a relative
time service based upon this clock, including the nanosleep() function;
... Consequently, these time services shall expire when the requested
relative interval elapses, independently of the new or old value
of the clock.
and POSIX's nanosleep(3p) says:
... except for the case of being interrupted by a signal, the suspension
time shall not be less than the time specified by rqtp, as measured by the
system clock CLOCK_REALTIME.
| > 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
| to hours).
In my view it depends on whether you're working in a calendar or in
elapsed time. The scheduling range ("far in the future" for example)
shouldn't be relevant, for all that "far in the future" is usually done
with a calendar instead of a relative timespans in flat seconds.
| > 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 it is confusing given some more context; to me it would
usually be a Big Clue that the internal supposedly-wallclock got a big
adjustment between log timestamps. If that shouldn't happen it may be
confusing or surprising...
Cameron Simpson <cs at zip.com.au> DoD#743
The street finds its own uses for things. - William Gibson
More information about the Python-Dev