Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 43697 invoked by uid 500); 11 Jul 2002 23:58:41 -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 43674 invoked from network); 11 Jul 2002 23:58:41 -0000 From: "James Cox" To: "Cliff Woolley" , , "Roy Fielding" Subject: RE: cvs commit: apr STATUS Date: Fri, 12 Jul 2002 00:58:47 +0100 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > The fact that APR has provided me with a platform-neutral way to get > high-resolution time has been a *huge* boon to my work. While I realize > this is a limited example, the same applies to many other use cases I can > think of. > > Stop hand-waving-saying-we're-hand-waving, please. IMO there's definitely > a very valid case for having sub-second time resolution in this > portability library, as getting high-resolution time across platforms is a > *bear* to do yourself. Also, the sole and primary reason i'm learning AP2 and APR is that i need to write software that can scale to millions of concurrent requests and be able to accept -> triage -> route -> reset. Having the ability to make such decisions (as Cliff says) is not a wet dream, but a necessity. Here is your second real-world example as to why sub-second time resolution is a real thing. -- James