Subject: Re: Avoiding microtime(9) global state
To: Simon Burge <firstname.lastname@example.org>
From: Frederick Bruckman <email@example.com>
Date: 07/01/2004 11:50:22
On Thu, 1 Jul 2004, Simon Burge wrote:
> Frederick Bruckman wrote:
>> CLOCK_HIGHRES sounds like the same thing as POSIX' CLOCK_MONOTONIC,
>> which we have.
> Note that Solaris' CLOCK_HIGHRES is defined as monotonic and linear
> (as Bill Sommerfeld mentioned - it's not affected by adjtime() et
> al), whereas our CLOCK_MONOTONIC is just monotonic. It is however
> recommended in SUSv3 that CLOCK_MONOTONIC be linear:
> Additionally, it is desirable (but not required by IEEE Std
> 1003.1-2001) that the monotonic clock increases its value uniformly.
In the man page for clock_settime(), Issue 6, there is added:
Note that the absolute value of the monotonic clock is
meaningless (because its origin is arbitrary), and thus
there is no need to set it...
So I infer the idea is that mono_time should be time since boot, so
that anyone attempting to use it for ToD improperly will be quickly
educated. That would be the basis for CLOCK_MONOTONIC.
CLOCK_REALTIME should give no guarantees of monoticity, "of course",
(with "of course" in quotes, because on NetBSD, it currently uses
Is there any use for the old microtime() semantics -- a CLOCK_BSD --,
or any form of them? What possible code can't tolerate small backwards
jumps, but can tolerate large ones? Observe that any large backward
jump will look just like a small backward jump for some specific
period of time in the future.