> Am 27.04.2016 um 14:10 schrieb Jim Jagielski <j...@jagunet.com>: > > Grrr... w/o looking too deeply into this, this seems very > wrong. Is that a long-standing bug or something recently > "optimized" away?
I had a look into 2.4.x this morning and while there are changes in filter brigade setaside code, the basic "cleanup" of empty and meta buckets before the setaside is there already. I think this has not bween noticed before as 1. EOR is always followed by a FLUSH 2. most bucket types survive the destruction of r->pool quite well, even pool buckets silently morph 3. even if transient buckets would reference pool memory, settings those aside after destruction of r->pool, but before filter return would access freed, but not re-used memory from the connection allocator - I think. So far, I have seen no reasons why meta buckets should not just be setaside in core filter. 0 length data buckets should also stay, IMHO, just ignored in the actual write. I can only guess the original intent: 0-length data buckets sometimes happen during some brigade read modes and if there are several FLUSH buckets in the brigade, it makes sense to get rid of them also. But I think the space savings are minimal. But there could be reasons for the current behavior, I overlooked. So, I am asking around. -Stefan > >> On Apr 26, 2016, at 10:49 AM, 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? 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! >> >> Cheers, >> >> Stefan >
