Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 463E711B5F for ; Fri, 12 Sep 2014 05:56:40 +0000 (UTC) Received: (qmail 29752 invoked by uid 500); 12 Sep 2014 05:56:38 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 29680 invoked by uid 500); 12 Sep 2014 05:56:38 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 29671 invoked by uid 99); 12 Sep 2014 05:56:38 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Sep 2014 05:56:38 +0000 Received: by minotaur.apache.org (Postfix, from userid 2161) id 7242711B5D; Fri, 12 Sep 2014 05:56:38 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gauss.localdomain (Postfix) with ESMTP id 57F3C364 for ; Fri, 12 Sep 2014 07:56:33 +0200 (CEST) Message-ID: <54128B11.9080803@apache.org> Date: Fri, 12 Sep 2014 07:56:33 +0200 From: Ruediger Pluem User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: [Patch] Async write completion for the full connection filter stack References: <715A3AE8-8015-4537-943F-A34E0E2A76F7@sharp.fm> <540DFB30.6050700@apache.org> <2F3B060C-E383-407F-A24C-7F026AD3CA81@sharp.fm> <7A74676C-AA9D-40E1-A434-9280C297217D@sharp.fm> In-Reply-To: <7A74676C-AA9D-40E1-A434-9280C297217D@sharp.fm> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 09/11/2014 05:20 PM, Graham Leggett wrote: > On 11 Sep 2014, at 9:51 AM, Yann Ylavic wrote: > >> If we or any filter has created the brigade on *deferred_write_pool >> (or an ancestor, I'm only talking about this case), it is dead now >> (unaccessible), and IMO should be marked as so. >> In the case the caller let the function handle the brigade (as we do), >> using NULL the first time only, (s)he expects to not crash whenever >> (s)he come back with it after a clear (which (s)he isn't supposed to >> know about). > > Agreed - as rpluem suggested a pool cleanup should be registered for this, I�ve added it. I know that I proposed this, but rethinking I see one risk with the cleanup. Take the following code with long_living_apr_bucket_brigade_ptr being NULL in the beginning: apr_bucket_brigade *stack_variable; stack_variable = long_living_apr_bucket_brigade_ptr; ap_save_brigade(f, &stack_variable, &bb, *deferred_write_pool); long_living_apr_bucket_brigade_ptr = stack_variable; I guess in this case this could cause unpredictable behaviour as the stack of the calling function is likely to be repurposed when the pool dies. Do we see that as something that we need to consider or do we see this as a "bug" on caller side? If we see it as a "bug" on caller side we should probably document our expectations. Regards R�diger