apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: [PATCH 3] example binary BUSEC for discussion
Date Thu, 11 Jul 2002 19:13:12 GMT
William A. Rowe, Jr. wrote:

> At 11:31 AM 7/11/2002, Brian Pane wrote:
>> I don't see a way to eliminate the "/ 1000" to convert usec to
>> msec.  But we may be able to do all the math in 32-bit mode, by
>> limiting the maximum timeout to the number of milliseconds that
>> will fit in 32 bits, which works out to a max timeout of about
>> 50 days.
> Actually, here is my current math, with optimized forms for specific
> situations we encounter often (aprox. limits are given in the macro 
> name).
> They break down to;
> apr_int32_t apr_time_sec_get(time)  deprecates apr_time_sec(time)
> apr_int32_t apr_time_msec_get(time) deprecates apr_time_msec(time)
> apr_int32_t apr_time_usec_get(time) deprecates apr_time_usec(time)
> apr_int32_t apr_time_nsec_get(time) deprecates apr_time_nsec(time)

Oh no, I just recently finished changing all the code to use
those now-deprecated macros. :-)

> apr_int64_t apr_time_as_sec(time)
> apr_int64_t apr_time_as_msec(time) or apr_time_as_272yrs_msec(time)
> apr_int64_t apr_time_as_usec(time) or apr_time_as_3mos_usec(time)
> apr_int64_t apr_time_as_nsec(time) or apr_time_as_2hrs_nsec(time) 

The naming convention is way too subtle:
   apr_time_[unit]_get     means 32-bit
   apr_time_as_[unit]      means 64-bit

How often do you anticipate that people will be using the
32-bit versions?  If it's not very often, then I'd rather
just supply the 64-bit versions in the API, because those
are the safe ones (no Y2038 problem).  People who really
need to do 32-bit math for performance reasons would have
to cast explicitly, but IMHO that's good because it forces
them to think more carefully about whether the loss of
precision is safe.


View raw message