> Subject: DO NOT REPLY [Bug 23567] - Huge memory usage > > ------- Additional Comments From [EMAIL PROTECTED] 2003-10-20 10:58 ------- > I spent some time last week-end investigating this. Hopefully this info > can help whoever has time to look for a solution. > > The only memory leak I was able to find is caused by an endless number > of cleanups registered against the request pool by content-length filter > and then killed by the core output filter. A cleanup is registered > during apr_brigade_split(), as the content-length filter separates out > the data already read from the CGI in order to send it to the client. > When the content-length filter is able to read a bit more from the CGI, > the same thing happens again. > > This same pattern could occur with most any other filter. Other filter > code that could do the pipe bucket read is going to have to do the same > thing -- brigade-split and pass-brigade -- before waiting for more > output from the CGI.
For the record, there is a way to do this that requires only a single additional brigade allocation for the whole request rather than n allocations, but it requires the direct use of the ring macros such as UNSPLICE. Perhaps there should be a new api call, something like: apr_brigade_split_and_append(brigade *src, bucket *splitpoint, brigade *dest), which would take two existing brigades, split all the buckets from head to splitpoint out of src and append them onto dest. This is a fairly commonly needed operation, at least in httpd if not in general. We could always have it be an ap_ function. Thoughts? --Cliff
