apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject apr pool arch shortcoming: lack of pool validation API
Date Sun, 25 Jan 2004 00:57:44 GMT
Recently I've learned about an important feature lacking in apr pool 
architecture - it's the ability to verify that the pool is still the same pool 
and wasn't destroyed or replaced by another pool.

If I create a new pool and stash a pointer to it in 2 variables, it's quite 
possible that one variable will call apr_pool_destroy, the other won't know 
that the pool has been destroyed. As long as a new pool wasn't allocated, the 
other accessor will still be able to use the ghost pool, as if it was there 
for real. The moment a new pool will get allocated at the same memory address, 
the ghost accessor will wreck havoc operating on the pool that doesn't belong 
to it.

I think what's needed is to store a unique signature every time a new pool is 
created somewhere in the pool and have the API to get and verify that 
signature. If this functionality was in place, I could stash that signature 
along with the apr_pool_t pointer in my variables and before doing something I 
could verify whether I'm still talking to the correct pool.

The situation when you have a ghost pointer is very real. Since the parent 
pool destroys all its child pools, the variables referencing these child pools 
may not know that the parent pool has been destroyed and still try to use the 
ghost pools.


Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

View raw message