On Dec 8, 2007, at 11:39 AM, Ruediger Pluem wrote:
The reason why the current code handles FLUSH separately
is though, yes, the ap_pass_brigade is done at the end of
the while loop, that is *only* done when we're done handling
the full brigade... The intent was to honor flushes in the
brigade "immediately" and "reset" at that point... Not sure
why this was removed, since the old way is more efficient.
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).
So we don't process the whole brigade before passing it down the
chain which would be indeed insane.
I didn't catch that when looking over the actual patch itself. Seeing
the actual code in trunk, yeah, this is better.
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 :-).
+1
