httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: svn commit: r307339 - in /httpd/httpd/branches/async-dev
Date Sun, 09 Oct 2005 19:48:36 GMT
On Oct 9, 2005, at 11:41 AM, Nick Kew wrote:

> On Sunday 09 October 2005 18:49, Brian Pane wrote:
>
>> On Oct 9, 2005, at 3:25 AM, Nick Kew wrote:
>>
>>> On Sunday 09 October 2005 02:37, brianp@apache.org wrote:
>>>
>>>> URL: http://svn.apache.org/viewcvs?rev=307339&view=rev
>>>> Log:
>>>> Redesign of request cleanup:
>>>>   - A new End-Of-Request bucket is pushed through the output filter
>>>>     chain after the last bucket of the response.
>>>>   - This bucket gets destroyed by ap_core_output_filter() after the
>>>>     buckets in front of it have been sent.
>>>>   - The destroy callback of the EOR bucket invokes the access  
>>>> logger
>>>>     and frees the request's pool.
>>>>
>>>
>>> How do you see this looking from a filter programmer's POV?  I  
>>> can see
>>> a danger of some nasty bugs arising from confusion between this and
>>> EOS buckets:
>>>
>>>  - Existing filters test for EOS and will ignore EOR.  That's
>>> presumably
>>>    fine with you.
>>>  - Sooner or later, someone will write a filter that propagates EOR
>>>    and not EOS.  Bang!
>>>
>>> Is there no way you could use EOS directly?
>>>
>>
>> I can think of two easy solutions:
>>
>> - Wrap the EOR declaration in "#ifdef CORE_PRIVATE," just
>>    like we do for EOC.
>>
>
> So what does my filter see?  A bucket of type <unknown>?
>
> How does this fit with filters of the common form:
>
> loop over buckets {
>   if (is data) {
>      read the data;
>      write something to the next filter;
>   } else if (is EOS) {
>      write EOS to next filter;
>      cleanup and return;
>   }
>   /* ignore anything else */
> }
>
> If there was an EOR bucket on input, it's lost in the above, yesno?
> How do you deal with that?  If it doesn't break or break on this  
> logic,
> I'm fine with it.

If this example is a request-layer filter, no problem: the EOR
buckets are inserted at the connection layer.

If a connection-layer filter uses this logic (throwing away
metadata buckets it doesn't understand), it's already broken,
since EOC buckets pass through the connection layer
output filters.

Unless I'm missing something, EOR buckets wouldn't
be at greater risk than EOC buckets are today.   We'd
just need to document the implied API rule: "don't destroy
EOR buckets if you're not ap_core_output_filter."  This
is a subtle enough API change that I wouldn't propose
backporting it to 2.0, but we could introduce it into 2.2
or 2.4.

>> - Or modify the EOS bucket API to support an optional "on_destroy"
>>    callback.
>>
>
> Smells of side-effects.  EOS buckets get created and destroyed by
> intermediate filters - as in my above skeleton.

I agree.  There's a subset of problems that could be solved
by adding reference counts to the EOS buckets, but refcounts
wouldn't solve the general problem of request-layer filters that
destroy EOS filters and create new ones.

Brian


Mime
View raw message