Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:


In any case I'm pretty sure that you've already thought about a
great solution and you have an almost working patch. Don't say that
you don't have one :)


The solution IMO, is to do what Apache::Request::Table::new does:
keep a reference to the APR::Pool argument in the new APR::Table
object's magic list. That ensures the pool will last as long as the table SV does.


I'm pretty sure I proposed this idea before, but it met with some resistance. IIRC folks here considered this a bug in
APR::Pool, but I say the problem here is in APR::Table. I'd
like to see us settle on a course of action first.

Yeah, I saw your changes to Apache::Request::Table and was planning to look at that. The problem with your solution is that it'll require getting this code into any function that gets the pool object. And there are quite a few of those. That's why we need to look first at the possibility to have the pool know when it's safe to go away.


I haven't yet studied in detail the latest reincarnation of APR::Pool, but the previous implementation was refcounting every time a pool object was asked for. And it won't destroy till all the users cease to exist. Granted, this worked (sort of) for pool objects, but it didn't solve the problem we are discussing now. So I wonder if it's possible to somehow store the users of the pool (svs) (and refcount them) in the pool and not the other way around. It's probably not quite possible, w/o invoking some code every time a pool is a passed to method/func, which will essentially do the same as your code in Apache::Request::Table::new.

--
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to