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
