Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 47791 invoked by uid 500); 10 Jul 2000 18:02:33 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 47772 invoked from network); 10 Jul 2000 18:02:33 -0000 Message-ID: <396A0F71.63987E4@Golux.Com> Date: Mon, 10 Jul 2000 14:01:21 -0400 From: Rodent of Unusual Size Organization: The Apache Software Foundation X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: filtering patches References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit rbb@covalent.net wrote: > > They can create sub-pools easily, because they have the request_rec, > but the data shouldn't be allocated out of a pool. Any data > allocated out of a pool sticks around forever. Unless pools are > modified to free memory, or we do some funky sub-pool management, > pools can't be used for filters. Nonsense. If a filter is being treated as a black box, and doesn't know about any external processing state, it can easily create a subpool when called, and destroy it before returning. > The problem with pools isn't that a filter can't find a sub-pool it > created before. The problem is that there are two ways to associate > data with pools. Either each filter has a pool, at which point all > memory has to be allocated for each filter, and the data has to be > copied. Or, the data has it's own pool that is passed around with > the data. You're trying to solve the problem of statefulness in an environment you just said was stateless. "They do not know about where they are in the request processing." Or did you mean that they don't know where they are in the output chain? In any case, your statements above are flawed. You seem to be making tons of assumptions about how filters will use memory, and they all seem to be worst-case. > Not knowing which pool is the parent of the data's pool though, no > pool can be destroyed (to free the memory), because you don't know > which sub-pools will also be destroyed, thus freeing memory the other > filters weren't done with yet. Rubbish. Any subpool would be created by the filter, and it would know there wouldn't be any descendants. If we had tables with binary values (Dirk?), dealing with this would be simple. All a filter has to do is hang some sort of pointer to the pool off the request_rec. That could be done now, in a messy kludgy fashion. You have in no way convinced me of any portion of your sweeping "pools will not work for filters" statement. -- #ken P-)} Ken Coar Apache Software Foundation "Apache Server for Dummies" "Apache Server Unleashed"