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) [EMAIL PROTECTED]
