Mladen Turk
Tue, 08 Jul 2008 05:03:54 -0700
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)