apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: API to prevent further allocations from a pool?
Date Thu, 07 Sep 2006 16:33:13 GMT
Joe Orton 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.  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.

Well... some additional pools could (at some significant cost) be stressed
out under APR_POOL_DEBUG, frequently unlocking and relocking them.

But as far as pconf which should be a static for the lifetime of the server
(and therefore not frequently unlocked/relocked) the code makes sense in
production, as well.

apr_pool_[un]lock absolutely should not be conditioned on APR_POOL_DEBUG.
Leave it to the user to use them explicitly or conditionally, as best
suits their purposes.


Mime
View raw message