From dev-return-14720-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Sep 07 09:22:18 2005 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 61320 invoked from network); 7 Sep 2005 09:22:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Sep 2005 09:22:14 -0000 Received: (qmail 32059 invoked by uid 500); 7 Sep 2005 09:22:13 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 31744 invoked by uid 500); 7 Sep 2005 09:22:12 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 31730 invoked by uid 99); 7 Sep 2005 09:22:12 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Sep 2005 02:22:12 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [82.195.144.76] (HELO loughan.stdlib.net) (82.195.144.76) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Sep 2005 02:22:24 -0700 Received: from colmmacc by loughan.stdlib.net with local (Exim 4.50) id 1ECw88-0002eI-Rz for dev@apr.apache.org; Wed, 07 Sep 2005 10:22:08 +0100 Date: Wed, 7 Sep 2005 10:22:08 +0100 From: Colm MacCarthaigh To: dev@apr.apache.org Subject: Re: [PATCH] Configurable read/write buffer sizes Message-ID: <20050907092208.GA10137@stdlib.net> Reply-To: colm@stdlib.net References: <20050906204911.GA5989@stdlib.net> <20050907083808.GC4636@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050907083808.GC4636@redhat.com> User-Agent: Mutt/1.5.9i X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Wed, Sep 07, 2005 at 09:38:08AM +0100, Joe Orton wrote: > On Tue, Sep 06, 2005 at 09:49:12PM +0100, Colm MacCarthaigh wrote: > > It supports increasing and decreasing the buffer size, as well as making > > an unbuffered file handle buffered, and a buffered file unbuffered. > > > > The patch also adds a new subpool to the file handle, for the buffer > > itself, with the subpool being destroyed on buffer resizes. > > A subpool is an extra 8K of allocated memory for something the caller > might not need, I don't think this is a good idea. It was only allocated if buffering was enabled, but I get what you mean. > I wonder if it would be better to simply allow the caller to choose and > manage the buffer allocation appropriately, a la stdio setbuf/setvbuf; > making the interface something like: > > apr_file_set_buffer(apr_file_t *file, char *buffer, apr_size_t buflen) It would still mean losing the original buffer, though I guess the application authors can have the sense to open the file un-buffered and then to use this call. > > Other things I'm thinking about; > > > > Destroying the subpool on apr_file_close, after all the lifetime > > of the buffer should be exactly concurrent with the lifetime of > > the file descriptor. > > > > Maybe making something like; > > > > apr_file_set_default_buffer_size(apr_off_t foo); > > insert "global state sucks" rant here :) (sizes of things in memory > should always be apr_size_t not apr_off_t btw) I know :) My reasoning for that is that to do with the bufpos handling. The bufpos itself is a plain "int", which won't ever overflow an apr_size_t, but then things like seek.c use an apr_off_t when they are assigning to bufpos. I wanted to avoid any overflow being my fault. Maybe I should I fix this too. bufpos should really be an apr_size_t and the handling should be consistent. -- Colm MacCárthaigh Public Key: colm+pgp@stdlib.net