> Am 26.04.2016 um 23:57 schrieb Yann Ylavic <ylavic....@gmail.com>: > > On Tue, Apr 26, 2016 at 4:49 PM, Stefan Eissing > <stefan.eiss...@greenbytes.de> wrote: >> Today I Learned the difference between writing >> DATA + META >> and >> DATA + META + FLUSH >> to the core output filters. I am astonished that >> my code ever worked. >> >> Seriously, what is the reason for this kind of >> implementation? > > Do you mean why META could be destroyed before (setaside-)DATA, in > remove_empty_buckets()?
Yes. That was unexpected. My understanding of the pass_brigade contract was that buckets get destroyed in order of appearance (might be after the call). > >> I would like to pass META buckets >> in non-blocking way and *not* lose the order of >> bucket destruction. Any explanation or advice is >> appreciated! > > You'd want to setaside (some) META buckets with DATA (in order), right? > At least for EOR buckets, that would keep requests in memory longer > than necessary, but maybe some other META are worth it... It's all fine if users of the filters can be aware of what the conditions and rules are. It is part of the API for all modules that pass buckets through the filters. The h2 use case is to pass a meta bucket that, when destroyed, signals the end of life for data belonging to one stream. So all buckets before that one should have been either destroyed or setaside already. With http/1.x and EOR, my current reading of the code, this does not happen since EORs are always FLUSHed. And even if, releasing the request pool early will probably go unnoticed as WRITE_COMPLETION will read all memory *before* a new pool is opened on the conn pool. This (again, if my reading is correct) does no longer hold in h2. request (stream) starting and ending is happening all the time, conn child pools are created/destroyed all the time. What I saw was memory nullified, by assumedly, new apr_pcallocs, that should not have been freed already. With more likelihood the more load and the less logging, of course. -Stefan
