httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Mon, 02 Oct 2000 15:46:29 GMT

> > While this is true, Bill is also right.  Avoiding copying is a laudable
> > goal, but it is just a goal.  It should not be the end all be all of our
> > filtering.  There are times that copying is a good idea, and it is the
> > correct design.
> >
> > The problem is that we need to be very careful how often we copy, and when
> > we decide to copy.  I think 99% of this problem can be solved by putting
> > some buffering in the ap_r* functions and by converting all of the current
> > handlers to use the buckets directly.
> 
> Introducing buffering in ap_r* function is a good possibility. Need to give it
> more thought. Still not convinced how using buckets directly in the handlers is
> good. mod_autoindex works now. We have a couple of reasonable (I think) options
> to fix the 2000 iovec problem (buffer filter or buffer ap_r* functions).  I just
> don't see the benefits of reimplementing mod_autoindex directly in buckets. It
> will introduce bugs and likely make the code more difficult for apache module
> writers to understand.

The problem is that mod_autoindex is creating a lot of very small
brigades, and passing them down the stack.  Most of the buckets that make
up these single element brigades are all the same type.  If instead
mod_autoindex tried to create bigger buckets, or fewer brigades, much of
this problem would go away.

By adding the buffering at the top (in ap_r*), we do all of the coalescing
before trying to pass data down the stack.  This decreases the number of
trips down the stack, and decreases the number of items in each iovec.

> > This I will agree with.  I do not believe we really need a buffering
> > filter, and at the very least, we don't have enough experience to know if
> > we need one or not.
> 
> Tony,
> Right now the buffer filter is serving a very real purpose. I can reduce 2000+
> iovecs into 3.  It works. Like I said earlier, if a better solution comes along,
> I'll gladly remove buffer filter. If you are not prepared to offer a better
> solution to the problem, then you have no right to veto. Okay, maybe you have a
> right to veto, but I have the right to ignore it (at least for now :-).

Two things.  1)  Tony has given two different solutions, either modify
mod_autoindex or ap_r*.   2)  As I have been told multiple times, nobody
has a right to ignore a veto.  As much as I think that is a mistake,
everytime I have ignored a veto, I have been forced to remove the code, or
fix it within a few days.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message