[EMAIL PROTECTED] wrote:

Toward the end of that last round of discussions, I thus proposed
that APR get out of the business of managing microseconds:

http://marc.theaimsgroup.com/?l=apr-dev&m=102678180413988

I'm interested in hearing people's comments on that proposal.



Doesn't that completely ignore Cliff's message early in this thread that specifically stated that he needed microsecond resolution?


No, it's actually a direct result of Cliff's message. As Cliff noted, there are apps out there that: 1) do need microsecond resolution and 2) need fast time arithmetic. None of the proposals that we've considered--the current apr_time_t, binary microseconds, or even a struct--provide good performance under all conditions. The binary microsecond representation, for example, allows for quick extraction of the time in seconds, but getting the microseconds requires an extra division. That's fine for some apps (like the httpd), but bad for any app that needs to extract the usec value more frequently.

The best thing to do is leave the representation of microsecond-
resolution times up to the app, so that the application developer
can pick the most effective design for the needs of that particular
program.

I continue to state that APR's time format should stay as it is.  If you
want seconds, use time_t.  The only change that I can see as appropriate,
is to make the interval_time_t a 32-bit value, which would mean that any
arithmetic on the intervals would be faster.  Apache, doesn't want (or
need) microsecond resolution, so it should use time_t, which
co-incidentally is now very easy to translate into an apr_interval_time_t
very quickly.  Since most, if not all, of the apr_functions should be
using apr_interval_time_t for the arguments, converting types should be
minimal.


That almost works, except that APR forces client apps to use apr_time_t. All the time formatting functions and file stat related functions, for example, use apr_time_t rather than time_t. These functions have no need for microsecond resolution, but at the moment they force the app to use a microsecond based time.

Brian





Reply via email to