Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <28641C04-8936-4004-BA40-C889C8B7846A@sharp.fm>
References: <A57B894B-50DA-4252-8FFF-C3DEF8473A61@sharp.fm>
	<D4B68B53-592F-4EEC-B39F-EFC9887F60D5@jaguNET.com>
	<715A3AE8-8015-4537-943F-A34E0E2A76F7@sharp.fm>
	<D7EA895A-9C37-4387-AE89-C1B7DF9B0706@jaguNET.com>
	<540DFB30.6050700@apache.org>
	<2F3B060C-E383-407F-A24C-7F026AD3CA81@sharp.fm>
	<AB1691BE05AE7F4992697F2A0835627AC5D859AB@VOEXM10W.internal.vodafone.com>
	<AA9FAD6C-8E83-4F5F-8F18-BC3BECF8B0A1@sharp.fm>
	<CAKQ1sVPFJk9-Y=JwDLvJcYT7ZCQ=xbuBRS9fu8Me_T-3f2fVXg@mail.gmail.com>
	<C6246136-6B10-4F7B-8261-6723ABD26817@sharp.fm>
	<CAKQ1sVMw0-=LsqPEkWYs1QP8daMYv=eaxhRT8gsnrppooVzuMg@mail.gmail.com>
	<7A74676C-AA9D-40E1-A434-9280C297217D@sharp.fm>
	<54128B11.9080803@apache.org>
	<496E8EFA-7A10-4D91-8C7E-434A9A3B09C5@sharp.fm>
	<541499A9.5050408@apache.org>
	<4D9E72F8-4918-49AD-8DC4-E3594C9ED43D@sharp.fm>
	<04776F50-0A53-4C1D-AA1C-9F57B60BC0AC@sharp.fm>
	<38C56976-E693-4EEE-88BA-85DE3328FED3@sharp.fm>
	<7051D658-B96C-47BA-B21F-6511665DDAD8@jaguNET.com>
	<28641C04-8936-4004-BA40-C889C8B7846A@sharp.fm>
Date: Mon, 5 Oct 2015 13:13:00 +0200
Message-ID: 
 <CAKQ1sVPuOxqWbw3Uo1k7OTa+etsUJhL_9j=jfEykXJJD=-ft3Q@mail.gmail.com>
Subject: Re: [Patch] Async write completion for the full connection filter
 stack
From: Yann Ylavic <ylavic.dev@gmail.com>
To: dev@httpd.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 4, 2015 at 1:40 PM, Graham Leggett <minfrin@sharp.fm> wrote:
>
> The next bit of this is the ability to safely suspend a filter.
>
> A suspended filter is a filter that is waiting for some external event, a=
 callback of some kind, some timer that it might have set, and in the mean =
time doesn=E2=80=99t want to be kicked. From the perspective of ap_filter_s=
hould_yield() the filter has data in it and a well behaved upstream filter =
should wait before sending anything further.
>
> The idea behind suspending filters over and above connections is that if =
two separate filters want to suspend a connection, what stops them from sto=
mping on one another?

Why suspend a filter rather than the calling handler (on EAGAIN/EWOULDBLOCK=
)?

>
> I am thinking of the sharp end of mod_proxy_httpd (and friends) becoming =
an async filter that suspends or not based on whether data is available on =
the other connection. In the process, mod_proxy becomes asynchronous.

It seems that suspending the handlers would avoid rewriting them as filters=
.
Or is your plan to go for something like (mod_)serf?

Regards,
Yann.