Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 36598 invoked by uid 500); 23 Jun 2000 18:08:05 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 36515 invoked from network); 23 Jun 2000 18:07:57 -0000 X-Authentication-Warning: koj.rkbloom.net: rbb owned process doing -bs Date: Fri, 23 Jun 2000 11:08:24 -0700 (PDT) From: rbb@covalent.net X-Sender: rbb@koj.rkbloom.net To: new-httpd@apache.org Subject: RE: default timeout values In-Reply-To: <000401bfdd3c$fc323bb0$345985d0@corecomm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > > > Comments on changing this type name for clarity? (I just propose > > > delta instead of interval since it's a shorter word, that's all.) > > > > I really don't think this helps clarity any, sorry. :-} I also don't > > mind replying to messages on the list with: > > > > "This topic has been discussed before, please see the archives for Jun > > 2000, and search for interval_time." > > Fair enough, but I'd suggest that if 3 coders notice this 'bug' (we are > up to two already), that we have a doc problem or clarity problem. Let's > not waste everyone's time unwinding the same restriction. You're right. Let's just document it in the header file. :-) > > I really think we are fine the way things are now. If we want room to > > grow into the future, I think we can just change the def of > > ap_interval_time_t. All this requires is a recompile to move > > from 32 -> 64 bit values. > > Here I disagree. 32 bits is a good thing for optimization, IMHO. If we > ever did extend to hours or days, that would and should be a different > type. Declaring it now tells the new coder to APR that we did think > this through, and these functions are all in short time intervals. How about we put this option in the comment too, and delay this discussion until it is really necessary. Who knows, by the time this is necessary, we could all be on 64-bit machines. :-) Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------