From @dgl

In despatch_signals in mg.c there's a comment explaining how perl
tries to emulate a behaviour of real signals in safe signals​:

  /* From sigaction(2) (FreeBSD man page)​:
  * | Signal routines normally execute with the signal that
  * | caused their invocation blocked, but other signals may
  * | yet occur.
  * Emulation of this behavior (from within Perl) is enabled
  * using sigprocmask
  */

However there's an issue in the emulation​: if a signal handler
directly calls exec() the signal is never unblocked, because the
destructor/clean up function set up in Perl_despatch_signals isn't
called.

David

From @Leont

On Sat, Aug 25, 2012 at 1​:17 PM, David Leadbeater
<perlbug-followup@​perl.org> wrote​:

# New Ticket Created by David Leadbeater
# Please include the string​: [perl #114586]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=114586 >

In despatch_signals in mg.c there's a comment explaining how perl
tries to emulate a behaviour of real signals in safe signals​:

        /\* From sigaction\(2\) \(FreeBSD man page\)​:
         \* | Signal routines normally execute with the signal that
         \* | caused their invocation blocked\, but other signals may
         \* | yet occur\.
         \* Emulation of this behavior \(from within Perl\) is enabled
         \* using sigprocmask
         \*/

However there's an issue in the emulation​: if a signal handler
directly calls exec() the signal is never unblocked, because the
destructor/clean up function set up in Perl_despatch_signals isn't
called.

But is that really different from the unsafe version? I'd expect it
not to be, though I don't think POSIX is explicit about this case.

Leon

The RT System itself - Status changed from 'new' to 'open'