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
