At 09:51 AM 10/21/2003, [EMAIL PROTECTED] wrote:
>William A. Rowe, Jr. wrote:
>>At 03:17 PM 10/20/2003, Aryeh Katz wrote:
>>
>>>I have an input filter that might need to reinvoke the handler that inserted this
>>>input filter (this time with the filter removed).
>
>> Do not attempt to remove a filter once it's inserted, simple force it to be inert.
>
>hmmm?
Ahhh. Now look at the code below. WHO removes the byterange filter?
Answer, the byterange filter removes itself. It *knows* there are no partially
processed buckets that it is holding on to. Nobody else is allowed to add
or remove a filter - but the filter may remove itself when it knows this is
a safe operation.
Be careful here, by the way. We have to be certain that f itself isn't
modified, such that the next reference of f->next isn't corrupted. That
won't occur in 2.0.x. Hopefully 2.1-dev retains that behavior, but for
safetys sake, this code would be better if you dereferenced f->next
and saved it, then called remove, the passed the saved reference.
Somewhat pedantic but it seems cleaner to me.
Bill
>modules/http/http_protocol.c:: ap_byterange_filter()
>
> /* We have nothing to do, get out of the way. */
> if (num_ranges == 0) {
> ap_remove_output_filter(f);
> return ap_pass_brigade(f->next, bb);
> }
>
>Greg
>
