On 4/11/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Jeff Trawick wrote: > > On 4/10/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > > > >>This pool is or is not created in the parent? If its the parent it's > >>gotta be proc mutexed even if using prefork. > > > > It is created in the parent and used only during request processing. > > Why does it need to be proc mutexed? Each process has its own copy. > > There is no shared memory involved. > > Ah... of course. The pages are copy-on-write. > > So there is no proc mutexing issue :) > > >>If it's process-local, then please don't depend on APR_THREADED, please > >>please please poll the MPM to determine if the mpm has_threads? It's a > >>huge waste for prefork users with a shared (threaded) apr :( > > > > That minor performance improvement for some (lots of?) prefork users > > should first be addressed in trunk, and implementation/backport of > > that should not hold up this critical bug fix. > > But the code is there, and what we are using in mod_ssl and others. Please > don't inject a regression where we already cleaned these up once before :(
Nobody ever "cleaned up" ldap. Now there are perhaps 9 occurrences of a pattern to replace instead of 8. (didn't count exactly) It is a HUGE stretch to call that a regression, since anybody that wants to "fix" it has to search for the pattern anyway. People have had several years to get around to that performance improvement and nobody cared so far.
