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
[EMAIL PROTECTED]
Charlottesville, VA
