Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <4961270B.80108@apache.org>
Date: Sun, 04 Jan 2009 22:15:55 +0100
From: Ruediger Pluem <rpluem@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Problem with file descriptor handling in httpd 2.3.1
References: <495FF1B9.9070607@kippdata.de> <495FF67D.3050801@force-elite.com>
 <495FF97C.8090201@kippdata.de> <4960C1EF.3080009@apache.org>
 <4960EA7D.3070402@kippdata.de> <4960F1B6.8040400@kippdata.de>
In-Reply-To: <4960F1B6.8040400@kippdata.de>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit


On 01/04/2009 06:28 PM, Rainer Jung wrote:
> On 04.01.2009 17:57, Rainer Jung wrote:
>> When the content file gets opened, its cleanup is correctly registered
>> with the request pool. Later in core_filters.c at the end of function
>> ap_core_output_filter() line 528 we call setaside_remaining_output().
> 
> ...
> 
>> 2.2.x has a different structure, although I can also see two calls to
>> ap_save_brigade() in ap_core_output_filter(), but they use different
>> pools as new targets, namely a deferred_write_pool resp. input_pool.
> 
> And the code already contains the appropriate hint:
> 
> static void setaside_remaining_output(...)
> {
> ...
>         if (make_a_copy) {
>             /* XXX should this use a separate deferred write pool, like
>              * the original ap_core_output_filter?
>              */
>             ap_save_brigade(f, &(ctx->buffered_bb), &bb, c->pool);
> ...
> }
> 

Thanks for the analysis and good catch. Maybe I have a look into this by
tomorrow.

Regards

R�diger