The alarm(0) in the CHLD handler is a good idea, but this doesn't relate at all to the second scenario I presented (parent->SIGUSR1->child). So while it might be a workaround for the first case, it is not a general solution.
I think the key issue is illustrated by this phrase:
Perl no longer handles signals immediately but instead "between opcodes",
when it is safe to do so.
While this sounds good, it still does not say whether or not this 'bug' exists.
If one opcode is the end of the eval block, and the next opcode is to start
restoring %SIG, but a signal occurs in between them, then that is a bug. It is
not enough to suppress signal handling between opcodes. Perl needs to go
further and ensure safe signal handling when the %SIG hash modified inside an
eval block.
But again, my original request still exists. Would someone familiar with the Perl interpreter's code please verify what I am saying. Is there a 'gap' between the end of an eval block and the restoration of the %SIG hash such that an incoming signal could result in execution of the (now defunct) local signal handler that was inside the eval block?
In reply to Re: Re: BUG? die() executing outside scope of eval block
by jdhedden
in thread BUG! die() executing outside scope of eval block
by jdhedden
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |