C9x <time.h> and clock precision
Paul Eggert
eggert at twinsun.com
Wed Oct 7 09:01:24 UTC 1998
Date: Tue, 06 Oct 1998 15:05:14 +0100
From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>
an API that does not provide this low-level control over timing
hazards can[not] be useful for sub-nanoseconds measurements
I agree, but it seems to me that an implementation should be able to
supply such low-level control, perhaps as implementation-defined
TIME_xxx flags passed to xtime_get.
you will never want to use anything like xtime_get() itself as a
source of sub-nanosecond timing information.
I'm not sure that I agree with the ``never'', as clocks will keep
getting better and better, and eventually (I hope within my lifetime
:-) places outside the PTB will break the 1ns barrier. And I would
like the spec to be modified so that xtime_get(TIME_MONOTONIC) can be
compiled to a single instruction accessing the hardware clock
register directly, which will make sub-ns access more practical.
Also, we must distinguish between the overhead of calling xtime_get(),
and the precision of the result. For some applications, it's enough
that xtime_get() returns a precise value even if the amount of time
that it takes to invoke xtime_get() is greater than the precision.
All that's needed is that the clock had the reported value at some
time during the invocation of xtime_get(). (Hmm, perhaps the spec
should say something about this?)
I am starting to get concerned that I might have wasted a lot of time
while working on this, especially since I didn't get any feedback yet
from the only ISO C committee member on this list.
I also hope that your time wasn't wasted, but I don't think that the
C9x is the only avenue for your work to be exploited. If we can get
this into the GNU C library, for example, a lot of users will have it
available in fairly short order. This will help convince the ISO C
committee the next time around.
More information about the tz
mailing list