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 Tue, 03 Oct 2000 13:54:05 GMT

> > From: Jeff Trawick []
> > Sent: Tuesday, October 03, 2000 6:55 AM
> >
> > "William A. Rowe, Jr." <> writes:
> >
> > > > From: []
> > > > ...
> > > > I entirely expect to re-write mod_autoindex to use a single brigade to
> > > > pass data down, at far fewer buckets than it currently uses.  The only
> > > > reason I haven't done so already is that I have had bigger fish to fry
> > > > and very little time.
> > >
> > > That's a given, and +++1's to you if you are the first to get to it :-)
> >
> > What you folks are saying is that the old API has been taken away.
> > Previously we had APIs to write to the network which work like stdio.
> Yes, that's what it did.
> > Simple, easy-to-review/test code led to reasonable performance.
> Very true.  I'd add limited flexibility to your list.

Flexibility generally equates to complexity. I have seen quite a few software
projects implode under unnecessary complexity because the design was too
general. In my experience, overly complex designs come from not understanding
exactly what is required of the code  (i.e, we don't understand exactly what
this code should do so we will design so that it can be extended to do
anything).  Also keep in mind that most successful open source projects have a
reasonably low entry barrier. That is, they are reasonably easy to understand
and tweak. But maybe that is a pipe dream for Apache 2.0 already :-(

> > Now you are saying that there is something wrong with such simple code
> > and it must be changed because it no longer performs reasonably.  I'd
> > rather us *NOT* change mod_autoindex (much) but still make sure it
> > still performs reasonably.
> If you want mod_autoindex as the testcase/benchmark for the ap_r* suite,
> I don't object to leaving it as is.  I think everyone is saying we need
> the coalescing layer within:
>   *) the ap_r* function support (handler source).
>   *) the chunking filter (prevent tiny packetization).
>   *) the core transport (or alternate transport) filter.

Arrggggghhhhhh, using the 'byte moving' defn of coalescing, why oh WHY do we
need it in each layer? What a PITA!  coalescing should be done in one place,
either a special case coalesce_filter (aka buffer_filter) or it it should be
done in ap_r*. Until I see a good ap_r* implementation, I am still in favor of
the filter solution because it is relatively simple. And the coalesce_filter is
completely general; it can be inserted where ever it makes sense to insert it.
And if you make a mistake and insert it where it is not needed, it will
introduce only the slighest overhead (probably not measurable).  Let the core
filter do 'buffering', i.e, collect iovecs. It should not attempt to coalesce.
BTW, apr_sendfile accepts an array of iovecs as arguments. The WIN32
implementation of apr_sendfile does the right thing with the iovecs, which is
the right approach IMHO.


View raw message