httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: cvs commit: apache-2.0/src/modules/standard mod_include.c
Date Fri, 13 Oct 2000 18:19:23 GMT writes:

> On 13 Oct 2000, Jeff Trawick wrote:
> > writes:
> > >   Log:
> > >   Remove all function pointers from the ap_bucket type.  These function
> > >   pointers are replaced with a global table that allows modules to register
> > >   their bucket types.  Those bucket types are then allowed to be used in
> > >   the server processing.  This also required removing all direct calls to
> > >   those functions.  The ap_bucket type has an index into an array, so in
> > >   each ap_bucket_* function, we use that index to find the correct set of
> > >   functions.
> > 
> > What is the purpose of this?  We just got even slower.
> The purpose is to shrink the size of the buckets structure so that we
> allocate them faster.  

When we use a pool of bucket structures, the cost of allocation will
be unrelated to the size of the bucket structure.  I doubt that even
with the current allocation code the current shrinkage results in
faster allocation/deallocation, but that is irrelevant.

> This also divorces the bucket structure from the currently implemented
> bucket types, and makes it possible for people to extend the bucket
> types.  Think of an SSL socket for input filtering.  We can't use a
> standard socket_bucket, because that would use the wrong recv
> function.

So prior to this patch, if I'm mod_ssl and I create an instance of my
custom bucket type and pass it up, where is the baddness?  I need to
make sure that the type doesn't collide with any core-provided types
(a simple ap_get-me-a-type() will take care of that).  I need to
provide the proper read() and destroy() and split() functions.

> This has been documented as a necessary enhancement for some time in the
> header files, and doing now keeps us from using e->read or e->split or
> e->destroy, because they won't work at all anymore.
> I have already been asked by at least one other person for a way to
> implement their own bucket types that their module understands.  This
> allows for that, the previous design didn't, because it used an enumerated
> type for bucket type.

The old mechanism can use enumerated values for core-provided bucket
types and use values above the max for bucket types which have to be
explicitly registered.

I already miss the ability to print a bucket in gdb and have it tell
me in words what the type of the bucket is.

Jeff Trawick | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message