[EMAIL PROTECTED] wrote:
yOn Tue, 13 Aug 2002, Brian Pane wrote:
[EMAIL PROTECTED] 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
