apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject Re: cvs commit: apr-site versioning.html
Date Tue, 13 Aug 2002 23:40:34 GMT
On Tue, 13 Aug 2002, Brian Pane wrote:

> rbb@apache.org wrote:
> >On Tue, 13 Aug 2002, Brian Pane wrote:
> >
> >>rbb@apache.org wrote:
> >>
> >>>I continue to state that APR's time format should stay as it is.  If you
> >>>want seconds, use time_t.  The only change that I can see as appropriate,
> >>>is to make the interval_time_t a 32-bit value, which would mean that any
> >>>arithmetic on the intervals would be faster.  Apache, doesn't want (or
> >>>need) microsecond resolution, so it should use time_t, which
> >>>co-incidentally is now very easy to translate into an apr_interval_time_t
> >>>very quickly.  Since most, if not all, of the apr_functions should be
> >>>using apr_interval_time_t for the arguments, converting types should be
> >>>minimal.
> >>>
> >>That almost works, except that APR forces client apps to use
> >>apr_time_t.  All the time formatting functions and file stat
> >>related functions, for example, use apr_time_t rather than
> >>time_t.  These functions have no need for microsecond resolution,
> >>but at the moment they force the app to use a microsecond based
> >>time.
> >>    
> >>
> >
> >The time formatting features are for apr_time_t, and should require
> >microseconds.  If you want to use time formatting functions for seconds,
> >then you have to use the ANSI standard functions.  Essentially, using a
> >time_t in an apr_time_t function just won't work, and it shouldn't
> >work.
> >
> Agreed, apps should be using separate functions to format time_t than
> they use for apr_time_t.
> 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.  POSIX requires a certain number of time functions
that can be used with time_t variables.  APR and Apache both require ANSI
compilers and C libraries.  There is no reason to wrap the time_t
structure that I can think of.

Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610

View raw message