apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
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 12:02:34 GMT
Sander Striker wrote:
> 
>> Unlike traditional pool it creates standalone pool (and allocator if
>> provided at creation time).
> 
> If *not* provided at creation time.  Why not use the global allocator
> in that case?  If the user really needs a separate allocator, it's two
> extra lines.  The allocator declaration and a call to
> apr_allocator_create, which makes it explicit.
>

Again, the global allocator might get destroyed before the
child pool since for it the owner is global pool.

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).

> 
>> This breaks the single root pool presumption, so the API has to be used
>> only in well defined environments where for each create_core_ex the
>> corresponding destroy will be always called.
> 
> The thing that throws me is the choice of naming.  'orphaned' and
> 'unmanaged', would have been more descriptive than 'core'.
>

Agreed, the core is not very well chosen name.
For trunk it should be easy, but will there be any problems
if renamed in 1.3 as well?

And of course, I'll make some capital letter sentences :)


Regards
-- 
^(TM)

Mime
View raw message