apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: cvs commit: apr-site versioning.html
Date Tue, 13 Aug 2002 20:08:07 GMT
rbb@apache.org wrote:

>>Toward the end of that last round of discussions, I thus proposed
>>that APR get out of the business of managing microseconds:
>>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

>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

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


View raw message