perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philippe M. Chiasson" <go...@ectoplasm.org>
Subject [PMX:####] Re: [VOTE] mp2.0.0 next week?
Date Tue, 10 May 2005 05:39:49 GMT
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> 
>> Stas Bekman wrote:
>>
>>> As RC6 release didn't reveal any significant problems (a few minor bugs
>>> that are either already fixed or will be shortly), I propose that it's
>>> time to get 2.0.0 out. I was thinking to work next week to polish things
>>> and improve docs and get 2.0.0 towards the end of the week/or the
>>> beginning of the following week.
>>
>> Sounds like a reasonable path to me. If necessary, I can take up the
>> release-manager's hat once more if needed, since I have the time to.
> 
> Cool, go for it.
> 
> 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.

> Remember that 2.0.0 is about API freeze.

Yes, absolutely.

> We will certainly have
> problems to deal with when people will actually start using 2.0.0. But
> before we release 2.0.0 they won't start using it.

And it's the main reason I think that getting 2.0.0 out will probably
cause more review and bug reports, leading to much better 2.0.n releases
shortly after.

After all, being a .0.0 release, it's understandable if it's got a few little
bugs ;-)

> So let's plan for the 2.0.0 release candidate (not RC7) this friday.
> 
>> 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.

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.

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.

--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

Mime
View raw message