Subject: Re: Avoiding microtime(9) global state
To: Martin Husemann <firstname.lastname@example.org>
From: Frederick Bruckman <email@example.com>
Date: 06/30/2004 10:47:58
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.