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.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
