[Python-Dev] PEP 418 is too divisive and confusing and should be postponed

Cameron Simpson cs at zip.com.au
Fri Apr 6 03:50:17 CEST 2012

On 06Apr2012 13:14, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
| Cameron Simpson wrote:
| > A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
| > polls of the clock. On its own it says nothing about steadiness or
| > correlation with real world time.
| No, no, no.
| This is the strict mathematical meaning of the word "monotonic",
| but the way it's used in relation to OS clocks, it seems to
| mean rather more than that.

It's like my next paragraph didn't exist...

  _Quality of implementation_ says that the montonic() call should try to
  return a close that is monotonic and _also_ steady and preferably precise.
  How these things are balancer is a matter of policy.

To forstall things, right at the bottom of this I'm going to say i agree
with you about objectives, but not about terminology. I maintain that
"monotonic" still means what I said, and that it is the combination of
the word with "clock" that brings in your other criteria.

| A clock whose only guarantee is that it never goes backwards
| is next to useless. For things like benchmarks and timeouts,
| the important thing about a clock that it *keeps going forward*
| at a reasonably constant rate. [...]
| I'm assuming this is what Linux et al mean when they talk
| about a "monotonic clock", because anything else doesn't make
| sense.

This is why I say there's no global understanding. Why assume?
On a Linux box, "man 3 clock_getres" says (sorry, this is a bit wordy):

   All  implementations  support the system-wide real-time clock, which
   is identified by CLOCK_REALTIME.  Its time represents seconds and
   nanoseconds  since the Epoch.  When its time is changed, timers for
   a relative interval are unaffected, but timers for an absolute point
   in time  are affected.

   More  clocks may be implemented.  The interpretation of the
   corresponding time values and the effect on timers is unspecified.

   Sufficiently recent versions of glibc and the Linux kernel support
   the following clocks:

      System-wide real-time clock.  Setting this clock requires
      appropriate privileges.

      Clock that cannot be set and  represents  monotonic  time since
      some unspecified starting point.

   CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
      Similar  to  CLOCK_MONOTONIC, but provides access to a raw hard-
      ware-based time that is not subject to NTP adjustments.

      High-resolution per-process timer from the CPU.

      Thread-specific CPU-time clock.

The first paragraph is very clear about real time (wall clock, and what
time.time() does, being "seconds since the epoch"). The CLOCK_MONOTONIC*
modes clearly imply steadiness.

"man 3p clock_getres" (POSIX clock_getres) is even more verbose and general.

| So if we're going to use the term "monotonic" at all, I think we
| should explicitly define it as having this meaning, i.e.
| both mathematically monotonic and steady.

I think if it is too "unsteady" then it is not "time".

So I actually side with you in the requirement for a "clock", but
monotonic alone does not mean that. Quality of implementation _may_ mean
we don't offer something abjectly erratic.

| Failure to be clear
| about this has caused a huge amount of confusion in this thead
| so far.

And burdening the word "monotonic" itself with exciting new meanings
doesn't help. "monotonic clock", sure, _that_ has additional
connotations, but not just the word monotonic.

Cameron Simpson <cs at zip.com.au> DoD#743

We had the experience, but missed the meaning.  - T.S. Eliot

More information about the Python-Dev mailing list