[EMAIL PROTECTED] wrote:
I would not support this change, simply because I don't see it making a
huge difference. We are better off fixing the apr_time_t implementation
and then looking for things like this.
I agree. Once we go to the binary microsecond implementation,
what we'll be able to do within poll is:
- extract the microseconds with a bitwise AND (encapsulated within
apr_time_usec())
- cast to 32 bits if the macro doesn't do so automatically
- then do a 32-bit division by 1000 to get milliseconds (which
is a lot cheaper than the current 64-bit division on 32-bit
platforms)
Or make apr_interval_time a 32-bit value to begin with. :-)
My only objection to using a 32-bit apr_interval_time is that
a main reason for using a scalar representation for times is
to make it easy to do math using the native arithmetic operators.
If apr_interval_time were a 32-bit count of microseconds, we
wouldn't be able to add it to apr_[whatever_we_call_time_now]_t
without a conversion macro.
--Brian