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 2004/04/02 04:31:18 UTC
remaing END blocks issues (was Re: cvs commit: modperl-2.0/todo release)
stas@apache.org wrote:
> stas 2004/04/01 18:17:46
>
> Modified: ModPerl-Registry/lib/ModPerl RegistryCooker.pm
> ModPerl-Registry/t perlrun_extload.t special_blocks.t
> ModPerl-Registry/t/cgi-bin perlrun_decl.pm
> perlrun_extload.pl perlrun_nondecl.pl
> special_blocks.pl
> ModPerl-Registry/t/conf modperl_extra_startup.pl
> src/modules/perl mod_perl.c modperl_handler.c modperl_perl.c
> modperl_perl.h modperl_perl_global.c
> modperl_perl_global.h modperl_util.c modperl_util.h
> t/response/TestModperl endav.pm
> xs/ModPerl/Global ModPerl__Global.h
> xs/maps modperl_functions.map
> xs/tables/current/ModPerl FunctionTable.pm
> . Changes
> todo release
[...]
> -* child processes never run END blocks. a good example is
> - Apache::TestUtil, which doesn't cleanup files and dirs it has
> - created, because the END block is not run.
> - also: see the next item
> - owner: stas
> -
> -* ModPerl::Registry END {} block woes , described in details at the
> - forwarded message from Jim Schueler
> - http://marc.theaimsgroup.com/?l=apache-modperl&m=103720834717981&w=2
> - the whole thread is here:
> - http://marc.theaimsgroup.com/?t=103713532800003&r=1&w=2
> - owner: stas
The gist of this big patch is simple.
1) Now only registered packages will snap END blocks from PL_endav under
perl-script (and a user has a complete control if they want any extra packages
to be registered and their END blocks to be run).
2) the END blocks are now run by the child processes (they weren't before,
since they were never moved out of PL_modglobal into PL_endav).
A few remaining END blocks issues:
1) we probably should *not* run END blocks inherited from the parent process,
otherwise we have BEGIN blocks run once in the parent, and END blocks run N
times (once in the parent and once in each child process). So we should
probably reset PL_endav in child_init.
2) there are several issues with threaded mpms at the server shutdown:
Attempt to free unreferenced scalar: SV 0xc4b8fd8 during global destruction.
Attempt to free temp prematurely: SV 0xc46a2ac during global destruction.
Scalars leaked: 1
I'll be looking at it.
3) I have a concern regarding 'httpd -k stop', sending SIGTERM. It's known
that we have a problem with httpd, which is not considered of any pool
cleanups that are still running and will just abort them if they are too slow.
So by enabling this run of END blocks in child_exit we raise the chance that
pool cleanups will be aborted. Making cleanups very unreliable. Last I
mentioned this on apr-dev, I was sent to httpd-dev. I guess we need to pursue
this issue with httpd-dev.
4) END blocks running too many times:
http://marc.theaimsgroup.com/?t=106387825600002&r=1&w=2
I haven't had a change to work on this one yet.
__________________________________________________________________
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: remaing END blocks issues (was Re: cvs commit: modperl-2.0/todo
release)
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
>>The gist of this big patch is simple.
>>
>>1) Now only registered packages will snap END blocks from PL_endav under
>>perl-script (and a user has a complete control if they want any extra packages
>>to be registered and their END blocks to be run).
>>
>>2) the END blocks are now run by the child processes (they weren't before,
>>since they were never moved out of PL_modglobal into PL_endav).
>
>
> Awesome!
:)
>>A few remaining END blocks issues:
>>
>>1) we probably should *not* run END blocks inherited from the parent process,
>>otherwise we have BEGIN blocks run once in the parent, and END blocks run N
>>times (once in the parent and once in each child process). So we should
>>probably reset PL_endav in child_init.
>
>
> Yes, this makes sense and it's the assumption I would make as a user.
Actually, I'm not sure it's a good idea after all. Normally fork() inherits
END blocks in perl:
% perl -le 'END { warn "$$: This is the end"}; fork'
8912: This is the end at -e line 1.
8911: This is the end at -e line 1.
So if we want to keep things indentical to perl we should keep it?
Looking at mp1, it doesn't run END blocks in the child processes. I guess
noone needed that feature.
Actually I found that problem when Apache-Test wasn't cleaning files/dirs it
created at run time and supposed to cleanup via an END block.
So now I'm a bit puzzled what's the best course to take.
__________________________________________________________________
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: remaing END blocks issues (was Re: cvs commit:
modperl-2.0/todo release)
Posted by "Philippe M. Chiasson" <go...@cpan.org>.
On Thu, 2004-04-01 at 18:31, Stas Bekman wrote:
> stas@apache.org wrote:
> > stas 2004/04/01 18:17:46
> >
> > Modified: ModPerl-Registry/lib/ModPerl RegistryCooker.pm
> > ModPerl-Registry/t perlrun_extload.t special_blocks.t
> > ModPerl-Registry/t/cgi-bin perlrun_decl.pm
> > perlrun_extload.pl perlrun_nondecl.pl
> > special_blocks.pl
> > ModPerl-Registry/t/conf modperl_extra_startup.pl
> > src/modules/perl mod_perl.c modperl_handler.c modperl_perl.c
> > modperl_perl.h modperl_perl_global.c
> > modperl_perl_global.h modperl_util.c modperl_util.h
> > t/response/TestModperl endav.pm
> > xs/ModPerl/Global ModPerl__Global.h
> > xs/maps modperl_functions.map
> > xs/tables/current/ModPerl FunctionTable.pm
> > . Changes
> > todo release
> [...]
> > -* child processes never run END blocks. a good example is
> > - Apache::TestUtil, which doesn't cleanup files and dirs it has
> > - created, because the END block is not run.
> > - also: see the next item
> > - owner: stas
> > -
> > -* ModPerl::Registry END {} block woes , described in details at the
> > - forwarded message from Jim Schueler
> > - http://marc.theaimsgroup.com/?l=apache-modperl&m=103720834717981&w=2
> > - the whole thread is here:
> > - http://marc.theaimsgroup.com/?t=103713532800003&r=1&w=2
> > - owner: stas
>
> The gist of this big patch is simple.
>
> 1) Now only registered packages will snap END blocks from PL_endav under
> perl-script (and a user has a complete control if they want any extra packages
> to be registered and their END blocks to be run).
>
> 2) the END blocks are now run by the child processes (they weren't before,
> since they were never moved out of PL_modglobal into PL_endav).
Awesome!
> A few remaining END blocks issues:
>
> 1) we probably should *not* run END blocks inherited from the parent process,
> otherwise we have BEGIN blocks run once in the parent, and END blocks run N
> times (once in the parent and once in each child process). So we should
> probably reset PL_endav in child_init.
Yes, this makes sense and it's the assumption I would make as a user.
> 2) there are several issues with threaded mpms at the server shutdown:
> Attempt to free unreferenced scalar: SV 0xc4b8fd8 during global destruction.
> Attempt to free temp prematurely: SV 0xc46a2ac during global destruction.
> Scalars leaked: 1
> I'll be looking at it.
>
> 3) I have a concern regarding 'httpd -k stop', sending SIGTERM. It's known
> that we have a problem with httpd, which is not considered of any pool
> cleanups that are still running and will just abort them if they are too slow.
> So by enabling this run of END blocks in child_exit we raise the chance that
> pool cleanups will be aborted. Making cleanups very unreliable. Last I
> mentioned this on apr-dev, I was sent to httpd-dev. I guess we need to pursue
> this issue with httpd-dev.
>
> 4) END blocks running too many times:
> http://marc.theaimsgroup.com/?t=106387825600002&r=1&w=2
> I haven't had a change to work on this one yet.
>
> __________________________________________________________________
> 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
--
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ FPR:F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5