Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 44455 invoked by uid 500); 13 Oct 2000 16:02:48 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 44414 invoked from network); 13 Oct 2000 16:02:45 -0000 X-Authentication-Warning: koj: rbb owned process doing -bs Date: Fri, 13 Oct 2000 09:03:42 -0700 (PDT) From: rbb@covalent.net X-Sender: rbb@koj To: new-httpd@apache.org Subject: Re: cvs commit: apache-2.0/src/modules/standard mod_include.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On 13 Oct 2000, Jeff Trawick wrote: > rbb@locus.apache.org 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. The problem right now as far as speed is concerned, is that we are actually using an index into an array rather than a pointer to another structure. The performance issue can be solved by 1), removing the functions, and replacing them with macros. 2) using a pointer to a structure rather than an index into an array. 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. 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. Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------