Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 94307 invoked by uid 500); 5 Jul 2001 22:47:39 -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 94270 invoked from network); 5 Jul 2001 22:47:36 -0000 X-Authentication-Warning: cobra.cs.Virginia.EDU: jcw5q owned process doing -bs Date: Thu, 5 Jul 2001 18:47:38 -0400 (EDT) From: Cliff Woolley X-X-Sender: To: "Roy T. Fielding" cc: APR Development List Subject: Re: cvs commit: apr-util/buckets apr_buckets_file.c In-Reply-To: <20010705144550.E898@waka.ebuilt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Thu, 5 Jul 2001, Roy T. Fielding wrote: > Either define two different file bucket types or add a variable that > indicates relative vs fixed. Fixed fds have to be seeked to the > position of each read, whereas relative fds skip from the current > position to the offset. File buckets are therefore relative until > split. I thought about that. But there'd be a *lot* of code duplication. The only thing that would be different would be whether or not apr_file_seek() gets called and the logic to convert from one type to another. Plus I'm not convinced that there's any reliable way to know when to do the relative->fixed swapover. It's not just when you split() the bucket. Problems can occur with copy, split, and delete, at least. But just the fact that you copy, split, or delete doesn't mean that you HAVE to seek, it just means that you can no longer guarantee that you don't have to seek. It seems like it'd be a lot easier if we just stuck a conditional at the top of apr_file_seek() that returns immediately if the offset stashed in the apr_file_t (which is assumed to be the same as the one in-kernel, which is a valid assumption if you don't mix apr_file_* and non-apr_file_* calls on the same file handle) is the same as the offset passed into apr_file_seek(). So we're talking about one functional call and one conditional return. It's a tradeoff between that very small performance penalty and much cleaner and more reliable file buckets. I'm dislike the idea of duplicating the file buckets in this way. But I'm willing to change my mind if you can show me a way to do it that doesn't duplicate much code and that works in all cases. --Cliff -------------------------------------------------------------- Cliff Woolley cliffwoolley@yahoo.com Charlottesville, VA