Stas Bekman wrote:
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.
Yup, but let's not forget it ;-)
:)
[..]
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?
Exactly!
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?
Yes, the package/namespace being removed is known. Then simpler to go the other way around and try and find and modperl_mgv entries with a cv into that package (should be only 1 or a few). Then invalidate, yes.
The problem I see is the lookup. How do you find all modperl_mgv * for "Some::NameSpace"? AFAIK, they are located in modperl_handler_t's and these are buried deep into configuration structures, no ?
I can't think of an easy way to implement a lookup like this, short of having a global knoledge of all modperl_(handle|mgv)_t created.
even if we had it it'd be a very slow operation to find those out.
Am I missing something obvious ?
I don't think so. Though I'd check why it does work when doing it in perl (the original way). After all that original implementation doesn't have a problem with mgvs. May be because the reloaded code gets the same addresses and in your implementation it is not?
May be there should be a mechanism that will not use mgv's in which case the xs code should be used. if the mgvs are in use the perl code is the way to go. since those who need this feature don't care about the performance this should work.
-- __________________________________________________________________ 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]
