apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: apr_time_t --> apr_time_usec_t
Date Mon, 10 Jun 2002 23:11:09 GMT
Justin Erenkrantz wrote:

>>Ryan Bloom wrote:
>>
>>This is going to break EVERY apr app out there.  I have no problem with
>>the change, but everything is going to be broken.  Is there any way to
>>do this by creating an apr_time32_t, or something that will keep the
>>default at 64-bit, and allow people to use 32 if they specify it?
>>    
>>
>
>How about using the value we already have:
>
>typedef apr_int32_t apr_short_interval_time_t;
>
>And, since there *are* processors that are 64-bit out there, I'm
>not entirely sure if it makes sense for us to go back to 32-bit
>for performance reasons.  -- justin
>  
>

I think it's better to maintain the microseconds part, but to split
the seconds and microseconds into separate fields in a timeval structure.

Sometimes we actually want microseconds.  They're useful, for example,
when generating unique IDs or when doing custom performance monitoring.
Most of the time, in the httpd at least, we just want seconds.  We get
both for free from gettimeofday(), so why not keep both?

Also, apr_short_interval_time_t isn't really a good choice for holding
a time_t.  That signed 32-bit int is going to overflow in 2038.

--Brian




Mime
View raw message