On Tue, Feb 2, 2021 at 10:32 AM Ruediger Pluem <rpl...@apache.org> wrote:
>
> > New Revision: 1885605
> >
> > URL: http://svn.apache.org/viewvc?rev=1885605&view=rev
[]
> > +        /* Yield if the output filters stack is full? This is to avoid
> > +         * blocking and give the caller a chance to POLLOUT async.
> > +         */
> > +        if (flags & AP_PROXY_TRANSFER_YIELD_PENDING) {
> > +            int rc = OK;
> > +
> > +            if (!ap_filter_should_yield(c_o->output_filters)) {
> > +                rc = ap_filter_output_pending(c_o);
>
> I am confused here: !ap_filter_should_yield(c_o->output_filters) means there 
> is no pending output.
> Why should we try to send it then? Shouldn't it be the other way round?

Yes, !ap_filter_should_yield() means that there is no pending output,
but only for filters that play the
ap_filter_{setaside,reinstate}_brigade() game.

The goal here is to try to flush pending data of filters that don't
ap_filter_setaside_brigade(), like e.g. ssl_io_filter_coalesce() which
is not using setaside/reinstate (but is kind of aware of them still,
see r1879416, I tried to move it to using setaside/resinstate but the
result is more complicated than the original code, so I passed on that
patch for now and pushed the one-liner..).

But (and this is why the code is like this), we don't want to try to
flush those potential non-setaside pending data if there are setaside
pending data already (like in the core output filter), otherwise we
might block in some filter (like the core filter still) if given more
data while already at the limits.

This poll()ing loop really depends on staying in the POLLOUT state
until there are no more pending data (setaside or not), otherwise we
"risk" the blocking call soon or later, at least with the current "no
EAGAIN" on output mechanism. Hope this clarifies why it's done like
this..

Regards;
Yann.

Reply via email to