> > > Why are we spending time trying to optimize pools when we haven't
> > > eliminated the
> > > malloc/frees in the bucket brigade calls? The miniscule
> > > performance improvements
> > > you -might- get optimizing pools will be completely obscured by
> > > the overhead of the
> > > malloc/frees.
> > >
> > > Bill
> >
> > Because it also eliminates the locking in the threaded mpm.
> > And, I wanted to see if I could squeeze some extra performance
> > out of it and make it a bit more readable. I don't know if
> > I succeeded in the latter. Or the performance for that matter :)
> >
> > Btw, why couldn't we use pools in brigades again?
> >
>
> Brigades need to be maintained across multiple requests to handle
> http pipelined
> responses, so allocating them out of a request pool clearly will
> not work. You could
> allocate the brigades out of a connection pool, but connections
> can remain active for
> 100's of requests so you could leak a lot of storage for the
> duration of the connection.
Wait, couldn't you create a new pool for each brigade, allocate
the brigade out of that pool, associate that pool with the brigade?
Then, when the brigade needs to go, just destroy that pool.
What am I missing?
> Bill
