apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject a new proposal Re: Earth to APR????
Date Tue, 16 Jul 2002 00:35:07 GMT
Actually, now that I think about it, I have a solution
in mind: we (APR) should get out of the business of
providing microsecond time manipulation.

Here's my rationale...

What added value can APR provide to applications that need
to work with time?
   - Getting the current time in a portable manner?  Yes.
   - Converting timestamps to date/time form in a portable
     manner?  Yes.
   - Doing arithmetic on times?  Not really.  Every solution
     we've found for representing a microsecond-resolution time
     has a performance tradeoff somewhere: either in extracting
     seconds (current apr_time_t), or in extracting microseconds
     (busec representation), or in addition and subtraction
     (struct representation).  Which of these operations can we
     afford to make slower in order to speed up the other ops?
     I don't know.  It depends on the application.

Based on these observations, I think it's important that APR
be able to provide a portable way to look up the current time
with microsecond resolution, but APR need not do all the rest
of its time operations in microseconds.

Here's a design that I think would be a reasonable compromise:

   - apr_time_t becomes a 64-bit uint representing seconds
     since the epoch.  (Maybe it's typedef'ed to time_t.  Maybe
     not.  Let's worry about that *after* we figure out the
     desired semantics.)

   - apr_time_now() returns a time_t, but it also returns
     the microseconds as a separate value for apps that need
         apr_status_t apr_time_now(apr_time_t *sec, apr_uint32_t *usec);
     Note: We could also keep apr_time_now() unchanged and add a
     different function that would provide seconds and microseconds.
     There are pros and cons for both.

   - All the time-maniuplation functions that currently use
     apr_time_t continue to use apr_time_t.  (As far as I can
     tell, none of them really need microseconds.)

   - Interval times are expressed as an integer count of microseconds.
     (We *might* want to let apr_poll() take an integer count of 
     to avoid a division by 1,000, since poll is such an important special

With this model, we can add one more field to the httpd's request_rec
to hold the microseconds part of the request_time.  The httpd core won't
care about it, but custom modules that need more granular time (e.g., for
special-purpose logging or session ID generation) will have access to it.

Apps that need to work with microsecond resolution can choose their own
time representation, based on whatever is best suited to the needs of
the app: structure, binary microseconds, even convert to floating-point.


View raw message