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

Reply via email to