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
