apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: Versioning before time please
Date Thu, 15 Aug 2002 03:03:19 GMT
Roy T. Fielding wrote:

> Oh, for crying out loud.  Apps do not need microsecond resolution for
> time since epoch.  None of them do.


I agree strongly with Roy's main argument, although I
have objections to this particular part.

I can think of examples where apps need the time since
the epoch in subsecond resolution.  Higher-resolution
loggers, unique ID generation, computing elapsed time
for internal performance monitoring, etc.

However, for all of these cases, the interface provided
by gettimeofday() works just fine: provide a time_t and
a microseconds value separately, and let the app decide
what to do with the microseconds (where "ignore the
microseconds completely" is a valid answer for some apps).
The problem with APR is that it does arbitrary and expensive
transformations on the data (64-bit math to combine together
the seconds and microseconds).

>   They need microsecond resolution
> for small interval timers.  The vast majority of APR time usages are for
> epoch times or intervals in seconds.  There is nothing that the app can
> do to "work around" APR's funky data type because APR forces the
> conversion on every function whether that function needs microseconds
> or not.  Using raw time_t is not an option because APR is supposed to
> be providing an interface to a time_now function that is portable.
> The fact of the matter is that using the same data structure for two
> different purposes is the wrong design for the portability library's
> basic interface to time, which is why none of the operating systems
> work that way.
>
> The trade-off is obvious -- just look at the profile results.  If you
> aren't willing to use that as the determinant of which interface is
> better, then we shouldn't be using APR for a Web server.


+1

I really think APR should follow the model that's worked
well for Unix:
  - A gettimeofday function returns separate values for
    time_t and microseconds.
  - All APIs that involve a timestamp use just a time_t.
  - If an application needs to make use of the microsecond
    data (e.g., a JVM built on top of APR that needs to
    support Java-style millisecond-resolution time objects),
    it's up to the application programmer to manipulate the
    microseconds in whatever manner is most appropriate,
    based on the specific functional and performance needs
    of that app.

Brian

> ....Roy





Mime
View raw message