On Mon, 2014-09-08 at 17:25 +0200, Graham Leggett wrote: > Ideally, filters should do this, but generally they don’t: > > /* Do nothing if asked to filter nothing. */ > if (APR_BRIGADE_EMPTY(bb)) { > return ap_pass_brigade(f->next, bb); > }
Why on Earth should filters want to do that, as opposed to: > Some filters, like mod_deflate, do this: > > /* Do nothing if asked to filter nothing. */ > if (APR_BRIGADE_EMPTY(bb)) { > return APR_SUCCESS; > } or similar variants? > In these cases ap_pass_brigade() is never called, so we detect this by > keeping a marker that is changed on every call to ap_pass_brigade(). If the > marker wasn’t changed during the call to the filter, we compensate by calling > each downstream filter until the marker is changed, or we run out of filters. Yes. The logic is that we call ap_pass_brigade when there's something to pass. Not when there's nothing: that would just look like superfluous overhead. If you have a reason to propagate an immediate event regardless of that logic, surely that's the business of a FLUSH bucket. Then the question becomes, is it ever right to absorb (or buffer) and fail to propagate a FLUSH? You seem instead to be ascribing FLUSH semantics to an empty brigade! As a filter developer, it's my business to pass a brigade when: 1) I'm ready to pass data. 2) I encounter EOS, when I must finish up and propagate it. 3) I am explicitly signalled to FLUSH whatever I can. What am I missing? Do we have a need to refine the FLUSH bucket type? Maybe an EVENT bucket carrying an event descriptor? -- Nick Kew