> -----Original Message----- > From: Graham Leggett [mailto:[email protected]] > Sent: Dienstag, 6. Oktober 2015 12:16 > To: [email protected] > Subject: Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ > modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ > server/mpm/simple/ > > On 06 Oct 2015, at 1:39 AM, Yann Ylavic <[email protected]> wrote: > > > >> + /* decide what pool we setaside to, request pool or deferred > pool? */ > >> + if (f->r) { > >> + pool = f->r->pool; > >> + APR_BRIGADE_CONCAT(f->bb, bb); > >> + } > >> + else { > >> + if (!f->deferred_pool) { > >> + apr_pool_create(&f->deferred_pool, f->c->pool); > >> + apr_pool_tag(f->deferred_pool, "deferred_pool"); > >> + } > >> + pool = f->deferred_pool; > >> + return ap_save_brigade(f, &f->bb, &bb, pool); > >> + } > > > > Shouldn't ap_save_brigade() be moved below the "else”? > > It shouldn’t no. > > ap_save_brigade() performs setaside, and that is precisely what we want to > avoid for request filters. In request filters we can safely > APR_BRIGADE_CONCAT and not worry. > > If you moved ap_save_brigade() the server behaviour would become > synchronous again for data that wasn’t a file. >
How can you be sure that you don't have transient buckets in the brigade that point to memory that changed or is invalid, once you reinstate the brigade? Regards Rüdiger
