Re: Propagating a Signal from DESTROY

The trick is not to propagate the signal, but instead set a flag, continue with the destructors, and handle the signal when it is safe to do so. This is in keeping with the general philosophy that signal handlers should be very simple -- especially in Perl. (I can't recall where I read this; perhaps someone can provide a pointer to more details.)

#!/usr/bin/perl -l
use strict;
use warnings;

my $sig;

END
{
  local $?;
  print "Handling signal $sig" if $sig;
}

$SIG{INT} = sub { $sig = shift; print "Got signal $sig" };

{
  package Foo;
  sub new { bless [$_[1]], $_[0] }
  sub DESTROY { print shift->[0], "->DESTROY()"; sleep 2 }
}

my $foo = new Foo "foo";
my $bar = new Foo "bar";

print "Now press Ctrl-C";
[download]

Update: Thanks to Mr_Person for finding the details.

Comment on Re: Propagating a Signal from DESTROY Download Code

Replies are listed 'Best First'.
Re^2: Propagating a Signal from DESTROY by Mr_Person (Hermit) on Aug 20, 2004 at 13:29 UTC
perlipc provides some more details. Look especially under Signals and Deferred Signals. Aparently Perl does some of the safer signal handling internally, in new versions anyways. Here's the relevant parts: Prior to Perl 5.7.3 it was necessary to do as little as you possibly could in your handler; notice how all we do is set a global variable and then raise an exception. That's because on most systems, libraries are not re-entrant; particularly, memory allocation and I/O routines are not. That meant that doing nearly anything in your handler could in theory trigger a memory fault and subsequent core dump. In Perl 5.7.3 and later to avoid these problems signals are "deferred"-- that is when the signal is delivered to the process by the system (to the C code that implements Perl) a flag is set, and the handler returns immediately. Then at strategic "safe" points in the Perl interpreter (e.g. when it is about to execute a new opcode) the flags are checked and the Perl level handler from %SIG is executed. The "deferred" scheme allows much more flexibility in the coding of signal handler as we know Perl interpreter is in a safe state, and that we are not in a system library function when the handler is called. If you have an older version of Perl, you'll still need to watch out for potential problems. In either case, it's probably still best for you to just set a flag and handle it later instead of rethrowing the signal.	[reply]
Re^2: Propagating a Signal from DESTROY by dpuu (Chaplain) on Aug 20, 2004 at 15:56 UTC
The problem with that approach is, of course, that you need to litter your code with checks of your flag-variable. If you're using a lot of modules (especially slow ones), then you might need to go through those modules' source code and add these same checks there. That seems incredibly non-scalable.	[reply]
Re^3: Propagating a Signal from DESTROY by TilRMan (Friar) on Aug 20, 2004 at 16:05 UTC
The delayed-handler approach is only necessary where you don't want to be interrupted. In the OP's case, change from the real signal handler to the delayed one at the very end of the program -- right before the destructors.	[reply]
Re^4: Propagating a Signal from DESTROY by dpuu (Chaplain) on Aug 20, 2004 at 16:30 UTC
My reading is that OP did want to be interrupted, but didn't want to jump straight to the end of the program. He wants the interrupt to kill the current eval-block, but then to do some more processing. I could make his example a bit more tricky by requiring that we recover from the interrupt, rather than dying. I.e. `START: my $interrupted = 0; eval { local $SIG{INT} = sub { $interrupted = 1; die }; ... } if ($@) { if ($interrupted) { print "Operation was interrupted by ^C. Press <return> to retry, ^ +C to die\n"; scalar <STDIN>; goto START; } }` [download] If the interrupt hits when the code is in a DTOR, then it will not kill the eval block, and the user will not be asked to retry. In fact, the only effect of the interrupt will be to set $interrupted; and to cause some resource to not be properly cleaned up. We could detect that this happenned by checking: `if ($@) { ... } elsif ($interrupted) { print "interrupted but didn't die. Must have hit ^C during DTOR. Sor +ry.\n"; die "better late than never!\n"; }` [download]	[reply] [d/l] [select]