apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: API to prevent further allocations from a pool?
Date Thu, 07 Sep 2006 16:39:57 GMT
On 9/7/06, Joe Orton <jorton@redhat.com> wrote:
> On Thu, Sep 07, 2006 at 11:22:35AM -0400, Jeff Trawick wrote:
> > 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.)
> If done "#if APR_POOL_DEBUG", I think this would be useful.

People who don't know pools don't know APR_POOL_DEBUG either ;)

Is it just a performance concern which leads you to APR_POOL_DEBUG?

>                                      Would need
> to be clear about whether other ways of manipulating the pool (userdata,
> cleanups, clear, destroy?) are covered or really just apr_p*alloc.

Userdata and cleanups are allocations and pool-internal data structure
manipulations, so they'd have to be disallowed to allow locking to
guarantee for some application that use of a certain pool has no
thread-safety issues or no initialization vs. steady-state issues
(e.g., memory leak).

Clear and destroy likely already result in sufficient fireworks if
they are misused, so those aren't so important to disallow.

> > apr_pool_lock() - cause abort() on subsequent allocation request
> [un-implemented, un-documented apr_pool_lock() already in-tree!]


View raw message