On 20 Oct 2015, at 10:42 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote:
>> So if at all a change for trunk only that requires a very deep review of all >> brigade usages. > > As I learned, bucket brigades are very optimized for the common HTTP/1 case: > appearing during one > request and going away together with the request - preferably with only one > thread involved. > > When (sub-)request are used - and you may look at HTTP/2 processing as > involving sub-requests, this > model no longer holds and such functionality has a heavy price to pay. It > needs to step very > carefully to avoid the pitfalls of pool destroy cleanups on EOR. I’m not fully following why this involves a heavy price - we already have (and have solved) the same problem in the proxy. The proxy welds backend conn_rec’s to frontend conn_rec’s, while mod_http2 welds a child conn_rec to a parent conn_rec. In the proxy case the EOR bucket only ever lives in one conn_rec, as long as you stick to that - ie destroy the EOR bucket in the child conn_rec, it should work fine. > Given the complexity and the modules out there, I do not think it wise to > change the behaviour > of the existing apr_bucket_brigade in 2.4.x. I think it is better to think of > an alternate bucket > brigade design and maybe how that could live next to the old one in 2.4.x. Or > skip 2.4.x entirely > for this. I am very wary of alternate designs that throw away the investment the community has made in existing code, existing tooling, and existing knowledge. I would far rather we fix these bugs in the current design than try come up with alternatives. So far, all the work I’ve done in expanding support for async filters has simply involved finding and fixing bugs. Regards, Graham —
