apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: API to prevent further allocations from a pool?
Date Thu, 07 Sep 2006 16:03:06 GMT
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

Mime
View raw message