On Thu, 4 Sep 2003, Chris Fallin wrote: > In order to prevent leaks each thread gets its own subpool, which it > frees on exit. However, I see in apr_thread_create (at > threadproc/unix/thread.c:160) that a subpool is allocated from the pool > passed to the function. This pool is the one that is destroyed in > apr_thread_exit at line 192. Thus, the pool passed in to > apr_thread_create is never freed unless done manually after > apr_thread_exit destroys the child pool, which is hard because it exits > the thread.
As for whether what you described is a bug or not, I'm not sure, but you might be able to get around it one way or the other by calling apr_allocator_create() yourself, then apr_pool_create_ex() -- that way your subpool has its own block of memory that you can destroy after the thread is done, rather than having it go back into the parent pool's allocator. (apr_allocator_max_free_set() might also be useful.) Hope this helps. No doubt one of the pool wizards will jump in with other suggestions... --Cliff
