On Mon, 4 Nov 2013, Graham Leggett wrote: > Looking a little bit deeper, we find the following: > > - The event MPM seems to want to perform write completion on the very > last filter in the chain only, which seems completely arbitrary - why > should another filter (like mod_ssl) be prevented from running within > write completion? Doesn't make sense to me. Ideally we need to teach the > event MPM to run write completion on a class of filters, such as > AP_FTYPE_NETWORK, and make it a rule that network filters must be aware > of and are not allowed to block async MPMs. Given that in theory there > is only one AP_FTYPE_NETWORK filter (to my knowledge), this should be > backportable to v2.4.
The filter calls during write completion are done in the worker threads. There is no strict requirement that they must not block. Of course, if they block, the advantage of write completion is lost. I think we should stay with this mode for the time being, because it will save a lot of trouble in case of badly behaved filters. Also, if encryption would be done in the async thread, the CPU processing that thread could become a bottleneck. In the medium term, we don't only want network filters to become eligible for write completion, but all filters. Think of a large text file being compressed with mod_deflate. Or a large file being processed with mod_include. I had the idea of inserting another buffering filter at the very start (let's call it edge_filter for now), which could then be called on write completion. It could somehow communicate with the core_output_filter to balance how much data is buffered on which end of the filter chain. For example, as long as core_output_filter has data buffered, it would write that with async write completion. When its buffer gets emtpy, it would call edge_filter to send some more data through the whole filter chain, including mod_ssl. If any in-between filter module blocks, then it would no worse than now, without write completion. But I think in many cases, none of the in-between filters would block, and we get write completion for many filters. Of course, so far this is only an idea and I haven't digged into the code to see if it's actually feasible. Do you see any immediate reason why it wouldn't work? > - mod_ssl defines itself as "AP_FTYPE_CONNECTION + 5", which looks to me > like mod_ssl really wants to be a network filter, not a connection > filter. If we were to teach the event MPM above to trigger network > filters, I propose that mod_ssl becomes a network filter following the > "not allowed to block async MPMs" rule (which it should do already > anyway). I have no idea ATM about the implications of changing that. BTW, mod_reqtimeout registers as AP_FTYPE_CONNECTION + 8. But it may make sense to integrate that into the core_output_filter.
