You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2005/05/08 06:49:06 UTC
[VOTE] mp2.0.0 next week?
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.
Besides being long overdue, my personal reason for getting it out now, is
that I'm finishing my contract with TM shortly and I'll be on the road
having vacation and teaching mp2 during most of the summer, so I won't be
able to deal with any post-release problems if it's released later. Of
course there are others who can do that, but it seems that nobody has time
nowadays.
So please vote. Thanks.
+1
--
__________________________________________________________________
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
Re: [VOTE] mp2.0.0 next week?
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> So please vote. Thanks.
>
> +1
+1 for the timimg, but I still haven't done a serious look at the
mp1+mp2 parallel installation issue. Has anyone actually run the
Apache-Test suites for mp$X when mp$Y is already installed?
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
[PMX:####] Re: [VOTE] mp2.0.0 next week?
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
>> Stas Bekman wrote:
>>
>>> Philippe M. Chiasson wrote:
>>>
>>>>[...]
>>
>> 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.
Yes indeed it would be.
>> 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?
That's because the Perl implementation deleted every single stash _entry_
one by one (CODE, SV, AV, HV, etc) directly, and left the stash itself
alone. This works, but it's slow and causes the annying warnings. The XS
implementation, by wiping entire stashes goes much quicker and avoids these
warnings (and a few other goodies).
> 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.
Yup, I am thinking:
ModPerl::Util::unload_package_xs()
ModPerl::Util::unload_package_pp()
and
ModPerl::Util::unload_package() as the user-visible, recommended one
that just dispatches to _pp for now, until the xs implementation can
be fixed (if it can)
Re: [PMX:####] Re: [VOTE] mp2.0.0 next week?
Posted by Stas Bekman <st...@stason.org>.
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
[PMX:####] Re: [VOTE] mp2.0.0 next week?
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
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 ?
Re: [PMX:####] Re: [VOTE] mp2.0.0 next week?
Posted by Stas Bekman <st...@stason.org>.
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.
>>>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.
Good.
> 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
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
[PMX:####] Re: [VOTE] mp2.0.0 next week?
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
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
Re: [PMX:####] Re: [VOTE] mp2.0.0 next week?
Posted by Stas Bekman <st...@stason.org>.
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. Remember that 2.0.0 is about API freeze. 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.
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.
>>Besides being long overdue, my personal reason for getting it out now,
>>is that I'm finishing my contract with TM shortly and I'll be on the
>>road having vacation and teaching mp2 during most of the summer, so I
>>won't be able to deal with any post-release problems if it's released
>>later. Of course there are others who can do that, but it seems that
>>nobody has time nowadays.
>
>
> Still, we've been on the 2.0 path long enough IMO. There will still be
> problems and bugs, but we've always done a good job at hunting these down.
right.
>>So please vote. Thanks.
>
>
> I am definitely +1 for a 2.0.0 release in the near future.
The near future is here: this friday 2.0.0 rc and mon-tue 2.0.0-final
--
__________________________________________________________________
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
[PMX:####] Re: [VOTE] mp2.0.0 next week?
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
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.
I would like to sort out the Apache::Reload segv problem before 2.0.0,
though.
> Besides being long overdue, my personal reason for getting it out now,
> is that I'm finishing my contract with TM shortly and I'll be on the
> road having vacation and teaching mp2 during most of the summer, so I
> won't be able to deal with any post-release problems if it's released
> later. Of course there are others who can do that, but it seems that
> nobody has time nowadays.
Still, we've been on the 2.0 path long enough IMO. There will still be
problems and bugs, but we've always done a good job at hunting these down.
> So please vote. Thanks.
I am definitely +1 for a 2.0.0 release in the near future.
--------------------------------------------------------------------------------
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
Re: [VOTE] mp2.0.0 next week?
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 7 May 2005, 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.
>
> Besides being long overdue, my personal reason for getting
> it out now, is that I'm finishing my contract with TM
> shortly and I'll be on the road having vacation and
> teaching mp2 during most of the summer, so I won't be able
> to deal with any post-release problems if it's released
> later. Of course there are others who can do that, but it
> seems that nobody has time nowadays.
>
> So please vote. Thanks.
>
> +1
+1
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [VOTE] mp2.0.0 next week?
Posted by Perrin Harkins <pe...@elem.com>.
On Sat, 2005-05-07 at 21:49 -0700, 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.
>
> Besides being long overdue, my personal reason for getting it out now, is
> that I'm finishing my contract with TM shortly and I'll be on the road
> having vacation and teaching mp2 during most of the summer, so I won't be
> able to deal with any post-release problems if it's released later. Of
> course there are others who can do that, but it seems that nobody has time
> nowadays.
>
> So please vote. Thanks.
+1
I will try to have a press release ready to go by the end of this
weekend, although we will probably not want to send it out on the actual
day of release.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [VOTE] mp2.0.0 next week?
Posted by Stas Bekman <st...@stason.org>.
OK, as we have more than 3 +1s, Philippe is going to post a 2.0.0 snapshot
to the list and around next tuesday if no major regression issues are
discovered we should get 2.0.0 out.
--
__________________________________________________________________
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