You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Cliff Woolley <cl...@yahoo.com> on 2000/11/13 05:10:22 UTC

[PATCH] bucket split compromise (Was RE: Implementing split() on pipe buckets?)

--- "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> The cases we are discussing are all fifo problems.  Can't we have a common
> wrapper that handles (with the extra error conditions) any fifo bucket, outside
> of the explicit and atomic calls (split, duplicate) that offer predictable fifo
> behavior for filters that don't care to work around these issues themselves?
> e.g. ap_bucket_split_any, ap_bucket_duplicate_any, etc.  They can carry their
> documented shortcomings, and the author who uses them does so at a cost?

+1.  I presume the following is what you mean?

--Cliff


Index: include/ap_buckets.h
===================================================================
RCS file: /home/cvspublic/apache-2.0/src/include/ap_buckets.h,v
retrieving revision 1.50
diff -u -r1.50 ap_buckets.h
--- include/ap_buckets.h	2000/11/10 04:53:24	1.50
+++ include/ap_buckets.h	2000/11/13 03:50:15
@@ -492,7 +492,7 @@
 
 /**
  * free the resources used by a bucket. If multiple buckets refer to
- * the same resource it is freed when the last one goes away.
+ *    the same resource it is freed when the last one goes away.
  * @param e The bucket to destroy
  * @deffunc void ap_bucket_destroy(ap_bucket *e)
  */
@@ -503,7 +503,8 @@
     }
 
 /**
- * read the data from the bucket
+ * read the data from the bucket.  This is guaranteed to be
+ *    implemented for all bucket types.
  * @param e The bucket to read from
  * @param str The location to store the data in
  * @param len The amount of data read
@@ -514,20 +515,35 @@
 
 /**
  * Setaside data so that stack data is not destroyed on returning from
- * the function
+ *    the function.  If this doesn't make sense for the bucket type,
+ *    then APR_ENOTIMPL is returned.
  * @param e The bucket to setaside
  * @deffunc apr_status_t ap_bucket_setaside(ap_bucket *e)
  */
 #define ap_bucket_setaside(e) e->type->setaside(e)
 
 /**
- * Split one bucket in two.
+ * Split one bucket in two by duplicating the bucket (not the data) and
+ *    modifying any necessary start/end/offset information.  If it's not
+ *    possible to do this (perhaps the length of the data is indeterminate),
+ *    then APR_ENOTIMPL is returned.
  * @param e The bucket to split
  * @param point The location to split the bucket at
  * @deffunc apr_status_t ap_bucket_split(ap_bucket *e, apr_off_t point)
  */
 #define ap_bucket_split(e,point) e->type->split(e, point)
 
+/**
+ * Split a bucket into two by splitting the bucket, if possible, using
+ *    ap_bucket_split().  If split() is not implemented for the bucket
+ *    type, then we perform a blocking read on the bucket, thereby
+ *    morphing the bucket into a splittable bucket, and then split
+ *    that bucket.
+ * @param e The bucket to split
+ * @param point The location to split the bucket at
+ * @deffunc apr_status_t ap_bucket_split_any(ap_bucket *e, apr_off_t point)
+ */
+AP_DECLARE(apr_status_t) ap_bucket_split_any(ap_bucket *e, apr_off_t point);
 
 /* Bucket type handling */
 
Index: ap/ap_buckets.c
===================================================================
RCS file: /home/cvspublic/apache-2.0/src/ap/ap_buckets.c,v
retrieving revision 1.31
diff -u -r1.31 ap_buckets.c
--- ap/ap_buckets.c	2000/11/10 19:01:29	1.31
+++ ap/ap_buckets.c	2000/11/13 03:50:17
@@ -229,6 +229,33 @@
     return bucket_types->nelts - 1;
 }
 
+AP_DECLARE(apr_status_t) ap_bucket_split_any(ap_bucket *e, apr_off_t point)
+{
+    apr_status_t rv;
+    const char *str;
+    apr_size_t len;
+
+    /* try to split this bucket directly */
+    rv = ap_bucket_split(e, point);
+    if (rv != APR_ENOTIMPL) {
+        return rv;
+    }
+
+    /* if the bucket cannot be split, we must read from it,
+     * changing its type to one that can be split */
+    if (point < 0) {
+        return APR_EINVAL;
+    }
+    rv = ap_bucket_read(e, &str, &len, AP_BLOCK_READ);
+    if (rv != APR_SUCCESS) {
+        return rv;
+    }
+    if (point > len) {
+        return APR_EINVAL;
+    }
+    return ap_bucket_split(e, point);
+}
+
 AP_DECLARE_NONSTD(apr_status_t) ap_bucket_setaside_notimpl(ap_bucket *data)
 {
     return APR_ENOTIMPL;




__________________________________________________
Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!
http://calendar.yahoo.com/

RE: [PATCH] bucket split compromise (Was RE: Implementing split()onpipe buckets?)

Posted by rb...@covalent.net.
On Sun, 12 Nov 2000, William A. Rowe, Jr. wrote:

> Does this mean we are all on the same page again :-?  Cool.

As long as the pipe/socket split doesn't go into the core bucket code
until we talk some more, yes we are on the same page again.  :-)

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


