apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <minf...@sharp.fm>
Subject Re: APR Pools
Date Wed, 01 Nov 2006 16:56:21 GMT
On Wed, November 1, 2006 6:12 pm, Ioan Popescu wrote:

> If they're here to stay, could someone tell me what advantages there are
> to
> using them instead of malloc()/free()? Regardless of portability.

In typical code, there are many possible paths, including possible failure
paths to account for. Once your code is done, you need to free memory
you've malloc'ed. Add a few more esoteric code paths, like handling
abort-on-timeout, and it gets even more complex. Did we free all the
memory we malloc'ed?

Sometimes it can be just plain difficult to keep track of your own memory
usage. When your code ends, you want a way to say "just clean up, dammnit"
and be done with it.

Pools give you this.

Right at the beginning, you define a pool. You attempt your task,
following one of many possible code paths, allocating RAM as and when you
need it. Maybe your task succeeds, maybe it fails with an error, doesn't
matter - right at the end of the task, you destroy your pool, and you have
peace of mind that all the memory you allocated is gone.

Of course, this isn't a solution for every problem. If your task involves
the allocating of excessive RAM, you effectively have a leak inside your
task. You might want to delete something just malloc'ed right away, and
not wait right till the end of the task.

One solution to this is create a subpool off a main pool. Subpools are
independent pools that can be created and destroyed at will, but they have
the property of being destroyed when the pool the subpool was created from
gets destroyed. Create the subpool, allocate the memory, destroy the
subpool, carry on going. Some argue that the above solution, while it
works, isn't that efficient, and it may not be efficient enough for your


View raw message