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
