httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: [Patch] non blocking writes in core
Date Thu, 21 Nov 2013 14:13:17 GMT
/me like :)

On Nov 21, 2013, at 8:57 AM, Graham Leggett <> wrote:

> Given that the world must be given an opportunity to migrate to async filters, we would
need to support both at the same time.
> What I am thinking is that a filter registers itself either as a legacy synchronous filter
(you'll be given a brigade, don't return until all the brigade is consumed), or an asynchronous
filter (feel free to return APR_EAGAIN at any time, and setaside data if you receive APR_EAGAIN
from upstream), you state explicitly which.
> The key bit will be the transition from an upstream async filter to an earlier sync filter,
APR_EAGAIN will need to be trapped and responded to by sending a flush bucket up the stack,
effectively allowing us to convert APR_EAGAIN into APR_SUCCESS which can then be safely received
by the earlier sync filter. This is a simple task that could be accomplished inside ap_pass_brigade().
> The event MPM would simply need to pass empty brigades to c->output_filters until
c->data_in_output_filters returns to zero.
> The addition of a sync filter to the c->output_filters would cause write_completion
to stop working, but it will still be functional until the sync filter became async.
> We currently have this situation where we keep track of the start of the protocol filter
stack in c->output_filters instead of the real start of the stack, we could for now insert
a helper protocol filter that runs first and waits until EOS is received meaning "synchronous
processing is done", before setting aside the data and returning APR_SUCCESS, inviting event
to enter write completion in the hope that everything from this filter onwards is async and
therefore eligible for write completion. This filter can also be responsible for flow control,
vastly simplifying the core_output_filter we have now.
> All of this is still backportable to v2.4.
> Regards,
> Graham
> --

View raw message