Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 52209 invoked by uid 500); 15 Jul 2002 03:03:42 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 52198 invoked from network); 15 Jul 2002 03:03:42 -0000 Reply-To: From: "Ryan Bloom" To: "'Aaron Bannert'" , Subject: RE: Why not POSIX time_t? Date: Sun, 14 Jul 2002 20:03:51 -0700 Organization: Covalent Technologies Message-ID: <00b201c22bac$3f8bc8d0$0a01230a@KOJ> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <20020715023505.GM18710@clove.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 resolution. 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. Ryan