httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re:
Date Sat, 08 Dec 2007 18:12:06 GMT

On Dec 8, 2007, at 11:39 AM, Ruediger Pluem wrote:
> In fact the patch does all this as it passes the passbb brigade down
> the chain after *each* processed bucket of the original brigade
> (the ap_pass_brigade is at *the end* of the while loop *not* after
> the while loop).

I didn't catch that when looking over the actual patch itself. Seeing
the actual code in trunk, yeah, this is better.

> So we don't process the whole brigade before passing it down the
> chain which would be indeed insane.
> In fact flush buckets are handled in the same manner as before
> the patch as they fall in the
> branch and the next code that is executed after the block there
> is an ap_pass_brigade at the end of the while loop
>> I also see that AP_MIN_BYTES_TO_WRITE is no longer being
> I saw no need for us to do *any* buffering in the filter. If the
> data passed down the chain is not reasonable large for sending over
> the wire the core network filter will take care of this and buffer
> it until it is reasonable or a flush bucket is seen.
>> used at all... I'm guessing MAX_BUCKETS is designed to
>> "replace" that?? Again, the idea is to avoid extremely
>> large in-process data sizes :) The MAX_BUCKETS seems
> The patch does that :-).
>> to be mostly for super-bad cases and not so much for
>> behaving "nicely" in all cases. (mod_include.c does
>> the same thing, btw)
> No MAX_BUCKETS should not replace that. It is a safety measure
> for super bad cases like the example I gave in my initial review
> mail
> ( 
> 3c99EA83DCDE961346AFA9B5EC33FEC08B05B290@VF- 
> Regards
> RĂ¼diger

View raw message