in reply to Setting signal handlers

That's the POSIX way to do things. It's as ugly in Perl as it's in C, since in C it's also done a la POSIX. Fortunately in Perl we have Another Way To Do It:

sub interrupt { print "quitting!\n"; }
$SIG{'INT'} = 'interrupt';
sleep 20;
__END__
^C
quitting!

[download]

--
David Serrano

Replies are listed 'Best First'.
Re^2: Setting signal handlers
by andyford (Curate) on May 09, 2006 at 21:17 UTC
    Thanks David but

    I tried that first and it didn't work. Supposedly it's because "POSIX unmasks the sigprocmask properly".

    Not sure what that means, but the POSIX way works and the Perl way doesn't.

[reply]

      What did you try exactly? Without some code it's difficult to guess why it's not working for you. You should post a small complete program that shows the problem and tell us what do you expect and what is happening instead.

      --
      David Serrano

[reply]

      Well, back in 2000, I gave up on a module (Server::FastPL, now on backpan) because of lost signals and unix sockets constant lock up... My experience told me to not trust signals for anything really important... I did use the $SIG way... maybe the problem is related...

      daniel
[reply]
        In perl 5.8.0, released in 2002, we introduced the concept of 'safe signals'. This makes the perl interpreter interruptable onbly on opcode boundaries. This removed a lot of the reentrancy and race problems that perl used to have handling signals, at the risk of sometimes delaying the handling of the signal.

        You may want to see if your old signal code workes better now.

        Dave.

[reply]

In Section Seekers of Perl Wisdom