apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Inf. on pool...
Date Sun, 16 Jan 2005 15:24:22 GMT
Eufordia wrote:

> Is there a good soul that could explain me what is exactly a "pool"?

Traditional ways of asking for memory involves:

- asking for some memory
- giving it back when you are finished

The trouble is with the second part - how are you sure you gave all the 
memory back when you were finished with it? Usually no, and thus we have 
memory leaks.

What if you could do this:

- ask for some memory
- ask for some more memory
- ask for even more memory
- ok I'm finished - clean up all the above in one go

If you could, you could free everything up in one go, and be sure you 
didn't miss anything, and be sure again that you're not leaking memory.

APR allows you to do this by using "pools" of memory. Depending on the 
task you are trying to do, you do this:

- create a pool
- allocate memory from the pool
- allocate more memory from the pool
- and more and more
- ok, I'm done - clean up the entire pool in one go

To make it more fun, when you create a pool, you can create it as a 
"child" of another pool. For example, you might have a "global" pool 
that all your memory is taken from. Then you create a "subtask" pool as 
a child of the "global" pool to perform some task. When you're finished 
doing the subtask, you clean up the subtask pool. If an error happens 
and you have to exit completely, if you clean up the global pool, the 
subtask pool will be cleaned up too.

The fun continues: You can get the pool cleanup to clean up more than 
just memory. If you open a file, register a function to close the file 
with the pool. When you clean up the pool, the file will be closed, and 
you don't leak file descriptors.

APR pools make it easy and clean for code to make sure it cleans up 
after itself preventing leaks.

Hope this gives you a direction to start in.


View raw message