Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Sun, 12 Mar 2000 09:54:53 -0800 (PST)
From: Dean Gaudet <dgaudet-list-new-httpd@arctic.org>
To: Apache Developers <new-httpd@apache.org>
Subject: Re: Buff should be an I/O layer
In-Reply-To: <20000310061837.A1570@manojk.users.mindspring.com>
Message-ID: <Pine.LNX.4.21.0003120948410.6274-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 10 Mar 2000, Manoj Kasichainula wrote:

> Random thought that I thought should go to the list before I forget
> it:
> 
> BUFF's API should be redone to look exactly like an IOL. As far as the
> rest of Apache code is concerned, a IOL with a buff around it
> should look just like any other IOL.

haha!

if you figure this out, then rad.  i tried for a long time to figure out a
clean way to do this which doesn't suck and i never found one.

remember it is totally unacceptable for bputc() and bgetc() to be anything
other than macros operating directly on the buffer.

> First of all, we get more uniformity in the API. That's always a good
> thing. This also allows us to yank out the buff IOL sometimes. I can
> see this being useful if a really sophisticated module wants to truly
> eliminate the buffering between it and the client.

the BUFF layer allows you to run without buffering, or with non-blocking
i/o, and it implements chunking.  you gain a mere few cycles by "yanking
it out".

you might say "chunking should be a layer too", see my above laughter.

the only way you're going to make a change like this "clean" is to add a
sophisticated zero-copy implementation.  i stopped short of doing this
because in my experience using one of these, the benefits are really
minimal.  <http://www.canonware.com/sqrl/> look in libstash.

the only case where i've seen the zero-copy stuff really shine is when
doing TCP-to-TCP proxying.  for everything else, the (comparatively
simple) heuristics present in BUFF are all that's required.

Dean