On Thu, 2004-04-01 at 18:31, Stas Bekman wrote:
> [EMAIL PROTECTED] 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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- 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
signature.asc
Description: This is a digitally signed message part
