Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: Possible race condition in pools WAS: RE: Thoughts on locks
From: Ian Holsman <ianh@cnet.com>
To: Justin Erenkrantz <jerenkrantz@ebuilt.com>
Cc: Brian Pane <bpane@pacbell.net>, dev@apr.apache.org
In-Reply-To: <20010627223224.K26239@ebuilt.com>
References: <Pine.LNX.4.30.0106270816200.21935-100000@koj.rkbloom.net>
	<3B3A9A81.2040306@pacbell.net>  <20010627223224.K26239@ebuilt.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 28 Jun 2001 08:28:41 -0700
Message-Id: <993742121.26438.0.camel@griffon.cnet.com>
Mime-Version: 1.0

On 27 Jun 2001 22:32:24 -0700, Justin Erenkrantz wrote:
> On Wed, Jun 27, 2001 at 07:46:25PM -0700, Brian Pane wrote:
> > Assuming that fixing it with code would mean adding a lock around
> > that block in apr_palloc, I submit that fixing it with documentation
> > is the better option.  Given how much slower the threaded MPM is
> > than the prefork one right now, I think that adding more mutex overhead
> > would be bad. :-(
> 
> Well, as Aaron has constantly told me, "It isn't the mutex that is slow, 
> it is the code between the acquiring and the releasing of the mutex."  
> IMHO, he's right on the money in this case.  (It's the fact that we're 
> doing this locking inside of the mainline pool allocation code...)  From 
> everything I can tell, this model makes more sense for prefork than it
> does for threaded MPMs.  I can't fathom how it makes sense to do this
> with a threaded APR.
> 
> I added my $.02 into the APR STATUS file.  I can't stand it anymore.  
> Unless someone can convince me otherwise (I'm fully open to ideas), I 
> plan on tossing this pool code and replacing it with SMS.  The caveat 
> being once I know SMS works to my satisfaction.  =)  At this point,
> I have no clue how I'm proceeding to actually implement this, but I 
> do know that I plan on doing something.  The STATUS file has more
> clues about my current thoughts.
> 
> I *should* be available to start working on this next week unless I
> receive any objections.  (We're wrapping up a project here - I hope
> to roll off of it this week...)  -- justin

I'm in the middle of writing a pool-tester
which can take a file and pool allocation commands
(alloc/create/destroy/etc)
and replay them.
combine this with some threads, and a capture tool in the current pool
code and we should be able to test different pooling algorithms easily.

(should be done today)

..Ian