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)
