Date: Tue, 06 Oct 1998 15:05:14 +0100 From: Markus Kuhn <Markus.Kuhn@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.