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
