Re: Avoiding microtime(9) global state

On Wed, 30 Jun 2004, Martin Husemann wrote:

> On Wed, Jun 30, 2004 at 09:55:15AM -0500, Frederick Bruckman wrote:
>
>> I think it would be cleaner to simply drop the monoticity requirement
>> of microtime(), and create a microtime1() for any callers that really
>> need the old semantics.
>
> That's equivalent, only with different names, to what I tried to say.
> Fine with me.

Maybe we should also throw in a monotime(), for when true high-res 
monotonic time is wanted? One of those three functions should pretty 
much give any existing customers of microtime() what they really want.

> David Leight suggested that it might be a good idea to drop any notion of
> wall clock time while changing microtime() - letting it return "system up
> time" instead. The (few) callers that are interested in real (external) time
> could add the offset itself.

I think that's too radical, and that it would complicate things 
immensely. It would add overhead to every call to timing-critical 
clock_gettime(). More importantly, remember that microtime() is just 
a selector for a grab bag of architecture-specific functions. At first 
cut, microtime(), microtime1(), and monotime() could all point to the 
same functions that microtime() points to now, and any breakage would 
be limited to platforms that try to implement the distinction. You 
can't do that if you change the semantics too much.

Frederick