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:25:43 GMT
On Tue, 5 Jun 2001, Greg Stein wrote:

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

I actually suggested something like this a long, long time ago, and Ryan
shot me down:

http://marc.theaimsgroup.com/?l=apache-new-httpd&m=97379194223807&w=2


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

+1.  I like this approach.  For clarity, a setaside of a transient bucket
would result in what?  A pool bucket?  Or should we just go ahead and
make it a heap bucket like we're doing now?

--Cliff


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




Mime
View raw message