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






Reply via email to