time.h design issues

Paul Eggert eggert at twinsun.com
Sun Aug 29 21:25:49 UTC 1999


   From: Ulrich Drepper <drepper at cygnus.com>
   Date: 29 Aug 1999 09:56:37 -0700

   I hope you suggest an implementation for a monotonic time
   implementation.  Constraints are:

     The underlying OS will not notify each running program about a sudden
     clock change and itself does not provide a monotonic clock.

TIME_MONOTONIC is optional; if the OS does not support TIME_MONOTONIC,
then xtime_get (TIME_MONOTONIC | ...) returns an error indication.

Kuhn's hope is that OS and C library suppliers can find their way to
support TIME_MONOTONIC.  I'm not an expert on GNU/Linux, but I believe
that there's currently an awful way to get a TIME_MONOTONIC clock --
namely, read /proc/uptime.  Clearly this could be improved by
providing a more efficient way to get at the freerunning clock that's
running inside the kernel.  I expect that a small, well-thought-out
patch to do this would be acceptable to the Linux kernel hackers.
I expect other Unix kernels would be similar.

   I think about things like the time stamp counters found on many
   modern processors.  But:

   - they are only found on modern processors, and therefore a generic
     implementation isn't possible

Absolutely.  

   - even if they are available, they might be useless if, as in the case
     of the Alpha, the counter range is too small

That's a problem.  (I wonder why the Alpha doesn't have a 64-bit clock?)
Presumably on the Alpha one would have to fall back on a lower-resolution
monotonic clock, e.g. the number of clock interrupts serviced by the kernel.

As Kuhn mentions, there is certainly a need for a TIME_MONOTONIC in
some applications.  The question is whether this need is enough to
justify inclusion in a standard API.



More information about the tz mailing list