a new proposal Re: Earth to APR????

[Brian Pane]

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
    them:
        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 
milliseconds
    to avoid a division by 1,000, since poll is such an important special
    case.)

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.
--Brian