Quoting Ioan Popescu <[EMAIL PROTECTED]>:
If they're here to stay, could someone tell me what advantages there are to
using them instead of malloc()/free()? Regardless of portability.
- well suited for request/response situations (i.e. limited object lifetime)
- faster than many malloc() implementations, especially on pool reuse
- can attach generic cleanup functions to them, with same lifetime
- one cleanup does it all, instead of many free()'s
- can have subpools for allocating memory in a branch of code that may
end up in an error, in which case the subpool can be easily dumped
without affecting the parent pool, therefore reducing the memory
pressure
This is a big problem when you don't know the lifetime of
objects and likely end up using some common pool for them with a very long
lifetime. Any solutions for this?
Apache has a notion of maximum number of requests a child process will
handle. This can help with memory leaks, as processes simply get
recycled after a while, therefore freeing any "long lifetime" memory
that may have leaked in the child during its service period. Not
suitable for all apps, but may help in some situations.
--
Bojan
