apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Possible race condition in pools WAS: RE: Thoughts on locks
Date Thu, 28 Jun 2001 05:32:24 GMT
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


Mime
View raw message