On 27 Mar 2020, at 14:01, Yann Ylavic <[email protected]> wrote: >> We need to find the reason that in a non-async case, data is being setaside, >> and we need to fix it. > > Connection and network output filters shouldn't care about async or > not, they just feed the pipe as much as possible, and setaside what > they can't (up to reinstate limits). For non-async this is pipelining, > let's not disable that. > > For non-async (though async would also benefit from it), what we need > to do is make sure that each request (worth handling in httpd) gets > finally EOR-ed, so that it's accounted (pipelining for non-async, or > blocking for async).
Async shouldn’t block, that’s the whole point of being async. It only blocks in pathological cases, where the choice is between block, or die because out-of-ram or out-of-file-handles. Pipelining should definitely be supported in the async case. I plan to add EAGAIN support to the core (that was the point behind a recent POC patch), at this point all the blocking vanishes. Adding blocking back in breaks this. > The bug in the current code is about ap_request_core_filter() > retaining data (because core should_yield) and returning, but not > getting called again (because it's not a connection filter and the > core and MPMs care only about that). > Whether ap_request_core_filter() should block depending on > async/non-async does not matter IMHO. In my original design (network and connnection filters only), async MPMs got async support, and non-async MPMs behaved identically to httpd 2.4. The idea was that the door was always open to backport this, but having slept on it it’s a big change, so I never proposed it for backport. In your design (add request filters), you added the additional behaviour to let all connection filters be async. Trouble is, this doesn’t work on non async MPMs, and here we are. I argue, given we’re not backporting this, let’s just teach the other MPMs how to be async. That means, at the end of handling every connection, run the appropriate hooks to completely flush out the setaside briagades, just like the event MPM and others do. In other words, just make everything async in trunk and be done with it. We know async works very well, because event is the default MPM, and that’s the most common path. Don’t leave the door open for weird bugs in the other MPMs. Regards, Graham —
smime.p7s
Description: S/MIME cryptographic signature
