Let's do this. I will review and think about changes from the h2 angle...
> Am 20.10.2015 um 11:24 schrieb Yann Ylavic <ylavic....@gmail.com>:
>
> On Tue, Oct 20, 2015 at 10:42 AM, Stefan Eissing
> <stefan.eiss...@greenbytes.de> wrote:
>>
>>> Am 20.10.2015 um 09:44 schrieb Plüm, Rüdiger, Vodafone Group
>>> <ruediger.pl...@vodafone.com>:
>>>
>>>> -----Original Message-----
>>>> From: Yann Ylavic [mailto:ylavic....@gmail.com]
>>>> Sent: Montag, 19. Oktober 2015 22:30
>>>>>
>>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=58503
>>>>>
>>>>> --- Comment #8 from Yann Ylavic <ylavic....@gmail.com> ---
>>>>> (In reply to Ruediger Pluem from comment #7)
>>>>>> Actually I think mod_proxy_wstunnel falls into the same pitfall
>>>>>> mod_proxy_http was in and it needs to do the same / something similar
>>>> then
>>>>>> mod_proxy_http.c with
>>>>>>
>>>>>> proxy_buckets_lifetime_transform
>>>>>
>>>>>
>>>>> We need to either use lifetime_transform like in proxy_http, or I was
>>>>> thinking
>>>>> of modifying all the input filters that create their buckets on f->r/c's
>>>>> pool/bucket_alloc so that they now use their given bb->p and bb-
>>>>> bucket_alloc.
>>>
>>> I don't think that this is a good idea, because bucket brigades sometimes
>>> have a longer lifetime
>>> then the buckets that are created right now with f->r/c'spool/bucket_alloc.
>>> They get created and are kept
>>> and only get cleared to avoid creating them over and over again. So this
>>> step can open up a big
>>> can of worms. Furthermore it is an API change, because currently the caller
>>> expects the buckets
>>> are created with f->r/c'spool/bucket_alloc und you cannot change that
>>> expectation for 3rd party modules.
>>>
>>> So if at all a change for trunk only that requires a very deep review of
>>> all brigade usages.
>>
>> As I learned, bucket brigades are very optimized for the common HTTP/1 case:
>> appearing during one
>> request and going away together with the request - preferably with only one
>> thread involved.
>
> What I proposed is precisely to let the caller of ap_get_brigade()
> decide the lifetime of the buckets it gets, by the involved input
> filters playing the game.
> But I agree we would still need a "safe guard" like
> bucket_lifetime_transform() which would do the right thing for
> (third-party) buckets that do not match, whereas in the common case we
> would avoid any copy.
> I suspect this could also help the h2 case by having spare/recycled
> brigades which could be shared/exchanged with the single writer on the
> client connection.
> I'm not sure this would break anything in 2.4.x, but since this is
> quite theorical for now, let me try a first implementation which will
> help me think more about the implications.
>
> Regards,
> Yann.
