Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Fri, 21 Jul 2000 20:27:47 -0700
From: Greg Stein <gstein@lyra.org>
To: new-httpd@apache.org
Subject: Re: buckets: should we pass buckets or brigades?
Message-ID: <20000721202746.B10086@lyra.org>
Mail-Followup-To: new-httpd@apache.org
References: <s978d38b.028@WISDOM.uc.wlu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <s978d38b.028@WISDOM.uc.wlu.edu>;
 from JWOOLLEY@wlu.edu on Fri, Jul 21, 2000 at 10:49:42PM -0400

The bucket design in my patch uses the second, simplified form. It is
definitely much easier to work with :-)

Note also that there is no real concept of "allocating" a bucket either, as
their lifetimes are defined to match that of the function call. In other
words, you can do:

  {
      ap_bucket_t b = { ... };
      
      ap_pass_bucket(&b);
  }

The next filter is not allowed to retain a reference to it since the
definition of the bucket is "it will go away when you return." 

Cheers,
-g

On Fri, Jul 21, 2000 at 10:49:42PM -0400, Cliff Woolley wrote:
> 
> I think some more cleanup could be done if we clarify exactly what the
> scope of a bucket brigade is.  I'm just now starting to look at the
> actual filtering code (I've been concentrating on the bucket type itself
> up to now)... I was always under the impression that a request would
> have *one* brigade, and that the *buckets* would be passed from filter
> to filter (hence the bucket brigade analogy... you pass buckets).  But
> apparently we're creating new bucket brigades pretty much every time we
> create a new bucket and catenating them on to one another?  The only
> benefit that I can think of is that you don't have to walk the list to
> find the tail again... but I need to look at that all of that code some
> more; maybe I'm missing something.
> 
> The way I see it, there are two options:
> 
> ----------------------------------------------------------------
> Option #1: Keep on passing brigades with ap_pass_brigade() like we are
> now.  In this case, it would probably make sense to be able to create a
> brigade and immediately put a bucket in it just as a bucket will be able
> to be created with something in it after my forthcoming patch (discussed
> in my previous email).  If you create the bucket first, then the
> sequence would look like:
> 
> b=ap_bucket_type_create(buf, nbyte);
> bb=ap_bucket_brigade_create(r->pool, b);
> ap_pass_brigade(bb);
> 
> instead of
> 
> bb=ap_bucket_brigade_create(r->pool);
> b=ap_bucket_type_create(buf, nbyte);
> ap_bucket_brigade_append_buckets(bb, b);
> ap_pass_brigade(bb);
> 
> It's a step in the right direction, but you still have two problems
> here: (a) it takes an extra step to create a new bucket brigade for just
> that one new bucket that needs to be passed on, and (b) after you call
> ap_pass_brigade(), the brigade you created ends up getting catenated
> onto the end of another one and emptied out, and since brigades are now
> allocated out of r->pool, you end up with loads of empty brigade
> structures floating around for the lifetime of r->pool.  That doesn't
> seem right to me.
> 
> ----------------------------------------------------------------
> Option #2: Pass buckets instead of bucket brigades (seems to make more
> sense to me): In this case, we avoid the problem of all the extra
> ap_bucket_brigade structures floating around and we can simplify the API
> yet again:
> 
> b=ap_bucket_type_create(buf, nbyte);
> ap_pass_bucket(b);
> 
> or even just
> 
> ap_pass_bucket(ap_bucket_type_create(buf, nbyte));
> 
> 
> (That last one might be a little severe, especially if we want more
> error checking in there... I'm just trying to make a point.)
> 
> ----------------------------------------------------------------
> 
> What do you think?
> 
> --Cliff
> 
> 
> Cliff Woolley
> Central Systems Software Administrator
> Washington and Lee University
> http://www.wlu.edu/~jwoolley/
> 
> Work: (540) 463-8089
> Pager: (540) 462-2303

-- 
Greg Stein, http://www.lyra.org/