Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Propagating a Signal from DESTROY

by TilRMan (Friar)
on Aug 20, 2004 at 09:21 UTC ( #384565=note: print w/ replies, xml ) Need Help??


in reply to 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";

Update: Thanks to Mr_Person for finding the details.


Comment on Re: Propagating a Signal from DESTROY
Download Code
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.
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.
      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.
        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"; }

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://384565]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (6)
As of 2014-08-22 22:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (168 votes), past polls