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.
....Roy
