apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Freeman \(saurik\)" <sau...@saurik.com>
Subject any documentation on the point of having pools?
Date Thu, 28 Mar 2002 21:31:20 GMT
Is there any documentation anywhere that describes "why you would want to
use pools"?  I've been using APR for over a year now in virtually all of my
projects, and I _still_ don't get what the advantage of this pool management
that's strewn all over my programs is.  I finally got fed up, wrote a C++
class named "pool" (with an autocast operator for getting an apr_pool_t *
and a destructor that destroys the pool), and have an instance of it in
_every APR related object_ so I have something I can pass to the APR
functions when they scream out for their precious pools :-P.  I pray at
nights that I'm not using an insane amount of working set by doing this,
hehe.

If I want to use sockets, I have to deal with pools (even for entirely
transient memory allocations).  If I want to spawn a thread, I need pools
(and I'm really getting worried that I might not be understanding this
"sup-pool" concept and might be causing weird thread contention on my
memory... I try to build a new pool every time I allocate even a byte of
memory, so hopefully this isn't a problem).  I've got code that loads DLLs
and shared objects, and apparently... apparently I need a pool for that too
(and I'm terrified that if I clear that pool my DLL might get unloaded from
memory).

My confusion is likely coming from the fact that I use C++, so please bear
with me.  Is this a speed optimization?  Do pools allocate memory _faster_
(such as in some sequential memory region somewhere) than the OS's virtual
memory manager can?  Are they there to try to make memory management easier?
If the latter, is there somewhere I can go to find out how and when it
finally gets easier?

Sincerely,
Jay Freeman (saurik)
saurik@saurik.com


Mime
View raw message