On Sun, Oct 4, 2015 at 1:40 PM, Graham Leggett <[email protected]> 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? Regards, Yann.
