Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
From: "William A. Rowe, Jr." <wrowe@lnd.com>
To: <new-httpd@apache.org>
Subject: Not [PATCH] Filter registration :)
Date: Mon, 24 Jul 2000 20:55:54 -0500
Message-ID: <000d01bff5db$9842a290$345985d0@corecomm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20000724184722.J10898@lyra.org>
Importance: Normal

And you suggest there are no issues with filtering + async (LOL)

> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Monday, July 24, 2000 8:47 PM
>
> If a bucket has a self-defined lifetime, then the ap_bucket_t must be
> allocated from the heap/pool. Usually, its data must also be managed in a
> way that is separate from the execution stack (e.g. rmem buckets have issues
> in that they can refer to stack-based data; that prevents their self-
> defined lifetime).

I actually found your #3 - pipe read is a terminal condition that can't be
undone, to be the most significant issue.

By definition, when and if we transition to async buckets, nothing can be
living on the stack.  Not that we can't pass the bucket from filter to
filter as arguments, but it needs to live in the pool.  And, as far as 
the lifetime is concerned, I suggest they live for the duration of their 
request, unless discarded (read on :)

Is there any thought to fixed-size buckets (8k, for example) in a common
pool for the process (talking about a threaded model, here, or perhaps
in shared memory across processes) that will live for eternity?  Simply 
grab and discard as the filters pass them around.  If I must rewrite a 
bucket (can't just tweak it), then grab another bucket and throw the 
last back to the pool.  If I need a second bucket (growing the response), 
then I need to just grab one from the pool.  All buckets must be thrown 
back into the available pool by Apache at the end of the request.

I don't like relying on the module writer to do-it-right when we will be
dying a slow, painful death due to a module's leak.

The advantage lies in the fact that shared file memory can be swapped in
and out, the bucket list can grow if necessary, and could even be shrunk
if we always allocate from the head (so once that ornery huge request is
done, and odd leftover buckets are released, noone is sitting at the end
of the pool.)

Thoughts?

Bill