You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by "Philippe M. Chiasson" <go...@cpan.org> on 2004/04/02 21:15:08 UTC
Re: remaing END blocks issues (was Re: cvs commit:
modperl-2.0/todo release)
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
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