[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)

[Cameron Simpson]

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.

Indeed.
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.

Raymond:
| > 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...

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

The street finds its own uses for things.       - William Gibson