httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@io.com>
Subject Re: Buff should be an I/O layer
Date Sun, 26 Mar 2000 02:42:14 GMT
On Sun, Mar 12, 2000 at 09:54:53AM -0800, Dean Gaudet wrote:
> On Fri, 10 Mar 2000, Manoj Kasichainula wrote:
> > 
> > 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.

OK, I just don't see the problem here:

iol_close = ap_bclose
iol_write = ap_bwrite
iol_writev = ap_bwrite
iol_read = ap_bread
iol_setopt = ap_bsetopt
iol_getopt = ap_bgetopt
iol_sendfile = either (ap_bread + ap_bwrite) or sendfile support in
               buff, depending on time available for some hotshot geek.

Note that I'm not talking about the earlier discussion with seperating
buffering and chunking, just chaning what the current buff's interface
looks like. (aside: Though my unschooled brain still sees no
problem if our chunking layer maintains a pile of 6-byte blocks that
get used in an iol_writev. I'll read the archived discussions.)

> > 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".

Got it. Well, I still like the API uniformity argument. It just feels
cleaner.

On Sun, Mar 12, 2000 at 10:15:00AM -0800, Dean Gaudet wrote:
> if all unixes supported TCP_CORK, and had very inexpensive syscall
> overhead like linux does then we wouldn't have to do much work at all --
> we could take advantage of the fact that the kernel generally has to do a
> single copy of all the bytes anyhow.

Well, we have representatives of many of the major OSs on this list.
Hey you all, hurry up! 

> i think TCP_CORK is still unique to linux.  they added it when they were
> implementing sendfile() and i pointed out the packet boundary problems and
> asked for this new api... most other sendfile() implementations are
> kludges bundling up sendfile and writev for the headers and trailers.

Like ours, unfortunately. (I meant it, you OS developers, hurry up!)


Mime
View raw message