httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: [Patch] Async write completion for the full connection filter stack
Date Sat, 13 Sep 2014 17:03:02 GMT
On 12 Sep 2014, at 4:57 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:

> Makes sense, however ap_core_output_filter() and
> ssl_io_filter_output() *know* that their buffered_bb does not contain
> such bucket (exclusively filled by ap_filter_setaside_brigade()), in
> that the original code (still in svn) is more optimal since it does
> not walk through the same brigade multiple times (doing an immediate
> nonblocking write with what it has and returning).

I suppose if we clearly document the behaviour it should be fine. We already force the return
of should_write if an empty brigade was passed in (as in, “no more coming for now, just
write it”).

> To avoid that and the buffered_bb lifetime issue discussed with
> Rüdiger, I'm thinking of an opaque type (a struct containing the
> buffered_bb and the deferred_pool) that could be passed to both
> ap_filter_setaside_brigade() and ap_filter_reinstate_brigade().
> That way no user could modify the content of the brigade or play with
> the pool (opaque), so that ap_filter_setaside_brigade() could
> create/clear the deferred_pool as it wish, and
> ap_filter_reinstate_brigade() could be sure buffered_bb contains only
> suitable buckets.

Are we not just trying to solve a dangling pointer to a brigade by replacing it with a dangling
pointer to apr_filter_aside_t?

Regards,
Graham
—


Mime
View raw message