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. Am I missing something obvious ?
signature.asc
Description: OpenPGP digital signature
