time.h design issues
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
- 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