apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject Re: pool debug question.
Date Thu, 05 Sep 2002 15:26:14 GMT

> > apr_initialize calls apr_pool_initialize which creates a
> > global allocator which is used for all pools (unless overridden).
> > The global allocator is protected by a mutex, which is allocated
> > out of the global pool (also created by apr_pool_initialize).
> > 
> > apr_terminate calls apr_pool_terminate which in turn destroys
> > the global pool.  The global pool is the owner of the global
> > allocator and thus destroys the global allocator after its own
> > destruction.  The global pool cleanup _should_ already have
> > taken care of the destruction of the mutex and the resetting of
> > the mutex field of the global allocator.
> > 
> > 
> >>the test program is creating and destroying thousands of pools
> >>but is not messing at all with allocators
> > 
> > 
> > Are you sure you are not calling apr_terminate before all threads
> > have finished?  If you are we have a nice thing to debug :(
> > 
> This could be the problem, as the program is creating/exiting threads
> several times. but I am 99.9% sure that they are all dead before I 
> terminate (this is what msvc's debugger shows me)
> The code is on http://webperf.org/a2/prob/
> it's the start of a dynamically sizing mpm (it spawns more threads
> when the queue is getting bigger, longer term it will base it's decision 
> on response times)

You realize that we already have an MPM that increases the number of
threads based on queuse, correct?  The Perchild MPM comes directly from
Dexter, which is static processes/dynamic threads.  Yes, perchild has more
options, because it change change the user/group of each child, but if you
don't specify any user/group directives, it works just like what you are


Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610

View raw message