fanf 00/09/08 23:01:25
Modified: src/include ap_buckets.h
Log:
explain the intent behind the buckets API better
Revision Changes Path
1.24 +28 -14 apache-2.0/src/include/ap_buckets.h
Index: ap_buckets.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/include/ap_buckets.h,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -u -r1.23 -r1.24
--- ap_buckets.h 2000/09/09 01:20:07 1.23
+++ ap_buckets.h 2000/09/09 06:01:24 1.24
@@ -72,27 +72,41 @@
*/
/*
- * The basic concept behind bucket brigades.....
+ * The one-sentence buzzword-laden overview: Bucket brigades represent
+ * a complex data stream that can be passed through a layered IO
+ * system without unnecessary copying. A longer overview follows...
*
* A bucket brigade is a doubly linked list of buckets, so we
* aren't limited to inserting at the front and removing at the end.
* Buckets are only passed around as members of a brigade, although
* singleton buckets can occur for short periods of time.
*
- * Buckets are data stores. They can be files, mmap areas, or just
- * pre-allocated memory. Along with that data come some functions to
- * access it. The functions are relatively simple: read, split,
- * setaside, and destroy.
+ * Buckets are data stores of varous types. They can refer to data in
+ * memory, or part of a file or mmap area, or the output of a process,
+ * etc. Buckets also have some type-dependent accessor functions:
+ * read, split, setaside, and destroy.
+ *
+ * read returns the address and size of the data in the bucket. If the
+ * data isn't in memory then it is read in and the bucket changes type
+ * so that it can refer to the new location of the data. If all the
+ * data doesn't fit in the bucket then a new bucket is inserted into
+ * the brigade to hold the rest of it.
+ *
+ * split divides the data in a bucket into two regions. After a split
+ * the original bucket refers to the first part of the data and a new
+ * bucket inserted into the brigade after the original bucket refers
+ * to the second part of the data. Reference counts are maintained as
+ * necessary.
+ *
+ * setaside ensures that the data in the bucket has a long enough
+ * lifetime. Sometimes it is convenient to create a bucket referring
+ * to data on the stack in the expectation that it will be consumed
+ * (output to the network) before the stack is unwound. If that
+ * expectation turns out not to be valid, the setaside function is
+ * called to move the data somewhere safer.
*
- * read reads a string of data. Currently, it assumes we read all of the
- * data in the bucket. This should be changed to only read the specified
- * amount.
- *
- * split makes one bucket into two at the specified location.
- *
- * setaside ensures that the data in the bucket has a long enough lifetime.
- *
- * free destroys the data associated with the bucket.
+ * destroy maintains the reference counts on the resources used by a
+ * bucket and frees them if necessary.
*
* To write a bucket brigade, they are first made into an iovec, so that we
* don't write too little data at one time. Currently we ignore compacting the
Modified: src/include ap_buckets.h
Log:
explain the intent behind the buckets API better
Revision Changes Path
1.24 +28 -14 apache-2.0/src/include/ap_buckets.h
Index: ap_buckets.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/include/ap_buckets.h,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -u -r1.23 -r1.24
--- ap_buckets.h 2000/09/09 01:20:07 1.23
+++ ap_buckets.h 2000/09/09 06:01:24 1.24
@@ -72,27 +72,41 @@
*/
/*
- * The basic concept behind bucket brigades.....
+ * The one-sentence buzzword-laden overview: Bucket brigades represent
+ * a complex data stream that can be passed through a layered IO
+ * system without unnecessary copying. A longer overview follows...
*
* A bucket brigade is a doubly linked list of buckets, so we
* aren't limited to inserting at the front and removing at the end.
* Buckets are only passed around as members of a brigade, although
* singleton buckets can occur for short periods of time.
*
- * Buckets are data stores. They can be files, mmap areas, or just
- * pre-allocated memory. Along with that data come some functions to
- * access it. The functions are relatively simple: read, split,
- * setaside, and destroy.
+ * Buckets are data stores of varous types. They can refer to data in
+ * memory, or part of a file or mmap area, or the output of a process,
+ * etc. Buckets also have some type-dependent accessor functions:
+ * read, split, setaside, and destroy.
+ *
+ * read returns the address and size of the data in the bucket. If the
+ * data isn't in memory then it is read in and the bucket changes type
+ * so that it can refer to the new location of the data. If all the
+ * data doesn't fit in the bucket then a new bucket is inserted into
+ * the brigade to hold the rest of it.
+ *
+ * split divides the data in a bucket into two regions. After a split
+ * the original bucket refers to the first part of the data and a new
+ * bucket inserted into the brigade after the original bucket refers
+ * to the second part of the data. Reference counts are maintained as
+ * necessary.
+ *
+ * setaside ensures that the data in the bucket has a long enough
+ * lifetime. Sometimes it is convenient to create a bucket referring
+ * to data on the stack in the expectation that it will be consumed
+ * (output to the network) before the stack is unwound. If that
+ * expectation turns out not to be valid, the setaside function is
+ * called to move the data somewhere safer.
*
- * read reads a string of data. Currently, it assumes we read all of the
- * data in the bucket. This should be changed to only read the specified
- * amount.
- *
- * split makes one bucket into two at the specified location.
- *
- * setaside ensures that the data in the bucket has a long enough lifetime.
- *
- * free destroys the data associated with the bucket.
+ * destroy maintains the reference counts on the resources used by a
+ * bucket and frees them if necessary.
*
* To write a bucket brigade, they are first made into an iovec, so that we
* don't write too little data at one time. Currently we ignore compacting the