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