dgaudet 98/03/07 22:07:51
Modified: docs stacked_io
Log:
some comments
Revision Changes Path
1.2 +26 -1 apache-2.0/docs/stacked_io
Index: stacked_io
===================================================================
RCS file: /export/home/cvs/apache-2.0/docs/stacked_io,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- stacked_io 1998/02/09 09:30:01 1.1
+++ stacked_io 1998/03/08 06:07:50 1.2
@@ -1,3 +1,5 @@
+[djg: comments like this are from dean]
+
This past summer, Alexei and I wrote a spec for an I/O Filters API...
this proposal addresses one part of that -- 'stacked' I/O with buff.c.
@@ -262,6 +264,14 @@
will be needed. This continues till B's buffer fills up, then
B will write to C's buffer -- with the same effect.
+[djg: I don't think this is the issue I was really worried about --
+in the case of shrinking transformations you are already doing
+non-trivial amounts of CPU activity with the data, and there's
+no copying of data that you can eliminate anyway. I do recognize
+that there are non-CPU intensive filters -- such as DMA-capable
+hardware crypto cards. I don't think they're hard to support in
+a zero-copy manner though.]
+
The maximum additional number of bytes which will be copied in this
scenario is on the order of nk, where n is the total number of bytes,
and k is the number of filters doing shrinking transformations.
@@ -291,6 +301,10 @@
sent to the next filter without any additional copying. This should
provide the minimal necessary memory copies.
+[djg: Unfortunately this makes it hard to support page-flipping and
+async i/o because you don't have any reference counts on the data.
+But I go into a little detail that already in docs/page_io.]
+
Function chaining
In order to avoid unnecessary function chaining for reads and writes,
@@ -323,6 +337,9 @@
NO_WRITEV is set; hence, it should deal with that case in a reasonable
manner.
+[djg: We can't guarantee atomicity of writev() when we emulate it.
+Probably not a problem, just an observation.]
+
*************************************************************************
Code in buff.c
@@ -457,7 +474,7 @@
}
-----
-If the btransmitfile function is called on a buffer which doesn't
+If the btransmitfile function is called on a buffer which doesn't implement
it, the system will attempt to read data from the file identified
by the file_info_ptr structure and use other methods to write to it.
@@ -491,6 +508,14 @@
calls to bflush. The user-supplied flush function will be called then,
and also before close is called. The user-supplied flush should not
call flush on the next buffer.
+
+[djg: Poorly written "expanding" filters can cause some nastiness
+here. In order to flush a layer you have to write out your current
+buffer, and that may cause the layer below to overflow a buffer and
+flush it. If the filter is expanding then it may have to add more to
+the buffer before flushing it to the layer below. It's possible that
+the layer below will end up having to flush twice. It's a case where
+writev-like capabilities are useful.]
Closing Stacks and Filters
