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
if (APR_BUCKET_IS_METADATA(b))
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
(http://mail-archives.apache.org/mod_mbox/httpd-dev/200712.mbox/%
[EMAIL PROTECTED]
MBX11.internal.vodafone.com%3e).
Regards
Rüdiger
