On Sat, 2002-12-21 at 09:52, [EMAIL PROTECTED] wrote: > No, that is a solution, in fact, it was part of the original design.
And we've discussed already, it's a flaw in the original design, because it requires that the app either maintain a long-lived connection-level pool (with unbounded memory usage) or create and clean up per-response pools (with performance and memory overhead). > What > you've done is said "The brigade may not live long enough", but you > haven't explained how that is the case. This, too, is something that we've discussed already. Request cleanups can happen asynchronously relative to transmission of brigades created from the request. Having a pool cleanup trigger the destruction of a brigade in another thread is dangerous. The canonical solution is to migrate the data to a new brigade outside the pool before handing it off to another thread, which is fine as long as that doesn't create a need for another pool in the application (for the reasons noted above). Brian
