Hah! And we're all idiots, too. :-)
ap_filter_flush() doesn't actually generate a FLUSH bucket. It is simply a
cover for ap_pass_brigade() with a prototype and an assumption about its
void* parameter to make it useful to pass into the apr_brigade_* writing
functions.
IOW, the ap_filter_flush -> ap_pass_brigade change will have no material
impact except to save a function call.
I'll be updating some headers and whatnot in httpd to clarify this, and I'll
go ahead and remove that overhead. But the underlying point still stands:
there is no way that mod_deflate should continue to buffer *ENTIRE*
responses. That is simple insanity... (not to mention the cause of the
timeouts people have been seeing, and quite probably the large working sets
that people have seen for httpd)
Cheers,
-g
On Tue, Jul 15, 2003 at 10:59:53AM -0700, Greg Stein wrote:
> Right. mod_dav's use of ap_filter_flush() is wrong. It should be using
> ap_pass_brigade() to pass the brigade contents down the filter stack. As it
> stands right now, we are flushing the content to the network via a FLUSH
> bucket, returning from the handler, and Apache is then sending a brigade
> with an EOS bucket. If we just pass our remaining brigade contents (before
> function return in the two places where flush is called), then the EOS will
> ensure the response is flushed to the network.
>
> (in fact, I'll make this ap_filter_flush -> ap_pass_brigade change later
> today... it is the right thing to do)
>...
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 15 22:42:37 2003