perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [PMX:####] Re: [VOTE] mp2.0.0 next week?
Date Tue, 10 May 2005 18:51:04 GMT
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
> 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,
>>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.


> 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     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message