Hi Paul,
What do you think of making gethrxtime fall back on gettime?
Currently, if it can't find a monotonic timer, it tries gettimeofday,
then resorts to using time. Those are also the last resorts of
gettime. The difference is that if gethrxtime used gettime,
it'd benefit by using nanotime or clock_gettime (CLOCK_REALTIME,
if present, before using the fallback functions.
Presuming you want to keep the current behavior where gethrxtime may fall
back on using a probably-non-monotonic clock, the comment in gethrxtime.h
/* Get the current time, as a count of the number of nanoseconds since
an arbitrary epoch (e.g., the system boot time). This clock can't
be set, is always increasing, and is nearly linear. */
should be changed to read more like the one in gethrxtime.c --
or removed altogether.
While we're on the subject, how about removing gettime's use
of time? If there is a system lacking all of the preceding
functions, then we should find/use a function it does provide
that has some sub-second precision rather than using `time (NULL)',
which has none. Then we could say that the function is guaranteed
to provide at least nominal sub-second precision.
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
