APR::Pool 2.0.3

APR::Pool is a Perl API for APR pools.

Synopsis

use APR::Pool ();

my $sp = $r->pool->new;
my $sp2 = APR::Pool->new;

# $sp3 is a subpool of $sp,
# which in turn is a subpool of $r->pool
$sp3 = $sp->new;
print '$r->pool is an ancestor of $sp3'
if $r->pool->is_ancestor($sp3);
# but sp2 is not a sub-pool of $r->pool
print '$r->pool is not an ancestor of $sp2'
unless $r->pool->is_ancestor($sp2);

# $sp4 and $sp are the same pool (though you can't
# compare the handle as variables)
my $sp4 = $sp3->parent_get;


# register a dummy cleanup function
# that just prints the passed args
$sp->cleanup_register(sub { print @{ $_[0] || [] } }, [1..3]);

# tag the pool
$sp->tag("My very best pool");

# clear the pool
$sp->clear();

# destroy sub pool
$sp2->destroy;

APR::Pool provides an access to APR pools, which are used for an easy memory management.

Different pools have different life scopes and therefore one doesn't need to free allocated memory explicitly, but instead it's done when the pool's life is getting to an end. For example a request pool is created at the beginning of a request and destroyed at the end of it, and all the memory allocated during the request processing using the request pool is freed at once at the end of the request.

Most of the time you will just pass various pool objects to the methods that require them. And you must understand the scoping of the pools, since if you pass a long lived server pool to a method that needs the memory only for a short scoped request, you are going to leak memory. A request pool should be used in such a case. And vice versa, if you need to allocate some memory for a scope longer than a single request, then a request pool is inappropriate, since when the request will be over, the memory will be freed and bad things may happen.

If you need to create a new pool, you can always do that via the new() method.

Product's homepage

Requirements:

· Perl