rbb@apache.org wrote:

>yOn Tue, 13 Aug 2002, Brian Pane wrote:
>
>  
>
>>rbb@apache.org wrote:
>>
>>    
>>
>>>>To use time_t in a portable app, though, I expect that we'll still
>>>>need to rely on APR to provide a portability wrapper.  The code for
>>>>even simple things like getting the current time is different between
>>>>Unix and Win32.   (I wouldn't mind leaving apr_time_t as-is if we
>>>>also had a portable second-resolution time API to complement it.)
>>>>   
>>>>
>>>>        
>>>>
>>>I'm sorry, but that just isn't true.  Apache 1.3 had no problem with time
>>>function portability.
>>>
>>>      
>>>
>>Sure it did.  Apache 1.3 had to use platform-specific ifdefs 
>>(NO_GETTIMEOFDAY
>>et al.) throughout the application code in order to do time operations.
>>    
>>
>
>Yep, you are correct, when Apache 1.3 wanted microseconds we needed
>portability code to acheive that.  However, when Apache 1.3 wanted
>seconds, it just used time(), without any #ifdefs.  Since APR is now
>providing the microsecond logic, we only need to be concerned with
>seconds, which is standardized as a part of POSIX.
>

But we can't use time() in 2.0.  time() runs quite a bit slower than
gettimeofday() on many systems.  On Solaris, for example, gettimeofday()
is optimized so that it doesn't require a trip into kernel space (you'll
never see it in the output of truss, for example), whereas time() requires
the full overhead of a syscall.

Apps also can't rely on APR to get the microseconds--not as long as the
only way to get the seconds from APR is in the form of an apr_time_t,
which requires the caller to do a 64-bit modulo.

I think we need

  apr_gettimeofday(time_t *sec, apr_uint32_t *usec)

as a complement to the apr_time_t API.

Brian