wrowe 2002/07/11 09:27:52
Modified: . STATUS
Log:
FirstBill says longlong integer divisions are near gone. Change the
vote to keeping apr_time_t v.s. renaming apr_butime_t, apr_busec_t
or any other name you care to propose.
Revision Changes Path
1.134 +13 -13 apr/STATUS
Index: STATUS
===================================================================
RCS file: /home/cvs/apr/STATUS,v
retrieving revision 1.133
retrieving revision 1.134
diff -u -r1.133 -r1.134
--- STATUS 28 Jun 2002 23:15:19 -0000 1.133
+++ STATUS 11 Jul 2002 16:27:52 -0000 1.134
@@ -58,18 +58,18 @@
CURRENT VOTES:
- * apr_time_t has proven to be a performance problem in some key
- apps (like httpd-2.0) due to the need for 64-bit division to
- retrieve the seconds "field." Alternatives that have been
- discussed on [EMAIL PROTECTED] are:
- 1) Keep the 64-bit int, but change it to use binary microseconds
- (renaming the function to get rid of apr_time_t vs time_t confusion,
- and having macros to convert BUSEC to USEC and back if need be)
- +1: BrianP, Cliff, Brane, rbb, Jim, Thom
- 2) Add a separate data type (and supporting functions) for seconds only
- -0: Cliff, Brane, rbb, Jim
- 3) Replace it with a struct with separate fields for sec and usec
- -0: BrianP, Cliff, Brane, rbb, Thom
+ * apr_time_t will change to use binary microseconds based on
+ profiling. The last remaining question on the table is keeping
+ the apr_time_t designation, or changing the symbol name.
+ 1) Keeping the existing apr_time_t names, in spite of potential
+ ANSI/C99 time_t confusion. apr_types don't promise to be
+ system types, or map to system units.
+ +1: rbb, wrowe
+ 2) Renaming the function to get rid of apr_time_t vs time_t confusion,
+ which wrowe suggests apr_butime_t [binary microtime].
+ +1: fielding
+ -0: wrowe
+ -0.5: rbb
* For the atomics code to be efficient it depends on instructions
in newer sparc models. Unfortunately this means that binaries
