apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCarthaigh <c...@stdlib.net>
Subject Re: [PATCH] Configurable read/write buffer sizes
Date Wed, 07 Sep 2005 09:22:08 GMT
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

View raw message