From cvs-return-3750-apmail-apr-cvs-archive=apr.apache.org@apr.apache.org Thu Jul 11 16:27:53 2002 Return-Path: Delivered-To: apmail-apr-cvs-archive@apr.apache.org Received: (qmail 96498 invoked by uid 500); 11 Jul 2002 16:27:53 -0000 Mailing-List: contact cvs-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: dev@apr.apache.org Delivered-To: mailing list cvs@apr.apache.org Received: (qmail 96487 invoked from network); 11 Jul 2002 16:27:52 -0000 Date: 11 Jul 2002 16:27:52 -0000 Message-ID: <20020711162752.26110.qmail@icarus.apache.org> From: wrowe@apache.org To: apr-cvs@apache.org Subject: cvs commit: apr STATUS X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 dev@apr 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