You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by David Radunz <da...@staff.netspace.net.au> on 2004/10/04 08:15:44 UTC
Apache::PerlRun - Constant subroutine redefined
Hi All,
I have looked high and low to work out how to avoid the 'Constant
subroutine redefined' warnings in the error log, followed by the
'Prototype missmatch:' error upon subsequent hits to the apache child
process - but, I have not been able to find an easy solution. The
warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
which attempts to reset/nullify everything - including constants. When a
constant is redefined it causes a warning in the error_log, and when the
constant gets reset upon the next run of the script the prototype doesnt
match as its reset incorrectly.
I found a message from Stass Beckman saying that you could use a
$SIG{__WARN__} handler to filter the warnings. This works for the
'Constant subroutine redefined' warnings, but not the 'Prototype
missmatch:' warnings (even thou I modified it to take both into
account), no matter where i add the $SIG{__WARN__} handler it never gets
called in the case of 'Prototype missmatch:' - not even when its defined
in the startup.pl
So I decided to work out a way to modify Apache::PerlRun so that it
did not redefine constants. There is no need to nullify constants as
they will not and CAN NOT change between child instances, and
documentation indicates that the 'Constant subroutine redefined' warning
means that the original value will be retained anyway (i.e. you cant
change a constants value).
Constants in perl are anonymous code references with a blank
prototype, that is how they are created within constant.pm here is a
snippet:
*{$fullname} = sub () { };
So if you had:
use constant TRUE => 1;
it would become:
*{$fullname} = sub () { 1 };
where $fullname was main::TRUE
When a subroutine is defined with a prototype of '()' and it returns a
constant result when compiled, it becomes a 'constant subroutine'.
Hence, constants are meerly constant subroutines.
So now for the changes I made to PerlRun.pm, below is the original
code:
if (defined &$fullname) {
no warnings;
local $^W = 0;
if (defined(my $p = prototype $fullname)) {
*{$fullname} = eval "sub ($p) {}";
}
else {
*{$fullname} = sub {};
}
undef &$fullname;
}
So, this code would reset every subroutine to a blank anonymous
subroutine, using the correct (current) prototype. And then undefine it.
My patch:
if (defined &$fullname) {
no warnings;
local $^W = 0;
if (defined(my $p = prototype $fullname)) {
# We DONT want to redefine constant subroutines (sub ())
if ($p) {
*{$fullname} = eval "sub ($p) {}";
undef &$fullname;
}
}
else {
*{$fullname} = sub {};
undef &$fullname;
}
}
This code will reset every subroutine that does not have an empty
prototype and then undef it. So basically the 'sub () {}' defined
subroutines are not reset (but sub {} and sub ($) {} are reset).
Now, im aware this is not an ideal solution due to the fact that any
subroutines declared in a script with a () prototype will not be reset.
But on the flip side of the coin all constants will be left intact and
any warnings in the error log avoided. My question is, what caveats
would there be in not resetting a subroutine? I have ran some tests to
see how subroutines setup in this way would work and the tests appear to
be good.
For example:
print STDERR 'time_constant = '. &time_constant(). "\n";
sub time_constant () {
time. ' '. $$;
}
running under 'httpd -X'
would produce a different time each request, and the same process id.
as did..
my $time_constant = sub () { time. ' '. $$ };
print STDERR 'var time_constant = '. &{$time_constant}. "\n";
Sorry this email is a tad long, but its quite complicated to explain.
Cheers,
--
David Radunz,
Developer / Programmer
Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz@staff.netspace.net.au
This email and any files transmitted with it are confidential and intended solely for the
use of the individual or entity to whom they are addressed. Please notify the sender
immediately by email if you have received this email by mistake and delete this email
from your system. Please note that any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of the organisation.
Finally, the recipient should check this email and any attachments for the presence of
viruses. The organisation accepts no liability for any damage caused by any virus
transmitted by this email.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::PerlRun - Constant subroutine redefined
Posted by David Radunz <da...@staff.netspace.net.au>.
Your quite right about constants in perl - they are a big hack. I could
have used the internals of constant.pm to determine for sure if
something was a constant (see: TECHNICAL NOTES documentation of the
constant man page). However, that doesnt work when using imported
(Exporter) constants because they arent setup using constant.pm, rather
pointers set to the reference of the parent package. So this is the only
way I can think of.
Thanks for your feedback
On Tue, 2004-10-05 at 03:29, Perrin Harkins wrote:
> On Mon, 2004-10-04 at 08:15, David Radunz wrote:
> > My patch:
>
> This looks like a good idea to me. I'd say we should put it in.
>
> > For example:
> >
> > print STDERR 'time_constant = '. &time_constant(). "\n";
> > sub time_constant () {
> > time. ' '. $$;
> > }
> >
> > running under 'httpd -X'
> >
> > would produce a different time each request, and the same process id.
>
> That's okay, since it would give a different time under CGI as well.
>
> My advice in general is that you just shouldn't use constants in Perl.
> The subroutine thing is kind of a hack, and the confusing problems with
> stringification are not worth the performance boost. Just use package
> variables instead. This doesn't work so well for running other people's
> code though.
>
> - Perrin
--
David Radunz,
Developer / Programmer
Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz@staff.netspace.net.au
This email and any files transmitted with it are confidential and intended solely for the
use of the individual or entity to whom they are addressed. Please notify the sender
immediately by email if you have received this email by mistake and delete this email
from your system. Please note that any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of the organisation.
Finally, the recipient should check this email and any attachments for the presence of
viruses. The organisation accepts no liability for any damage caused by any virus
transmitted by this email.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::PerlRun - Constant subroutine redefined
Posted by Perrin Harkins <pe...@elem.com>.
On Mon, 2004-10-04 at 08:15, David Radunz wrote:
> My patch:
This looks like a good idea to me. I'd say we should put it in.
> For example:
>
> print STDERR 'time_constant = '. &time_constant(). "\n";
> sub time_constant () {
> time. ' '. $$;
> }
>
> running under 'httpd -X'
>
> would produce a different time each request, and the same process id.
That's okay, since it would give a different time under CGI as well.
My advice in general is that you just shouldn't use constants in Perl.
The subroutine thing is kind of a hack, and the confusing problems with
stringification are not worth the performance boost. Just use package
variables instead. This doesn't work so well for running other people's
code though.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::PerlRun - Constant subroutine redefined
Posted by David Radunz <da...@staff.netspace.net.au>.
Also forgot to mention, this is running:
mod_perl 1.29
perl 5.8.4
apache 1.3.27
and ..
SunOS *** 5.9 Generic_112234-08 i86pc i386 i86pc
Cheers
On Mon, 2004-10-04 at 16:15, David Radunz wrote:
> Hi All,
>
> I have looked high and low to work out how to avoid the 'Constant
> subroutine redefined' warnings in the error log, followed by the
> 'Prototype missmatch:' error upon subsequent hits to the apache child
> process - but, I have not been able to find an easy solution. The
> warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
> which attempts to reset/nullify everything - including constants. When a
> constant is redefined it causes a warning in the error_log, and when the
> constant gets reset upon the next run of the script the prototype doesnt
> match as its reset incorrectly.
>
> I found a message from Stass Beckman saying that you could use a
> $SIG{__WARN__} handler to filter the warnings. This works for the
> 'Constant subroutine redefined' warnings, but not the 'Prototype
> missmatch:' warnings (even thou I modified it to take both into
> account), no matter where i add the $SIG{__WARN__} handler it never gets
> called in the case of 'Prototype missmatch:' - not even when its defined
> in the startup.pl
>
> So I decided to work out a way to modify Apache::PerlRun so that it
> did not redefine constants. There is no need to nullify constants as
> they will not and CAN NOT change between child instances, and
> documentation indicates that the 'Constant subroutine redefined' warning
> means that the original value will be retained anyway (i.e. you cant
> change a constants value).
>
> Constants in perl are anonymous code references with a blank
> prototype, that is how they are created within constant.pm here is a
> snippet:
>
> *{$fullname} = sub () { };
>
> So if you had:
>
> use constant TRUE => 1;
>
> it would become:
>
> *{$fullname} = sub () { 1 };
>
> where $fullname was main::TRUE
>
> When a subroutine is defined with a prototype of '()' and it returns a
> constant result when compiled, it becomes a 'constant subroutine'.
> Hence, constants are meerly constant subroutines.
>
> So now for the changes I made to PerlRun.pm, below is the original
> code:
>
>
> if (defined &$fullname) {
> no warnings;
> local $^W = 0;
> if (defined(my $p = prototype $fullname)) {
> *{$fullname} = eval "sub ($p) {}";
> }
> else {
> *{$fullname} = sub {};
> }
> undef &$fullname;
> }
>
> So, this code would reset every subroutine to a blank anonymous
> subroutine, using the correct (current) prototype. And then undefine it.
>
> My patch:
>
> if (defined &$fullname) {
> no warnings;
> local $^W = 0;
> if (defined(my $p = prototype $fullname)) {
> # We DONT want to redefine constant subroutines (sub ())
> if ($p) {
> *{$fullname} = eval "sub ($p) {}";
> undef &$fullname;
> }
> }
> else {
> *{$fullname} = sub {};
> undef &$fullname;
> }
> }
>
> This code will reset every subroutine that does not have an empty
> prototype and then undef it. So basically the 'sub () {}' defined
> subroutines are not reset (but sub {} and sub ($) {} are reset).
>
> Now, im aware this is not an ideal solution due to the fact that any
> subroutines declared in a script with a () prototype will not be reset.
> But on the flip side of the coin all constants will be left intact and
> any warnings in the error log avoided. My question is, what caveats
> would there be in not resetting a subroutine? I have ran some tests to
> see how subroutines setup in this way would work and the tests appear to
> be good.
>
> For example:
>
> print STDERR 'time_constant = '. &time_constant(). "\n";
> sub time_constant () {
> time. ' '. $$;
> }
>
> running under 'httpd -X'
>
> would produce a different time each request, and the same process id.
>
> as did..
>
> my $time_constant = sub () { time. ' '. $$ };
> print STDERR 'var time_constant = '. &{$time_constant}. "\n";
>
>
> Sorry this email is a tad long, but its quite complicated to explain.
>
> Cheers,
>
>
> --
> David Radunz,
> Developer / Programmer
>
> Netspace Online Systems Pty Ltd
> Ground Floor, 293 Camberwell Road
> Camberwell, Victoria 3124
> Ph: +613 9811 0087
> Fx: +613 9811 0044
> Mo: +614 0549 9719
> Em: david.radunz@staff.netspace.net.au
>
> This email and any files transmitted with it are confidential and intended solely for the
> use of the individual or entity to whom they are addressed. Please notify the sender
> immediately by email if you have received this email by mistake and delete this email
> from your system. Please note that any views or opinions presented in this email are solely
> those of the author and do not necessarily represent those of the organisation.
> Finally, the recipient should check this email and any attachments for the presence of
> viruses. The organisation accepts no liability for any damage caused by any virus
> transmitted by this email.
--
David Radunz,
Developer / Programmer
Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz@staff.netspace.net.au
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::PerlRun - Constant subroutine redefined
Posted by David Radunz <da...@staff.netspace.net.au>.
Further to that - I just tested with an even bigger string and this one
did get cleared fine, so it musnt be the size :(
Not sure what the problem is,
DJ
On Mon, 2004-10-11 at 12:13, David Radunz wrote:
> Hey,
>
> Thanks for your help. I tried using Devel::Unload to see how it works
> and encountered something unexpected. Basically I put the
> 'unload_package_xs' call just above the 'flush_namespace' call. Then I
> printed from within the namespace clearing loop (expecting nothing to be
> printed), yet something did get printed..
>
> Flushing
> Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_2dpr::chargespage_2ecgi::qs
> Flushing
> Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_2dpr::paymentspage_2ecgi::qs
> Flushing
> Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_2dpr::homeadslclientpage_2ecgi::qs
>
> Which isnt that bad, because the rest of the namespace had been cleared,
> except this lonley scalar - I printed it to see if it contained anything
> and got the following:
>
> Scalar = SELECT DECODE.... (i wont paste the whole scalar here, its
> basically a huge SQL statement, about 2000 characters).
>
> Perhaps the scalar was too big to be cleared?
>
> Cheers,
>
> DJ
>
>
> On Sat, 2004-10-09 at 09:08, Philippe M. Chiasson wrote:
> > Stas Bekman wrote:
> >
> > > David Radunz wrote:
> > >
> > >> Hi All,
> > >>
> > >> I have looked high and low to work out how to avoid the 'Constant
> > >> subroutine redefined' warnings in the error log, followed by the
> > >> 'Prototype missmatch:' error upon subsequent hits to the apache child
> > >> process - but, I have not been able to find an easy solution. The
> > >> warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
> > >> which attempts to reset/nullify everything - including constants. When a
> > >> constant is redefined it causes a warning in the error_log, and when the
> > >> constant gets reset upon the next run of the script the prototype doesnt
> > >> match as its reset incorrectly.
> > >
> > >
> > > David, take a look at the ModPerl::PerlRun which now
> > > http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm?r1=1.50&r2=1.51&diff_format=h
> > >
> > > uses:
> > > http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_unload_package_
> > > which Philippe has just added recently. (you will need the current mp2
> > > cvs to see it at works). It solves all these problems in a much
> > > cleaner way. It's still too new to new to be sure that it doesn't have
> > > side-effects, but once it's proved to be good by users, we can just
> > > port it back to mp1.
> >
> > It's also available as a yet to be released on CPAN module
> > (Devel::Unload) here: http://svn.ectoplasm.org/projects/perl/Devel-Unload/
> >
> > You might just try installing Devel::Unload and plugging it into
> > PerlRun.pm and see if it works
> >
> > (untested patch)
> >
> > Index: lib/Apache/PerlRun.pm
> > ===================================================================
> > RCS file: /home/cvs/modperl/lib/Apache/PerlRun.pm,v
> > retrieving revision 1.41
> > diff -u -I$Id -r1.41 PerlRun.pm
> > --- lib/Apache/PerlRun.pm 8 Mar 2003 04:11:09 -0000 1.41
> > +++ lib/Apache/PerlRun.pm 8 Oct 2004 23:08:02 -0000
> > @@ -118,6 +118,8 @@
> > $_r->clear_rgy_endav;
> > $_r->log_error("Apache::PerlRun->compile") if $Debug && $Debug & 4;
> > Apache->untaint($$eval);
> > + use Devel::Unload;
> > + Devel::Unload::unload_package_xs($pr->namespace);
> > {
> > no strict; #so eval'd code doesn't inherit our bits
> > eval $$eval;
> >
> > > If you want to look at the C code that does that, it's
> > > modperl_package_unload in:
> > > http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/modperl_util.c?view=markup
> > >
> > >
> --
> David Radunz,
> Developer / Programmer
>
> Netspace Online Systems Pty Ltd
> Ground Floor, 293 Camberwell Road
> Camberwell, Victoria 3124
> Ph: +613 9811 0087
> Fx: +613 9811 0044
> Mo: +614 0549 9719
> Em: david.radunz@staff.netspace.net.au
>
> This email and any files transmitted with it are confidential and intended solely for the
> use of the individual or entity to whom they are addressed. Please notify the sender
> immediately by email if you have received this email by mistake and delete this email
> from your system. Please note that any views or opinions presented in this email are solely
> those of the author and do not necessarily represent those of the organisation.
> Finally, the recipient should check this email and any attachments for the presence of
> viruses. The organisation accepts no liability for any damage caused by any virus
> transmitted by this email.
--
David Radunz,
Developer / Programmer
Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz@staff.netspace.net.au
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::PerlRun - Constant subroutine redefined
Posted by David Radunz <da...@staff.netspace.net.au>.
Hey,
Thanks for your help. I tried using Devel::Unload to see how it works
and encountered something unexpected. Basically I put the
'unload_package_xs' call just above the 'flush_namespace' call. Then I
printed from within the namespace clearing loop (expecting nothing to be
printed), yet something did get printed..
Flushing
Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_2dpr::chargespage_2ecgi::qs
Flushing
Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_2dpr::paymentspage_2ecgi::qs
Flushing
Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_2dpr::homeadslclientpage_2ecgi::qs
Which isnt that bad, because the rest of the namespace had been cleared,
except this lonley scalar - I printed it to see if it contained anything
and got the following:
Scalar = SELECT DECODE.... (i wont paste the whole scalar here, its
basically a huge SQL statement, about 2000 characters).
Perhaps the scalar was too big to be cleared?
Cheers,
DJ
On Sat, 2004-10-09 at 09:08, Philippe M. Chiasson wrote:
> Stas Bekman wrote:
>
> > David Radunz wrote:
> >
> >> Hi All,
> >>
> >> I have looked high and low to work out how to avoid the 'Constant
> >> subroutine redefined' warnings in the error log, followed by the
> >> 'Prototype missmatch:' error upon subsequent hits to the apache child
> >> process - but, I have not been able to find an easy solution. The
> >> warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
> >> which attempts to reset/nullify everything - including constants. When a
> >> constant is redefined it causes a warning in the error_log, and when the
> >> constant gets reset upon the next run of the script the prototype doesnt
> >> match as its reset incorrectly.
> >
> >
> > David, take a look at the ModPerl::PerlRun which now
> > http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm?r1=1.50&r2=1.51&diff_format=h
> >
> > uses:
> > http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_unload_package_
> > which Philippe has just added recently. (you will need the current mp2
> > cvs to see it at works). It solves all these problems in a much
> > cleaner way. It's still too new to new to be sure that it doesn't have
> > side-effects, but once it's proved to be good by users, we can just
> > port it back to mp1.
>
> It's also available as a yet to be released on CPAN module
> (Devel::Unload) here: http://svn.ectoplasm.org/projects/perl/Devel-Unload/
>
> You might just try installing Devel::Unload and plugging it into
> PerlRun.pm and see if it works
>
> (untested patch)
>
> Index: lib/Apache/PerlRun.pm
> ===================================================================
> RCS file: /home/cvs/modperl/lib/Apache/PerlRun.pm,v
> retrieving revision 1.41
> diff -u -I$Id -r1.41 PerlRun.pm
> --- lib/Apache/PerlRun.pm 8 Mar 2003 04:11:09 -0000 1.41
> +++ lib/Apache/PerlRun.pm 8 Oct 2004 23:08:02 -0000
> @@ -118,6 +118,8 @@
> $_r->clear_rgy_endav;
> $_r->log_error("Apache::PerlRun->compile") if $Debug && $Debug & 4;
> Apache->untaint($$eval);
> + use Devel::Unload;
> + Devel::Unload::unload_package_xs($pr->namespace);
> {
> no strict; #so eval'd code doesn't inherit our bits
> eval $$eval;
>
> > If you want to look at the C code that does that, it's
> > modperl_package_unload in:
> > http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/modperl_util.c?view=markup
> >
> >
--
David Radunz,
Developer / Programmer
Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz@staff.netspace.net.au
This email and any files transmitted with it are confidential and intended solely for the
use of the individual or entity to whom they are addressed. Please notify the sender
immediately by email if you have received this email by mistake and delete this email
from your system. Please note that any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of the organisation.
Finally, the recipient should check this email and any attachments for the presence of
viruses. The organisation accepts no liability for any damage caused by any virus
transmitted by this email.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::PerlRun - Constant subroutine redefined
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> David Radunz wrote:
>
>> Hi All,
>>
>> I have looked high and low to work out how to avoid the 'Constant
>> subroutine redefined' warnings in the error log, followed by the
>> 'Prototype missmatch:' error upon subsequent hits to the apache child
>> process - but, I have not been able to find an easy solution. The
>> warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
>> which attempts to reset/nullify everything - including constants. When a
>> constant is redefined it causes a warning in the error_log, and when the
>> constant gets reset upon the next run of the script the prototype doesnt
>> match as its reset incorrectly.
>
>
> David, take a look at the ModPerl::PerlRun which now
> http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm?r1=1.50&r2=1.51&diff_format=h
>
> uses:
> http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_unload_package_
> which Philippe has just added recently. (you will need the current mp2
> cvs to see it at works). It solves all these problems in a much
> cleaner way. It's still too new to new to be sure that it doesn't have
> side-effects, but once it's proved to be good by users, we can just
> port it back to mp1.
It's also available as a yet to be released on CPAN module
(Devel::Unload) here: http://svn.ectoplasm.org/projects/perl/Devel-Unload/
You might just try installing Devel::Unload and plugging it into
PerlRun.pm and see if it works
(untested patch)
Index: lib/Apache/PerlRun.pm
===================================================================
RCS file: /home/cvs/modperl/lib/Apache/PerlRun.pm,v
retrieving revision 1.41
diff -u -I$Id -r1.41 PerlRun.pm
--- lib/Apache/PerlRun.pm 8 Mar 2003 04:11:09 -0000 1.41
+++ lib/Apache/PerlRun.pm 8 Oct 2004 23:08:02 -0000
@@ -118,6 +118,8 @@
$_r->clear_rgy_endav;
$_r->log_error("Apache::PerlRun->compile") if $Debug && $Debug & 4;
Apache->untaint($$eval);
+ use Devel::Unload;
+ Devel::Unload::unload_package_xs($pr->namespace);
{
no strict; #so eval'd code doesn't inherit our bits
eval $$eval;
> If you want to look at the C code that does that, it's
> modperl_package_unload in:
> http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/modperl_util.c?view=markup
>
>
Re: Apache::PerlRun - Constant subroutine redefined
Posted by Stas Bekman <st...@stason.org>.
David Radunz wrote:
> On Tue, 2004-10-05 at 12:39, Stas Bekman wrote:
>
>>David Radunz wrote:
>>
>>>Heya Stas,
>>>
>>> I like that alot, as you say heaps cleaner. For the time being thou
>>>can you see any problems with us using my patch internally?
>>
>>Looks fine to me.
>>
>
>
> Thanks, we'll put it into production.
Hmm. Well, I said that it looks fine, but you probably want to test it by
yourself to ensure that it works well. I certainly can't guarantee that.
>>>I have run a
>>>few more tests and it seems everything still works pretty good. And of
>>>course keeping an eye out for Apache::RegistryCooker.. or will it be
>>>ported under Apache::PerlRun?
>>
>>Ported under PerlRun.
>>
>>You are more than welcome to do the porting to mp1. It shouldn't be too
>>much work, since the C code should be pretty much copy-n-paste. At the
>>moment we just don't want to touch mp1 and potentially break stable
>>things. So we would like to have that new implementation (courtesy of
>>Philippe Chiasson) to be thoroughly tested by users first.
>>
>
>
> I would love to, but I dont really know much C. If its just copying and
> pasting then I guess it wouldnt be that bad, did you mean make a new
> Apache::* module, say Apache::ModPerlUtil (since Apache::Util is used)
> and then modify Apache::PerlRun to use that?
More or less yes. But let's just wait and see how the mp2 solution scores
first.
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::PerlRun - Constant subroutine redefined
Posted by David Radunz <da...@staff.netspace.net.au>.
On Tue, 2004-10-05 at 12:39, Stas Bekman wrote:
> David Radunz wrote:
> > Heya Stas,
> >
> > I like that alot, as you say heaps cleaner. For the time being thou
> > can you see any problems with us using my patch internally?
>
> Looks fine to me.
>
Thanks, we'll put it into production.
> > I have run a
> > few more tests and it seems everything still works pretty good. And of
> > course keeping an eye out for Apache::RegistryCooker.. or will it be
> > ported under Apache::PerlRun?
>
> Ported under PerlRun.
>
> You are more than welcome to do the porting to mp1. It shouldn't be too
> much work, since the C code should be pretty much copy-n-paste. At the
> moment we just don't want to touch mp1 and potentially break stable
> things. So we would like to have that new implementation (courtesy of
> Philippe Chiasson) to be thoroughly tested by users first.
>
I would love to, but I dont really know much C. If its just copying and
pasting then I guess it wouldnt be that bad, did you mean make a new
Apache::* module, say Apache::ModPerlUtil (since Apache::Util is used)
and then modify Apache::PerlRun to use that?
> p.s. please don't CC your posts to other address at your domain since it
> bounces.
Sorry - I didnt know that the internal mailing lists didnt allow
external emails.
Thanks
--
David Radunz,
Developer / Programmer
Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz@staff.netspace.net.au
This email and any files transmitted with it are confidential and intended solely for the
use of the individual or entity to whom they are addressed. Please notify the sender
immediately by email if you have received this email by mistake and delete this email
from your system. Please note that any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of the organisation.
Finally, the recipient should check this email and any attachments for the presence of
viruses. The organisation accepts no liability for any damage caused by any virus
transmitted by this email.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::PerlRun - Constant subroutine redefined
Posted by Stas Bekman <st...@stason.org>.
David Radunz wrote:
> Heya Stas,
>
> I like that alot, as you say heaps cleaner. For the time being thou
> can you see any problems with us using my patch internally?
Looks fine to me.
> I have run a
> few more tests and it seems everything still works pretty good. And of
> course keeping an eye out for Apache::RegistryCooker.. or will it be
> ported under Apache::PerlRun?
Ported under PerlRun.
You are more than welcome to do the porting to mp1. It shouldn't be too
much work, since the C code should be pretty much copy-n-paste. At the
moment we just don't want to touch mp1 and potentially break stable
things. So we would like to have that new implementation (courtesy of
Philippe Chiasson) to be thoroughly tested by users first.
p.s. please don't CC your posts to other address at your domain since it
bounces.
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::PerlRun - Constant subroutine redefined
Posted by David Radunz <da...@staff.netspace.net.au>.
Heya Stas,
I like that alot, as you say heaps cleaner. For the time being thou
can you see any problems with us using my patch internally? I have run a
few more tests and it seems everything still works pretty good. And of
course keeping an eye out for Apache::RegistryCooker.. or will it be
ported under Apache::PerlRun?
Cheers
On Tue, 2004-10-05 at 11:34, Stas Bekman wrote:
> David Radunz wrote:
> > Hi All,
> >
> > I have looked high and low to work out how to avoid the 'Constant
> > subroutine redefined' warnings in the error log, followed by the
> > 'Prototype missmatch:' error upon subsequent hits to the apache child
> > process - but, I have not been able to find an easy solution. The
> > warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
> > which attempts to reset/nullify everything - including constants. When a
> > constant is redefined it causes a warning in the error_log, and when the
> > constant gets reset upon the next run of the script the prototype doesnt
> > match as its reset incorrectly.
>
> David, take a look at the ModPerl::PerlRun which now
> http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm?r1=1.50&r2=1.51&diff_format=h
> uses:
> http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_unload_package_
> which Philippe has just added recently. (you will need the current mp2 cvs
> to see it at works). It solves all these problems in a much cleaner way.
> It's still too new to new to be sure that it doesn't have side-effects,
> but once it's proved to be good by users, we can just port it back to mp1.
>
> If you want to look at the C code that does that, it's
> modperl_package_unload in:
> http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/modperl_util.c?view=markup
--
David Radunz,
Developer / Programmer
Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz@staff.netspace.net.au
This email and any files transmitted with it are confidential and intended solely for the
use of the individual or entity to whom they are addressed. Please notify the sender
immediately by email if you have received this email by mistake and delete this email
from your system. Please note that any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of the organisation.
Finally, the recipient should check this email and any attachments for the presence of
viruses. The organisation accepts no liability for any damage caused by any virus
transmitted by this email.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::PerlRun - Constant subroutine redefined
Posted by Stas Bekman <st...@stason.org>.
David Radunz wrote:
> Hi All,
>
> I have looked high and low to work out how to avoid the 'Constant
> subroutine redefined' warnings in the error log, followed by the
> 'Prototype missmatch:' error upon subsequent hits to the apache child
> process - but, I have not been able to find an easy solution. The
> warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
> which attempts to reset/nullify everything - including constants. When a
> constant is redefined it causes a warning in the error_log, and when the
> constant gets reset upon the next run of the script the prototype doesnt
> match as its reset incorrectly.
David, take a look at the ModPerl::PerlRun which now
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm?r1=1.50&r2=1.51&diff_format=h
uses:
http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_unload_package_
which Philippe has just added recently. (you will need the current mp2 cvs
to see it at works). It solves all these problems in a much cleaner way.
It's still too new to new to be sure that it doesn't have side-effects,
but once it's proved to be good by users, we can just port it back to mp1.
If you want to look at the C code that does that, it's
modperl_package_unload in:
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/modperl_util.c?view=markup
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html