RE: [PATCH] bucket split compromise (Was RE: Implementing split()onpipe buckets?)

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Does this mean we are all on the same page again :-?  Cool.

> -----Original Message-----
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Sunday, November 12, 2000 10:24 PM
> To: new-httpd@apache.org
> Subject: RE: [PATCH] bucket split compromise (Was RE: Implementing
> split()onpipe buckets?)
> 
> 
> On Sun, 12 Nov 2000, William A. Rowe, Jr. wrote:
> 
> > > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > > Sent: Sunday, November 12, 2000 10:17 PM
> > > 
> > > +1 for all the docs changes.
> > > 
> > > +1 for the split function, -1 for putting it into 
> ap_buckets.c.  Until
> > > this code is actually put into the buckets themselves (I 
> > > disagree that it should), this code belongs in util_filter.c.
> > 
> > +1 here too.  And I'd suggest we start an ap_buckets_util.c 
> for these
> > sorts of accessors that would otherwise polute the buckets 
> themselves
> > (making them non-atomic) but don't do anything but provide bucket
> > utility functions.
> 
> I could go along with that.  I would ask that it go in ap/.
> 
> This keeps it in the same general location, but out of the 
> core buckets
> code.  :-)
> 
> Ryan
> 
> ______________________________________________________________
> _________________
> Ryan Bloom                        	rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> --------------------------------------------------------------
> -----------------
> 
> 

RE: [PATCH] bucket split compromise (Was RE: Implementing split()on pipe buckets?)

Posted by rb...@covalent.net.
On Sun, 12 Nov 2000, William A. Rowe, Jr. wrote:

> > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > Sent: Sunday, November 12, 2000 10:17 PM
> > 
> > +1 for all the docs changes.
> > 
> > +1 for the split function, -1 for putting it into ap_buckets.c.  Until
> > this code is actually put into the buckets themselves (I 
> > disagree that it should), this code belongs in util_filter.c.
> 
> +1 here too.  And I'd suggest we start an ap_buckets_util.c for these
> sorts of accessors that would otherwise polute the buckets themselves
> (making them non-atomic) but don't do anything but provide bucket
> utility functions.

I could go along with that.  I would ask that it go in ap/.

This keeps it in the same general location, but out of the core buckets
code.  :-)

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


RE: [PATCH] bucket split compromise (Was RE: Implementing split()on pipe buckets?)

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Sunday, November 12, 2000 10:17 PM
> 
> +1 for all the docs changes.
> 
> +1 for the split function, -1 for putting it into ap_buckets.c.  Until
> this code is actually put into the buckets themselves (I 
> disagree that it should), this code belongs in util_filter.c.

+1 here too.  And I'd suggest we start an ap_buckets_util.c for these
sorts of accessors that would otherwise polute the buckets themselves
(making them non-atomic) but don't do anything but provide bucket
utility functions.

Re: [PATCH] bucket split compromise (Was RE: Implementing split() on pipe buckets?)

Posted by rb...@covalent.net.
+1 for all the docs changes.

+1 for the split function, -1 for putting it into ap_buckets.c.  Until
this code is actually put into the buckets themselves (I disagree that it
should), this code belongs in util_filter.c.

Ryan



> --- ap/ap_buckets.c	2000/11/10 19:01:29	1.31
> +++ ap/ap_buckets.c	2000/11/13 03:50:17
> @@ -229,6 +229,33 @@
>      return bucket_types->nelts - 1;
>  }
>  
> +AP_DECLARE(apr_status_t) ap_bucket_split_any(ap_bucket *e, apr_off_t point)
> +{
> +    apr_status_t rv;
> +    const char *str;
> +    apr_size_t len;
> +
> +    /* try to split this bucket directly */
> +    rv = ap_bucket_split(e, point);
> +    if (rv != APR_ENOTIMPL) {
> +        return rv;
> +    }
> +
> +    /* if the bucket cannot be split, we must read from it,
> +     * changing its type to one that can be split */
> +    if (point < 0) {
> +        return APR_EINVAL;
> +    }
> +    rv = ap_bucket_read(e, &str, &len, AP_BLOCK_READ);
> +    if (rv != APR_SUCCESS) {
> +        return rv;
> +    }
> +    if (point > len) {
> +        return APR_EINVAL;
> +    }
> +    return ap_bucket_split(e, point);
> +}
> +
>  AP_DECLARE_NONSTD(apr_status_t) ap_bucket_setaside_notimpl(ap_bucket *data)
>  {
>      return APR_ENOTIMPL;
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Calendar - Get organized for the holidays!
> http://calendar.yahoo.com/
> 
> 


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------