httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gst...@apache.org
Subject cvs commit: httpd-2.0/server core.c
Date Tue, 01 May 2001 18:43:10 GMT
gstein      01/05/01 11:43:10

  Modified:    server   core.c
  Log:
  Add a comment about an assumption we make in our keepalive buffering.
  
  Delay the check for "too many items in an iovec" until we actually try to
  put something in there. This allows that N+1 bucket to be an EOS, FLUSH,
  FILE, or zero-length bucket without triggering a split. Only if that next
  bucket has iovec data will a split be made.
  
  Revision  Changes    Path
  1.11      +23 -10    httpd-2.0/server/core.c
  
  Index: core.c
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/server/core.c,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -u -r1.10 -r1.11
  --- core.c	2001/04/29 17:05:49	1.10
  +++ core.c	2001/05/01 18:43:09	1.11
  @@ -3092,29 +3092,31 @@
   
                   rv = apr_bucket_read(e, &str, &n, APR_BLOCK_READ);
                   if (n) {
  -                    nbytes += n;
                       if (!fd) {
  +                        if (nvec == MAX_IOVEC_TO_WRITE) {
  +                            /* woah! too many. stop now. */
  +                            more = apr_brigade_split(b, e);
  +                            break;
  +                        }
                           vec[nvec].iov_base = (char*) str;
                           vec[nvec].iov_len = n;
                           nvec++;
                       }
                       else {
                           /* The bucket is a trailer to a file bucket */
  +
  +                        if (nvec_trailers == MAX_IOVEC_TO_WRITE) {
  +                            /* woah! too many. stop now. */
  +                            more = apr_brigade_split(b, e);
  +                            break;
  +                        }
                           vec_trailers[nvec_trailers].iov_base = (char*) str;
                           vec_trailers[nvec_trailers].iov_len = n;
                           nvec_trailers++;
                       }
  +                    nbytes += n;
                   }
               }
  -    
  -            if ((nvec == MAX_IOVEC_TO_WRITE) || 
  -                (nvec_trailers == MAX_IOVEC_TO_WRITE)) {
  -                /* Split the brigade and break */
  -                if (APR_BUCKET_NEXT(e) != APR_BRIGADE_SENTINEL(b)) {
  -                    more = apr_brigade_split(b, APR_BUCKET_NEXT(e));
  -                }
  -                break;
  -            }
           }
       
           /* Completed iterating over the brigades, now determine if we want 
  @@ -3153,6 +3155,17 @@
                       apr_size_t n;
   
                       rv = apr_bucket_read(bucket, &str, &n, APR_BLOCK_READ);
  +
  +                    /* This apr_brigade_write does not use a flush function
  +                       because we assume that we will not write enough data
  +                       into it to cause a flush. However, if we *do* write
  +                       "too much", then we could end up with transient
  +                       buckets which would suck. This works for now, but is
  +                       a bit shaky if changes are made to some of the
  +                       buffering sizes. Let's do an assert to prevent
  +                       potential future problems... */
  +                    AP_DEBUG_ASSERT(AP_MIN_BYTES_TO_WRITE <
  +                                    APR_BUCKET_BUFF_SIZE);
                       apr_brigade_write(ctx->b, NULL, NULL, str, n);
                   }
                   apr_brigade_destroy(b);
  
  
  

Mime
View raw message