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_set
Mladen - 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 dependency
1: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)
