apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Wed, 06 Jun 2001 01:27:50 GMT
On Tue, Jun 05, 2001 at 05:45:15PM -0700, Greg Stein wrote:
> Now, setaside(pool):
> 
> In this case, let's say that filter FOO is a (main) request filter and is
> doing a setaside. It calls setaside(r->pool). The FILE bucket has its own
> pool (this happens to be subreq->pool), so it calls some pool function to
> see if its pool will live at least as long as the passed-in pool (r->pool in
> this example). It finds "no", so the FILE bucket decides it has some work to
> do. It can choose to do one of two things:

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?

> 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?

> The basic problem with the current setaside() function is that it doesn't
> say *how long* the set-aside bucket should be able to live. Thus, it must
> implement logic to "live forever" (to be conservatively corect), or it will
> simply fail in some circumstances. But then we have the problem that most
> buckets *don't* implement "live forever". The FILE bucket doesn't do
> anything at all; thus, it dies when the subrequest pool goes away.

Based on your description, seems like setaside() should be tossed, while 
setaside(pool) sounds correct.

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


Mime
View raw message