On Wed, Feb 17, 2010 at 12:49 AM, Sam Carleton <[email protected]> wrote: > I am in agreement with mcqueenorama. I have not done a ton of module > programming, but what I have done is HEAVILY used by my app and core to the > whole thing. My best advise is don't use the pools other then the request > pool unless you REALLY need to, even when the module is initializing there > is a temp pool which Apache clears after initialization.
Thank you. Yes, I really need to use pools that live longer than request and sometimes I make mistakes which are causing leaks. Using --enable-pool-debug=all is probably best advice by now. I will try that shortly. > I did run into a memory leak once that I found by simply checking all the > pool usages, it turned out I was using a server pool rather then a request > pool. Something that automatizes that checking is what I am looking for :-) > I NEVER use anything other then a pool for memory allocation. The only > exception is 3rd party lib's that allocate memory, such as my usage of > SQLite, which I am sure allocates lots of memory, but I rely on it to clean > up that memory, assuming I manage the resource correctly. To date, all runs > well! I am using such libraries too. libmemcached for example. Registering free() function to exec when some pool will be cleaned is very useful apr lib feature. -- Marko Kevac Sent from Moscow, Mow, Russia
