Not to be contrary, but this can be easily resolved, by passing in a simple flag when creating a pool. That flag tells us whether or not we should lock when using the pool.
Ryan On 28 Jun 2001 [EMAIL PROTECTED] wrote: > jerenkrantz 01/06/27 22:14:30 > > Modified: . STATUS > Log: > "I'm mad as hell and I'm not going to take it anymore." > > The threading and pool stuff just don't mix. If we ever plan on > getting Apache 2.0 to work WELL with threading, this needs to be > addressed. The most likely way to address this is via SMS. I > need to play more with SMS to determine how close this is to being > ready for prime-time. I may need to clean up SMS first. > > Expect this to be my focus once I get freed up at my day job. > (Hopefully, end of this week...) > > Revision Changes Path > 1.47 +18 -1 apr/STATUS > > Index: STATUS > =================================================================== > RCS file: /home/cvs/apr/STATUS,v > retrieving revision 1.46 > retrieving revision 1.47 > diff -u -r1.46 -r1.47 > --- STATUS 2001/06/28 04:03:19 1.46 > +++ STATUS 2001/06/28 05:14:28 1.47 > @@ -1,5 +1,5 @@ > APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: > -*-text-*- > -Last modified at [$Date: 2001/06/28 04:03:19 $] > +Last modified at [$Date: 2001/06/28 05:14:28 $] > > Release: > > @@ -146,6 +146,23 @@ > - add to the default build as currently it's omitted. Also need to > add testmem to the test build at that point. > - add more detailed tests to testmem.c > + > + * In line with the new SMS code is the fact that threading and pools > + just are not working together well. This is due to the fact that > + the pool code has one global mutex (alloc_mutex) and one freelist > + (block_freelist) for all pools to share. This means that only > + one worker can be allocating memory at any given time. This is > + probably the reason why Apache 2.0 is faster with prefork MPM > + (thread-disabled APR) than threaded MPM. The solution to this > + is most likely to incorporate a rework of the pools to use the new > + SMS code and allow certain pools (i.e. request pools in httpd-2.0) > + to have an option for no locking (as they can't have contention > + by definition). This would mean that the mutex and freelist > + must be moved inside of apr_pool_t. Therefore, this is the > + jumping-off point into SMS. Short-term, it is *possible* that > + ALLOC_USE_MALLOC would be faster than the current pool code for > + a threaded APR (but, I'm not sure). > + Status: Justin volunteers > > Documentation that needs writing: > > > > > > _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
