apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Wed, 06 Jun 2001 03:35:33 GMT
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.

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

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

+1.

> 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.  =-)  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.  Tying it to a pool makes it a
*much* more useful function.

--Cliff


--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA



Mime
View raw message