apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Fri, 08 Jun 2001 22:40:09 GMT
Bugger... wish I could avoid sending this to two lists, but I guess
it does overlap.

On Wed, Jun 06, 2001 at 01:04:29AM -0700, Greg Stein wrote:
> On Tue, Jun 05, 2001 at 11:25:43PM -0400, Cliff Woolley wrote:
> > On Tue, 5 Jun 2001, Greg Stein wrote:
> >...
> > > The basic problem with the current setaside() function is that it doesn't
> > > say *how long* the set-aside bucket should be able to live. Thus, it must
> > > implement logic to "live forever" (to be conservatively corect), or it will
> > > simply fail in some circumstances. But then we have the problem that most
> > > buckets *don't* implement "live forever". The FILE bucket doesn't do
> > > anything at all; thus, it dies when the subrequest pool goes away.
> > 
> > +1.  I like this approach.  For clarity, a setaside of a transient bucket
> > would result in what?  A pool bucket?  Or should we just go ahead and
> > make it a heap bucket like we're doing now?
> Tough call. A POOL bucket is nominally "safer" than a HEAP bucket. But *IF*
> we are careful to ensure the HEAP bucket gets placed into a brigade, then we
> are guaranteed it will be tossed.

This is all horribly wrong. ;-)

Seriously, though, there is no reason for the setaside function to need
a full memory allocation system (pool) passed just to do a bit of byte
stuffing within a buffer.  Simply pass a storage pointer and a maximum
size to the setaside function.  That way, a sensible terminal filter
can keep a single buffer within its own state which can be reused
each time some data needs to be setaside, rather than pallocing a new
block of memory every time setaside is called.


View raw message