apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: Why not POSIX time_t?
Date Mon, 15 Jul 2002 03:03:51 GMT

For clarity, there is only one reason that we aren't just using POSIX's
time_t.  While Windows has time_t, it doesn't use time_t's internally.
Instead, it uses a completely different epoch with 100 nano-second

The only other reason for apr_time_t is to get usec resolution.

> From: Aaron Bannert [mailto:aaron@clove.org]
> On Sun, Jul 14, 2002 at 07:27:04PM -0700, Brian Pane wrote:
> > The reason we don't use a struct (timeval or any variant thereof)
> > is that doing addition and subtraction on the struct is much slower,
> > more complicated, and (if people try to do their own match on the
> > struct directly) more error-prone than doing the same ops on a
> > scalar.
> How exactly is the subtraction slower?I'm not at all sure what you
> mean by people matching on the struct directly...

In order to do subtraction or struct matching, you have to deal with
carry-over, because you have two numbers to add or compare.

There is a big part of me that believes that Apache should just use
time_t, while APR continues to implement apr_time_t for other
applications.  Time_t is used if you want second resolution, and
apr_time_t is used for more granularity.

BTW, this whole conversation started because we wanted to speed up
Apache.  Has anybody considered taking a completely different tack to
solve this problem?  

I know there is a patent on this, but I am willing to ignore it, and I
am pretty sure that we can get the patent owner to let us use it.  (I
won't say who owns the patent, but if the owner wants to stand up, it
will be obvious why I say this).  We could create a separate thread to
keep track of the current time every second.  That way, the computation
is completely removed from request processing it is just a memory
access.  On platforms without threads, we just go back to getting the
time during request processing.  That will hurt performance for those
platforms, but I am not too concerned about that.


View raw message