apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: next steps for changing apr_time_t?
Date Mon, 08 Jul 2002 16:30:00 GMT
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


Mime
View raw message