On 12 Sep 2014, at 4:57 PM, Yann Ylavic <ylavic....@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 —
