On Thursday 07 September 2006 16:22, Jeff Trawick wrote: > Occasionally I see problems caused by Apache modules using per-process > pools on a request processing thread. Aside from the thread-safety > issues, they had no business doing that anyway. > > It would be cool for the MPM to be able to lock the pool once it is > ready to start serving requests so that if any errant module tries to > use pconf, pchild, etc. it will crash immediately instead of > introducing memory corruption under load. (Even if the module author > is "clever" and uses a mutex around the pool use, that assumes she is > the only person in the world to have that idea.)
There are cases where using pchild can be the lesser evil. Example: managing a persistent resource that supports infrequent delete or timeout. If a module creates a private pool at child_init, that'll make a slow leak. A workaround hack for that is to add a timer or counter, and periodically tear down the module's pool and renew it by allocating a new one from pchild. > Some other multi-threaded APR apps probably have the same concern, > especially if they allow plug-ins from third parties to be loaded. > > apr_pool_lock() - cause abort() on subsequent allocation request > apr_pool_unlock() - allow it to be used again Another thought (separate from, not instead of, yours): thread-safe pools? A pool with a thread mutex attached, as a builtin option? That would be ideal for modules doing the kind of thing I suggested. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.prenhallprofessional.com/title/0132409674
