Philippe M. Chiasson wrote:
My plan was to polish things this week (add registryprefork and stuff), get the 2.0.0-RC on friday and release 2.0.0 on monday if everything is cool.
I'd probably add slightly more time between the RC and the release, especially if people only have the week-end to test it. I'd rather wait until tuesday or even wednesday, giving time to the folks who stay offline during the week-ends.
sure, it's a minor matter.
I would like to sort out the Apache::Reload segv problem before 2.0.0, though.
It has been on the todo list for quite a few months. We can't wait forever. I suggest that the old pure perl code will be committed instead of the slightly limping new C code.
Yes, like we discussed last time. I am working on a patch to bring back the old pure-perl (warning cursed) module unloading code, and suggest putting it into ModPerl::Util::unload_package_pp and keep the XS implementation as ModPerl::Util::unload_package_xs. Then switch Apache::Reload and friends back to using the pure-perl version until the XS one can be made as robust.
Good.
I have finally put my finger on the problem though. In modperl_mgv, we cache GV* to the various stashes leading to a package. That optimization assumes that stashes will never dissapear. The new unload code does, thus, SEGV.
The problem here, is that even knowing this, there isn't much that can be done while keeping the current XS unloading approach. Unless there is a way to find the various modperl_mgv's pointing to our old stashes and invalidate them somehow. From my understanding of that piece of code, it's not feasible.
You mean you can't map the gvs being unloaded to the modperl_mgv entries?
The modperl_mgv code itself can't verify the validity of it's cached GV* either, so I am not sure if this can be fixed without changing the way I implemented the XS unloading code. Deleting the stashes directly is what avoided all the mandatory warnings and all.
When the stash is deleted you know what namespaces are removed, so it should be possible to figure out what CODE entries are removed. Once you have those you can find the modperl_mgv entry and invalidate it. No?
-- __________________________________________________________________ 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]
