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.


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.


> ....Roy

View raw message