httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Wed, 06 Jun 2001 00:45:15 GMT
On Tue, Jun 05, 2001 at 01:49:39PM -0700, Ian Holsman wrote:
> > -----Original Message-----
> > From: Greg Stein [mailto:gstein@lyra.org]
> > Sent: Monday, June 04, 2001 3:18 PM
> > To: new-httpd@apache.org
> > Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18
>...
> > Passing a pool to setaside() should allow us to migrate a 
> > bucket from one
> > pool/lifetime (the subrequest) to another pool/lifetime (the 
> > request or the
> > connection depending on who does a setaside and where they 
> > want to put it).
> 
> ok thats sounds fair..
> 
> the only problem i can see is that most bucket types don't implement the setaside function
> is implementing the setaside (with a pool) going to fix the mod_include problem of not
> having the buckets passed back?

Hmm. I lost the context for the question :-)


Ah! Let me restate to ensure that I've got it right:

  mod_include runs a subrequest to include some other file. The subrequest
  sends a FILE and an EOS bucket into the output filter chain. The EOS is
  chewed up by some subrequest filtering logic. The FILE bucket moves into
  the main request's filter chain. Some filter FOO does a setaside for
  whatever reason. The subrequest is done, so it goes away, which throws out
  the pool. The FILE bucket was in that pool, so it dies and forks up the
  set-aside data.

Correct?

I see one existing problem, and then I'll explain how the setaside(pool)
solves the above problem.

Problem: let's say that filter FOO caused the setaside(). Further, let's say
it did this using ap_save_brigade(). Looking at that function, we see that
it ignores APR_ENOTIMPL returns from setaside(). For the FILE case, that
bungs us up horribly. That NOTIMPL should mean "sorry, buddy. I can't be
setaside. you're screwed."

The doc for setaside() is probably wrong here. I think a no-op should return
APR_SUCCESS ("I am successfully set-aside."). The NOTIMPL or other errors
are just that: the set-aside did not work correctly.

Thus, it appears we have three work items:

1) change the doc on setaside() to remove its comment about NOTIMPL.
   However, it could retain the comment but simply suggest returning
   APR_SUCCESS instead.

2) add apr_bucket_setaside_success to complement
   apr_bucket_setaside_notimpl. This new function would be used by the
   IMMORTAL and HEAP buckets.

3) change ap_save_brigade() to not ignore APR_ENOTIMPL


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:

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.

or

2) read() the file contents into a new POOL(setaside_pool) or HEAP bucket.
   Again, the contents will now live at least as long as the setaside_pool.


Option (2) may be preferable for "small" FILE buckets, on the assumption
that a read(), and the corresponding memory consumption, is cheaper than a
dup() of the file.


If filter FOO is a connection filter, then it will be passing c->pool to the
setaside() function. The bucket then gets set-aside to live as long as the
connection.

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.


I hope that explains the setaside(pool) concept well enough. Of course, ask
questions where it isn't clear.

Cheers,
-g

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

Mime
View raw message