httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: [Patch] Async write completion for the full connection filter stack
Date Tue, 09 Sep 2014 08:58:09 GMT
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

View raw message