perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [PMX:####] Re: [VOTE] mp2.0.0 next week?
Date Wed, 11 May 2005 17:43:41 GMT
Philippe M. Chiasson wrote:
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message