httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Wed, 06 Jun 2001 00:28:21 GMT
On Tue, Jun 05, 2001 at 02:01:01PM -0700, wrote:
> > > 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
> > is implementing the setaside (with a pool) going to fix the mod_include problem
of not
> > having the buckets passed back?
> Greg's idea requires that more buckets implement the setaside function.
> The other idea of just having the sub_request_filter handle the problem
> doesn't have that requirement.

Well, taking a pool means that the buckets have more capability. At the
moment, some buckets don't implement setaside() which means they can't
change their lifetimes.

To be concrete: the FILE bucket cannot be setaside. Therefore, if you want
to hold onto a FILE bucket for some period of time, then you have to read
its contents out and set *those* aside.

On the other hand, taking a pool in the setaside() means we can ask the FILE
bucket to "do whatever is best to keep the FILE bucket for <this> lifetime."
It can then choose to dup() the file, read it into a HEAP or POOL bucket, or
continue to fail.

So... yes, it would require more buckets implement it because we're adding
more functionality. But once we have it, then we can do some really neat
stuff with them.


Greg Stein,

View raw message