apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Making apr_pools 'standalone'
Date Thu, 10 May 2007 17:55:03 GMT

The current pool logic always assure the
pool will be destroyed when it's parent is destroyed
(up to the global_pool singleton), and that's great, but ...

That presumption makes APR behaving badly in
threaded environment applications with its own memory
management because each time the apr_pool is created
there is mutex lock.

I have a simple patch, and I would like the opinion from
someone that knows that area better then me.

How the patch works.

A typical scenario in 'known' memory management model is
as follows

1. pool = apr_pool_create
2. do something
3. apr_pool_destroy(pool)

This can be even extended by using allocator

1. allocator = apr_allocator_create
2. pool = apr_pool_create_ex(allocator)
3. apr_allocator_owner set(allocator, pool)
4. do something
5. apr_pool_destroy(pool)

Now, the later works fine, but it still inserts
the created pool in the parent/global pool chain
and that causes mutex lock/unlock in steps 2 and 5
with unnecessary linked list insert/remove.

With the patch the second scenario can be extended

1. allocator = apr_allocator_create
2. apr_allocator_owner_set(allocator, NULL)
3. pool = apr_pool_create_ex(allocator)
4. apr_allocator_owner set(allocator, pool)
5. do something
6. apr_pool_destroy(pool)

And the resulting pool will be standalone, and there
will be no mutex lock/unlock.

Of course there is potential memory leak in that case,
but like said the original presumption is that APR like that
is used in environments where there is already a known
memory manager, like Java etc...

The patch itself to my knowledge doesn't break
any existing implementation, and is backward compatible
because the APR versions that do not contain a patch
will simply put the new pool in the parents pool chain
and on explicit pool destroy remove it.
Of course it is backportable because it doesn't
introduce neither a new parameters nor new functions.

However it always set the global_pool as an allocator
owner, but the proper usage is to use the
apr_allocator_owner_set anyhow.

Sorry, for the long email, but I tried to be as concise
as I could :)


View raw message