[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




Reply via email to