On 20 Dec 2002, Brian Pane wrote: > On Fri, 2002-12-20 at 21:37, [EMAIL PROTECTED] wrote: > > On 20 Dec 2002, Brian Pane wrote: > > > > > On Fri, 2002-12-20 at 13:50, [EMAIL PROTECTED] wrote: > > > > > > > > Basically, if you received a brigade from a higher filter, you can only > > > > > assume that it will survive a single trip down the filter stack. > > > > > > Right. And you also can't assume that the context that passed > > > the brigade down the filter stack still exists by the time the > > > brigade reaches the last filter. It's a safe assumption in > > > httpd-2.0, where the brigade is passed as a synchronous function > > > call, but it's not valid for apps in general (potentially including > > > future Apache versions) where the brigade may be queued up for > > > asynchronous processing by an I/O completion thread. > > > > Actually, it's not even a safe assumption in httpd-2.0. You have data > > from requests that originally lived in brigades allocated out of the > > request pool moved to brigades allocated out of the connection pool > > because the request pool is going away. But that just proves the point, > > the data must be moved from one brigade to another to change it's > > lifetime. That is part of the design of buckets and brigades. It is why > > the concat and split operations were written for maximum performance. > > > > We are talking about a couple of pointer assignments for the concatenation > > and a malloc and some pointer assignments for the split. > > And you're also talking about needing a pool from which you > can do the alloc. With pool-based brigade allocation, there > are two basic choices when allocating a new brigade during > the split, and they both have problems:
Um, you need a pool that lives at least as long as your filter. But that should make sense, because if you are going to do any memory allocation, you will need a pool in your filter. > - Allocate from a connection pool. This is what httpd-2.0 > does, but it's not a robust solution, given that connections > can be very long-lived. And for non-http connections, like > an app server connector, connections may live forever, so > doing per-request allocations from a connection-level pool > guarantees a memory leak. No, httpd-2.0 only uses the connection pool in filters that live as long as the connection. If that scope doesn't make sense, then you have to clear the brigade when you are done with it. Remember, we are talking about a couple of bytes for the size of the brigade. Even if it does leak until the end of the connection, it isn't a very big leak. It is a huge leak if you don't clear the brigade, but that is why we have brigade_clear. > Pools just aren't a good match for the allocation needs of > brigades. We happen to have been able to hack around many > of the problems through liberal use of the "copy the brigade > into another pool with a more appropriate scope" technique > in httpd-2.0, but that's not a solution for apps in general. I'm really sorry, but I am sick of hearing this isn't a solution for apps in general. This is now the fourth time that I have asked for a clear description of _why_. I helped to design and write buckets and bucket_brigades. I understand them incredibly well. You seem to be unable or unwilling to give a clear description of the problem you are having. All you are doing is hand-waving saying that this might be a problem for some apps. Give a clear description please. Ryan
