Re: [PATCH 5.6.0] local $SIG{FOO} restoration

[Hugo <hv...@crypt.compulink.co.uk>]

In <Pi...@mojo.covalent.net>,
Doug MacEachern writes:
:when 'local $SIG{ALRM} = sub {...}' goes out of scope, magic_setsig() sets
:the SIGALRM handler to SIG_DFL, rather than the original handler.  this
:causes quite a bit of trouble running inside of apache, since 'local
:$SIG{ALRM}' unhooks the apache SIGALRM handler for the life of that
:proccess.
:the original handler is already fetched by magic_getsig(), this patch
:saves that pointer so it can be restored in magic_setsig().
[snip]

I believe that this (or take2) might cause a problem for code like:

  sub handler { print "sig handled" }
  my $handlesub = "handler";

  [... something reads $handlesub in numeric context ...]

  $SIG{ALRM} = $handlesub;

I'm not sure how big a concern that should be, if it is true.

Hugo

Re: [PATCH 5.6.0] local $SIG{FOO} restoration

[Doug MacEachern <do...@covalent.net>]

On Wed, 29 Mar 2000, Hugo wrote:
 
> I believe that this (or take2) might cause a problem for code like:
> 
>   sub handler { print "sig handled" }
>   my $handlesub = "handler";
> 
>   [... something reads $handlesub in numeric context ...]
> 
>   $SIG{ALRM} = $handlesub;

i suppose the handler should not be restored if it was Perl's, something
along the lines of (on top of take2 patch):

--- mg.c~       Tue Mar 28 23:44:09 2000
+++ mg.c        Thu Mar 30 11:50:05 2000
@@ -966,7 +966,7 @@
            /* cache state so we don't fetch it again */
            if(sigstate == SIG_IGN)
                sv_setpv(sv,"IGNORE");
-           else if (sigstate)
+           else if (sigstate && sigstate != PL_sighandlerp)
                sv_setiv(sv,(IV)sigstate);
            else
                sv_setsv(sv,&PL_sv_undef);