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
