Am 23.01.2017 um 23:42 schrieb Yann Ylavic:
> On Mon, Jan 23, 2017 at 11:37 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
>> Hi Stefan,
>>
>> On Mon, Jan 23, 2017 at 9:54 PM, Stefan Eissing
>> <stefan.eiss...@greenbytes.de> wrote:
>>>
>>> I am not aware of any special expectations now. Almost all is triggered by
>>> (parent) pool cleanups and is therefore more deterministic than before. The
>>> only explicit destroy is done on finished streams and slave connections no
>>> longer used. When the master conn disappears, all is deallocated as the
>>> force wills it.
>>
>> I wonder if the attached patch makes sense.
>> If beam_{recv,send}_cleanup() are to be executed on (parent) pool
>> destroy, there will be before beam_cleanup() itelf (which also calls
>> beam_send_cleanup() explicitly), so it should avoid potential a double
>> cleanup in this case.
>>
>> WDYT?
>
> Please ignore the last (garbage) hunk.
last garbage hunk?
This one?
@@ -520,8 +529,8 @@ static apr_status_t beam_cleanup(void *data)
* beam should have lost its mutex protection, meaning
* it is no longer used multi-threaded and we can safely
* purge all remaining sender buckets. */
- apr_pool_cleanup_kill(beam->send_pool, beam,
beam_send_cleanup);
ap_assert(!beam->m_enter);
+ beam_set_send_pool(beam, NULL);
beam_send_cleanup(beam);
}
ap_assert(H2_BPROXY_LIST_EMPTY(&beam->proxies));
Stefan
