Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Fri, 23 Feb 2001 11:58:38 -0800
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: new-httpd@apache.org
Subject: Re: SGI Patch 10xpatch-2.0a6-2: Reduce time resolution to 1 sec
Message-ID: <20010223115838.A798@waka.ebuilt.net>
Mail-Followup-To: "Roy T. Fielding" <fielding@ebuilt.com>,
	new-httpd@apache.org
References: <Pine.LNX.4.30.0102230344310.29367-100000@koj.rkbloom.net>
 <0c8e01c09dd3$5afcc870$e4421b09@raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13-current-20010115i
In-Reply-To: <0c8e01c09dd3$5afcc870$e4421b09@raleigh.ibm.com>;
 from bill@wstoddard.com on Fri, Feb 23, 2001 at 03:01:04PM -0500

On Fri, Feb 23, 2001 at 03:01:04PM -0500, Bill Stoddard wrote:
> > Doesn't this remove the advantage of using apr_time_t's?  The whole point
> > of that format was that we were using microseconds instead of seconds.  If
> > that is our goal, then why don't we just change what an apr_time_t is?
> >
> 
> apr_time_t should maintain 1 microsecond resolution (there are legit uses for
> it).  Reducing resolutions should be a runtime or compile time option for
> folks who want speed at the expense of function.

I was going to bring this up later, but what the heck...  I would much
prefer a time structure that used time_t seconds and int microseconds
as separate components rather than mixing all of these 100000s through
the code.  The fact is that almost every use (all except poll/select)
use seconds as their primary time format, and those system calls that
do use microseconds prefer them as a separate parameter.

....Roy