httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: [Patch] Async write completion for the full connection filter stack
Date Mon, 05 Oct 2015 11:13:00 GMT
On Sun, Oct 4, 2015 at 1:40 PM, Graham Leggett <> 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’t want to be kicked.
From the perspective of ap_filter_should_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 stomping 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?


View raw message