Mladen Turk
Sun, 06 Jul 2008 23:08:35 -0700
Sander Striker wrote:
On Wed, Apr 16, 2008 at 3:52 PM, Joe Orton <[EMAIL PROTECTED]> wrote:On Tue, Apr 15, 2008 at 06:48:49AM +0200, Mladen Turk wrote:Joe Orton wrote:On Sat, Apr 12, 2008 at 08:42:59AM -0000, Mladen Turk wrote:Author: mturk Date: Sat Apr 12 01:42:51 2008 New Revision: 647394 URL: http://svn.apache.org/viewvc?rev=647394&view=rev Log: Introduce apr_pool_sys_allocator_setMladen - I think you posted that response to this thread as well as the other; this thread was about r647384 (apr_pool_create_core_ex) not r647394 (apr_pool_sys_allocator_set).I checked on the archives, as I stumbled over the code and wondered what the heck it was for. I don't seem to find a response as to what this functionality is actually needed for. In case I missed it, could you point me to it? If I didn't miss it, because there is nothing there, could you please follow up to Joe's earlier question?
Sorry for the late answer. I was on the vacation ;) I think I already explained the purpose and usage of create_core_ex. Unlike traditional pool it creates standalone pool (and allocator if provided at creation time). The usage addresses two main common concepts: 1. Temporary memory pools that are commonly used inside loops and are used as create/alloc*n/destroy Since create_core_ex doesn't lock the parent (or global) pool during create/destroy this is performance upgrade. 2. Using pools with high level languages like Java that have strict garbage collection. APR Objects in that case can be directly bound to the java object without the need to sync the GC with the pool maintenance. Since those languages ensure that the object destroy method will be called, but in random order there is no need to create any back reference to parent pool. Just to give you an overview of the problems with that in heavily multithreaded environment like JVM where GC and occur in parallel, are the long JNI calls in which case the apr_terminate needs to be protected by the sync method so that it gets called *only* when all functions exits. In any other case we might end up with zombie memory (child pool) in the middle of the function call. We have that problem in Tomcat Native, so a simple high CPU usage can lead to a JVM core during connector shutdown/restart. JVM can decide to cleanup the our apr socket object at some later time when the parent was already destroyed. To solve this issue we would need to create internal tree that would map apr_pool parent/child dependency1:1, protect the access and maintain it, as well as having an atomic counter of number of JNI functions currently executing.
With detached pools we don't need that and the memory will still be released by calling pool_destroy in objects finalize method. 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. Long one, I know :) Regards -- ^(TM)