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 5438811F65 for ; Sat, 13 Sep 2014 17:03:35 +0000 (UTC) Received: (qmail 8113 invoked by uid 500); 13 Sep 2014 17:03:34 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 8045 invoked by uid 500); 13 Sep 2014 17:03:34 -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 8035 invoked by uid 99); 13 Sep 2014 17:03:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 13 Sep 2014 17:03:34 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of minfrin@sharp.fm designates 80.168.143.5 as permitted sender) Received: from [80.168.143.5] (HELO monica.sharp.fm) (80.168.143.5) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 13 Sep 2014 17:03:06 +0000 Received: from [192.168.0.105] (135-23-43-54.cpe.pppoe.ca [135.23.43.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: minfrin@sharp.fm) by monica.sharp.fm (Postfix) with ESMTPSA id 56C3981792 for ; Sat, 13 Sep 2014 18:03:05 +0100 (BST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [Patch] Async write completion for the full connection filter stack From: Graham Leggett In-Reply-To: Date: Sat, 13 Sep 2014 19:03:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <62D9FF5D-738E-4CE7-BBFE-75E5832AC8BA@sharp.fm> References: <715A3AE8-8015-4537-943F-A34E0E2A76F7@sharp.fm> <540DFB30.6050700@apache.org> <2F3B060C-E383-407F-A24C-7F026AD3CA81@sharp.fm> <0D921B31-EAC0-40EC-8978-EB6FDE02E579@sharp.fm> To: dev@httpd.apache.org X-Mailer: Apple Mail (2.1878.6) X-Virus-Checked: Checked by ClamAV on apache.org On 12 Sep 2014, at 4:57 PM, Yann Ylavic wrote: > Makes sense, however ap_core_output_filter() and > ssl_io_filter_output() *know* that their buffered_bb does not contain > such bucket (exclusively filled by ap_filter_setaside_brigade()), in > that the original code (still in svn) is more optimal since it does > not walk through the same brigade multiple times (doing an immediate > nonblocking write with what it has and returning). I suppose if we clearly document the behaviour it should be fine. We = already force the return of should_write if an empty brigade was passed = in (as in, =93no more coming for now, just write it=94). > To avoid that and the buffered_bb lifetime issue discussed with > R=FCdiger, I'm thinking of an opaque type (a struct containing the > buffered_bb and the deferred_pool) that could be passed to both > ap_filter_setaside_brigade() and ap_filter_reinstate_brigade(). > That way no user could modify the content of the brigade or play with > the pool (opaque), so that ap_filter_setaside_brigade() could > create/clear the deferred_pool as it wish, and > ap_filter_reinstate_brigade() could be sure buffered_bb contains only > suitable buckets. Are we not just trying to solve a dangling pointer to a brigade by = replacing it with a dangling pointer to apr_filter_aside_t? Regards, Graham =97