apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: Possible race condition in pools WAS: RE: Thoughts on locks
Date Thu, 28 Jun 2001 15:28:41 GMT
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
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)


View raw message