httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: Buff should be an I/O layer
Date Sun, 12 Mar 2000 17:54:53 GMT
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




Mime
View raw message