apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: API to prevent further allocations from a pool?
Date Fri, 08 Sep 2006 08:14:30 GMT
On Thu, Sep 07, 2006 at 12:39:57PM -0400, Jeff Trawick wrote:
> 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 ;)

*You* can still run the suspect modules through a stress test on a 
debug-enabled server build, right?

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

Simply that this is a debugging aid and as such it seems sufficient to 
add it to the debug code and leave the production code alone.

But to make a strong API guarantee I think this would need to use atomic 
operations anyway, which means the performance hit (mutexes on some 
platforms) would indeed be way too high for the pool allocation critical 
path, I think.



View raw message