dgaudet 99/06/18 17:17:51
Modified: mpm/src/docs buff.txt Log: rambling on Revision Changes Path 1.2 +77 -0 apache-2.0/mpm/src/docs/buff.txt Index: buff.txt =================================================================== RCS file: /home/cvs/apache-2.0/mpm/src/docs/buff.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- buff.txt 1999/06/18 23:34:57 1.1 +++ buff.txt 1999/06/19 00:17:51 1.2 @@ -1,6 +1,83 @@ +goals? we need an i/o abstraction which has these properties: + +- buffered and non-buffered modes + + The buffered mode should look like FILE *. + + The non-buffered mode should look more like read(2)/write(2). + +- blocking and non-blocking modes + + The blocking mode is the "easy" mode -- it's what most module writers + will see. The non-blocking mode is the "hard" mode, this is where + module writers wanting to squeeze out some speed will have to play. + In order to build async/sync hybrid models we need the + non-blocking i/o abstraction. + +- timed reads and writes (for blocking cases) + + This is part of my jihad against asynchronous notification. + +- i/o filtering or layering + + Yet another Holy Grail of computing. But I digress. These are + hard when you take into consideration non-blocking i/o -- you have + to keep lots of state. I expect our core filters will all support + non-blocking i/o, well at least the ones I need to make sure we kick + ass on benchmarks. A filter can deny a switch to non-blocking mode, + the server will have to recover gracefully (ha). + +- copy-avoidance + + Hey what about zero copy a la IO-Lite? After having experienced it + in a production setting I'm no longer convinced of its benefits. + There is an enormous amount of overhead keeping lists of buffers, + and reference counts, and cleanup functions, and such which requires + a lot of tuning to get right. I think there may be something here, + but it's not a cakewalk. + + What I do know is that the heuristics I put into apache-1.3 to choose + writev() at times are almost as good as what you can get from doing + full zero-copy in the cases we *currently* care about. To put it + another way, let's wait another generation to deal with zero copy. + + But sendfile/transmitfile/etc. those are still interesting. + + So instead of listing "zero copy" as a property, I'll list + "copy-avoidance". + +So far? + - ap_bungetc added - ap_blookc changed to return the character, rather than take a char *buff - in theory, errno is always useful on return from a BUFF routine - ap_bhalfduplex, B_SAFEREAD will be re-implemented using a layer I think - chunking gone for now, will return as a layer - ebcdic gone for now... it should be a layer + +- ap_iol.h defined, first crack at the layers... + + Step back a second to think on it. Much like we have fread(3) + and read(2), I've got a BUFF and an ap_iol abstraction. An ap_iol + could use a BUFF if it requires some form of buffering, but many + won't require buffering... or can do a better job themselves. + + Consider filters such as: + - ebcdic -> ascii + - encryption + - compression + These all share the property that no matter what, they're going to make + an extra copy of the data. In some cases they can do it in place (read) + or into a fixed buffer... in most cases their buffering requirements + are different than what BUFF offers. + + Consider a filter such as chunking. This could actually use the writev + method to get its job done... depends on the chunks being used. This + is where zero-copy would be really nice, but we can get by with a few + heuristics. + + At any rate -- the NSPR folks didn't see any reason to included a + buffered i/o abstraction on top of their layered i/o abstraction... so + I feel like I'm not the only one who's thinking this way. + +- iol_unix.c implemented... should hold us for a bit
