Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 6 Jun 2001 00:25:38 -0700
From: Greg Stein <gstein@lyra.org>
To: new-httpd@apache.org, dev@apr.apache.org
Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18
Message-ID: <20010606002537.W23560@lyra.org>
Mail-Followup-To: new-httpd@apache.org, dev@apr.apache.org
References: <20010605182750.M21860@ebuilt.com>
 <Pine.GSO.4.32.0106052327200.28921-100000@cobra.cs.Virginia.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <Pine.GSO.4.32.0106052327200.28921-100000@cobra.cs.Virginia.EDU>;
 from cliffwoolley@yahoo.com on Tue, Jun 05, 2001 at 11:35:33PM -0400

On Tue, Jun 05, 2001 at 11:35:33PM -0400, Cliff Woolley wrote:
> On Tue, 5 Jun 2001, Justin Erenkrantz wrote:
> > With you up until here, but how does the pool know that it won't live as
> > long as another pool?  If a pool is a child of a pool, then we know that
> > it won't last as long as its parent?
> 
> A pool is guaranteed to live at least as long as all its children (and,
> conversely, a child pool is guaranteed to last no longer than its parent).
> Therefore, if you say "make sure you last as long as pool foo", all that
> has to be done is to make sure that the pool you're actually using is
> either == foo or is an ancestor of foo.  You just walk the parent pointers
> until you find a match.

The problem can be a little bit harder. Note that the two pools could be on
disjoint branches of some other pool.

    P1
   /  \
 P2    P3

If we called setaside(P2) on a bucket using P3, then we "should" use P1 as
the pool for allocation. However, that could cause some extreme leakage.
Consider the case where P1 == global pool. For disjoint pools like this
(where we can't effectively move data into P2's scope), the setaside()
should simply punt, or it can copy the data into a HEAP bucket (which is
effectively immortal).

Note that most buckets should be able to move from P3 to P2. A FILE bucket
simply dups into P2. Same for MMAP. A POOL bucket would just copy over to a
P2-based bucket. etc.

And note that normally, this kind of disjoint behavior won't happen. We'll
be migrating "up the pool chain". P1 would correspond to the r->pool. P0
might be c->pool. The above scenario could happen if P2 is a pool private to
filter FOO.
[ but again: most buckets will be able to move their contents to another
  pool without much problem ]

Note that apr_pool_is_ancestor() would be yanked from the DEBUG-only
compilation and made available to the runtime.

> > > 1) call apr_file_dup(&new_file, bucket->file, setaside_pool). This
> > >    duplicates the file into the new pool, ensuring that the bucket now lives
> > >    as long as the given pool.
> >
> > I didn't think dup was *that* expensive, but maybe I'm wrong.  Maybe on
> > non-Unix platforms, dup is expensive?
> 
> There are some platforms where this is true, yes.  IIRC, Windows is one of
> them.

Right. And the meta-point is that a bucket can decide what is best, and can
fine-tune its behavior. We don't have to scatter that behavior to all
setaside() callers.

>...
> > I remember wrestling with setaside a few months ago for the keepalive
> > problem.  I remember asking myself, "What does setaside() do again?"
> > Be nice to see it do what it says it does.  -- justin
> 
> Well, right now it *does* do what it says it does... it just says
> something different.  =-)

Right.

> The current implementation is really very
> specific to transient buckets.  It was tailored to the needs of transient
> buckets from day one (not that that's a good thing), which is why it was
> never implemented for ANY other type.

Exactly. The intent was to allow for transient buckets within the filter
chain. But those presented certain problems, which the "setaside" concept
solved. However, that didn't go quite far enough.

> Tying it to a pool makes it a *much* more useful function.

I would agree :-)

Cheers,
-g

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