httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: TIL
Date Wed, 27 Apr 2016 12:49:51 GMT

> Am 27.04.2016 um 14:10 schrieb Jim Jagielski <>:
> 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
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.


>> On Apr 26, 2016, at 10:49 AM, Stefan Eissing <>
>> Today I Learned the difference between writing 
>> and 
>> 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

View raw message