Re: Avoiding microtime(9) global state

On Wed, 30 Jun 2004, Bill Sommerfeld wrote:

> > NetBSD should provide both facilities (ToD & interval time), and the
> > code we write needs to be clear about which it is using and why.
>
> indeed.  as another example, solaris's clock_gettime(3RT) supports
> CLOCK_REALTIME (wall clock ToD) and CLOCK_HIGHRES (interval time).
> the latter is not adjusted by adjtime or settimeofday or the like.

CLOCK_HIGHRES sounds like the same thing as POSIX' CLOCK_MONOTONIC,
which we have. What we do odd, is that CLOCK_REALTIME uses microtime()
under the hood, and microtime() currently carries the baggage for
monoticity which CLOCK_REALTIME shouldn't need.

> A third "timebase" of sorts is required by systems which use
> timestamp-based unique-id generators (including multics, apollo
> domain/os, DCE, and others; the DCE UUID has escaped as the M$ GUID
> but i'm not sure if those are time-based as well).  This requires that
> no two calls to the "gettime" function ever return the same value.
>
> At least some ports of BSD in the 4.2/4.3 timeframe implemented this
> property as part of microtime().

We did that, too, until very recently. monotonic time is weird, and
hardly anyone should use it, so we could just as well make it strictly
monotonic, which would cover the use you described.

While we're on this, we might as well go for true nanosecond
resolution, so we could leave microtime() alone, and the new kernel
functions might be called nanotime(), nanotime1() (and monotime()).

Frederick