apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <s.stri...@striker.nl>
Subject Re: apr_pool_create_core_ex, WAS: Re: svn commit: r647384 - in /apr/apr/trunk: CHANGES include/apr_pools.h memory/unix/apr_pools.c
Date Tue, 08 Jul 2008 13:33:06 GMT
On Tue, Jul 8, 2008 at 3:26 PM, William A. Rowe, Jr.
<wrowe@rowe-clan.net> wrote:
> Mladen Turk wrote:
>> Again, the global allocator might get destroyed before the
>> child pool since for it the owner is global pool.
> Interesting observation, hinging on being a bug itself.

All pools are guaranteed to live as long as the global pool, at least
under the previous implementation.  That ensures that the global
allocator lives as long as any pool.  The global pool will destroy it
once it goes away on apr_pool_terminate(), which is called by

>> Making sure that apr_terminate is called as last makes the need
>> for tracking the child pools, and it breaks the OO language paradigm.
>> The point is that one can call apr_terminate at some exit point, but
>> that would require to wait for all objects to detach itself, and make
>> event mechanism for breaking the long running functions (like file or
>> network).
> Nope.  As in most object paradigms, init/terminate is reference counted
> and final destruction is held for refcount reaching zero.

Indeed.  After the last apr_terminate(), behavior is undefined.



View raw message