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: apr_time_t --> apr_time_usec_t
Date Tue, 11 Jun 2002 22:58:58 GMT
At 10:14 PM 6/10/2002, Brian Pane wrote:
>William A. Rowe, Jr. wrote:
>>At 09:31 PM 6/10/2002, I wrote:
>>>usec * 1048575 / 1000000 = busec
>>>bsec * 1000000 / 1048575 = usec
>>whoops, s/1048575/1048576/
>That's a major improvement.  I was going to complain about
>the need for both a 64-bit multiplication and a 64-bit
>division to do the conversion, but 1048576 only requires a
>In general, I like this design:
>* It combines most of the benefits of the "struct apr_timeval"
>  approach with most of the benefits of the current 
> seconds*1000000+microseconds
>  scalar representation.

However, we aught to define convenience macros;

#define APR_BUSEC_PER_SEC 1048576

#define APR_TIME_MAKE(sec, usec) (sec * APR_BUSEC_PER_SEC \
                                            + (usec * 1000000) / 

#define APR_TIME_SEC(time) ((time) / APR_BUSEC_PER_SEC)

#define APR_TIME_USEC(time) ((((usec) % APR_BUSEC_PER_SEC)  \
                                           * 1000000) / APR_BUSEC_PER_SEC)

>* And the transition is easy: just change APR_USEC_PER_SEC to 1048576
>  and tell all users of APR to recompile.

Not quite, simply dividing the time by APR_USEC_PER_SEC would give you seconds,
but taking the modulus APR_USEC_PER_SEC wouldn't give you decimal usec.

This is why I'd favor using APR_BUSEC_PER_SEC for the name, to prevent new

>+1 for the binary microseconds implementation
>-0 for continuing to call it apr_time_t

So it's time to invent the proper, new names and give it a whirl.  I'll 
commit such a patch
later tonight or so, depending on how things are going.  Feel free to beat 
me to it :-)
If we make it conditional on a compile switch, we can benchmark the difference.

View raw message