From dev-return-7037-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Mon Jul 08 17:14:11 2002 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 15356 invoked by uid 500); 8 Jul 2002 17:14:11 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 15343 invoked from network); 8 Jul 2002 17:14:10 -0000 Errors-To: Message-Id: <5.1.0.14.2.20020708111957.02fa2e00@pop3.rowe-clan.net> X-Sender: wrowe%rowe-clan.net@pop3.rowe-clan.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Jul 2002 11:30:00 -0500 To: Brian Pane , dev@apr.apache.org From: "William A. Rowe, Jr." Subject: Re: next steps for changing apr_time_t? In-Reply-To: <1026114367.1420.13.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 02:46 AM 7/8/2002, you wrote: >Based on the votes in STATUS, there's a consensus in favor of changing >from the current apr_time_t implementation to a binary microseconds >implementation. Meanwhile, I've removed most of the dependencies on >the old design from the httpd-2.0 code. The next step doesn't require any of the decisions below, though I'll offer my comments and observations. First; You simply need to replace the macros with BUSEC computations. Don't bother with the symbol names. Then profile. I don't think anyone wants to consider this change until we know the performance impact :-) >A couple of important questions remain, though: > > How much will this impact other APR-based apps (SVN, Flood, etc), > and is now a good time to break things? > > Should the new data type still be called apr_time_t? (My own > preference is to change the name so that existing applications > will break predictably at compile time rather than unpredictably > at run time.) apr_time_t is what it is. But there are a few old-school coders who believe that apr_foo_t is nothing but a wrapper for the well-known foo_t. To appease everyone, we need to rename this more explicitly. I would suggest the final name of apr_time_busec_t (if we go with a busec implementation.) Do the same to all apr_time_xxx functions and macros. The other alternative for shorter names is apr_butime_ or apr_utime_ (binary or decimial micro-time units). Bill