httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 11:54:41 GMT
"William A. Rowe, Jr." <wrowe@rowe-clan.net> writes:

> > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > Sent: Monday, October 02, 2000 6:46 PM
> > ...
> > 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.
Simple, easy-to-review/test code led to reasonable performance.  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.

Buckets are more error prone to code than the old API, even more so
than the old trade-off of collecting data in the handler vs. making
multiple calls to ap_rXXX() (or collecting data to write to a file
vs. making multiple write calls to stdio).  Taking this away is
harmful to people who want to solve a problem without spending a lot
of time on it.

A change I think is fair for classic API users is to make a new API
call (once per request) which inserts a special filter (coalescing?
buffering? I don't care what you call it) right after the generator.
The filter would work similar to BUFF/stdio.  It would copy small
pieces into a buffer so that we make fewer trips down the filter
chain.  Copying small pieces is not slower, assuming that small is
#defined appropriately.  You get double benefit: less overhead
accounting for little pieces and fewer trips down the filter chain.
This is much more cache friendly in addition to taking fewer CPU
cycles.

Any generator which writes in small increments should call
ap_buffer_output() (sucky name, but you get the picture) so that the
generator performs much more similar to classic Apache.

> ap_r* is going away, correct?  It's legacy, and I'm not too
> concerned.

When did "we" drop the requirement to maintain the old API?

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message