httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Mon, 02 Oct 2000 15:01:10 GMT

> Tony Finch <> wrote:
> > wrote:
> >>
> >>First cut at a filter to buffer/coalesce multiple small buckets into
> >>a single large bucket.
> >
> >I'm sure this is the wrong approach to solving the problem. The whole
> >point of buckets is to avoid copying, so we should re-do the ap_rput
> >stuff so that copying isn't needed in the first place and re-do
> >mod_autoindex so that it uses buckets directly.
> Actually, I think I will upgrade this objection to a veto for two
> reasons:
> 1. It is easy to write a buffering filter without unnecessary copies
> using the setaside facility, i.e. only TRANSIENT buckets would get
> copied. What has been committed copies far too much unnecessarily,
> and fails to allow for 3rd party bucket types.

Can you elaborate? Keep in mind, using writev to send 2000 1 to 8 byte chunks is
not a solution. If you have 2000 HEAP buckets with 2 bytes of data, you need to
coalesce those bytes into a single buffer.  How do you do that in your design
without moving bytes?

> 2. Including a buffering filter in the core is wrong for the reasons I
> stated in my earlier post, and therefore it gives entirely the wrong
> message to 3rd party developers. If we include something like this in
> the core then we are compromising the design, and we are encouraging
> our users to do the wrong thing.
> I am -1 for including a buffering filter in the standard apache code,
> and -10 for including a copying buffering filter. I do not believe
> that expedience is a good argument in favour of blundering along in a
> half-hearted fashion and thereby ending up with a half-arsed
> implementation of a design which I think is actually quite good.

I've yet to hear a good alternative. Give me a concrete example of how you
propose to fix the problem? And I am totally unconvinced that reimplementing all
handlers to use buckets directly is the right solution. In fact, I don't see how
it will even solve the problem.


View raw message