Re^2: Propagating a Signal from DESTROY

[dpuu]

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.

[TilRMan]

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.

[dpuu]

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;
  }
}

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";
}