Seshouan has asked for the wisdom of the Perl Monks concerning the following question:

The following code doesn't work: 
#!/usr/bin/perl -w

sub my_sig_int_handler {
    open (OUT,">info.txt");
    print OUT "Woo-Hoo!\n";
    close(OUT);
}

my $oldSigInt = $SIG{INT};
$SIG{INT} = \&my_sig_int_handler;
print "process $$\n";
sleep(3);
kill 'INT', $$;
sleep(5);

[download]
The interrupt is only handled if I press "CTRL-C" on the console. Why doesn't the kill function send the appropriate signal?

Replies are listed 'Best First'.
Re: signal trapping
by tachyon (Chancellor) on Sep 28, 2001 at 23:11 UTC

    Have a look at kill() in the docs which will point you to the perlman:perlipc manpage where you can read this:

    Some signals can be neither trapped nor ignored, such as the KILL and STOP (but not the TSTP) signals.

    Many details about Perl IPC are on this manpage.

    cheers

    tachyon

    s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[reply]
Re: signal trapping
by dragonchild (Archbishop) on Sep 28, 2001 at 22:59 UTC
    If you try it, but using a second script to send the signal, it works just fine.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]
      I tried it and sent the signal from another script, but it still doesn't work, no output file is being created, the signal wasn't captured. How did you make yours work? This is my original script: 
      #!/usr/bin/perl -w

sub my_sig_int_handler {
    open (OUT,">info.txt");
    print OUT "Woo-Hoo!\n";
    close(OUT);
}

$SIG{INT} = \&my_sig_int_handler;
print "process $$\n";
while(1){}

      [download]
      The calling script contains the following: 
      #!/usr/bin/perl -w
$process = shift;
kill 'INT', $process;

      [download]
      when I launch the second script, the orginal one quits but does not capture the interrupt in order to create the output file. Show me what you did.
[reply]
[d/l]
[select]
        What platform are you on? I suspect that this is one of those platform-dependant things. Mine didn't work on Control-C, even when I cut'n'pasted your code. *shrugs*

        ------
        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]
Re: signal trapping
by converter (Priest) on Sep 29, 2001 at 11:15 UTC

    It is a bad idea to do I/O inside an interupt handler. You should set a flag, then return. In your code, check the flag value and act accordingly if it's set. This doesn't address your problem directly, but it seems to be sound advice and worth mentioning here.

    Notice this snippet from perlipc:

    For example, to trap an interrupt signal, set up a handler like this. Do as little as you possibly can 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 means that doing nearly anything in your handler could in theory trigger a memory fault and subsequent core dump.

    the signal(7) manpage lists a table of signals by name along with their values, actions and descriptions.

    conv

[reply]

Back to Seekers of Perl Wisdom