Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > POSIX signal handling: inputs needed

Reply
Thread Tools

POSIX signal handling: inputs needed

 
 
monk
Guest
Posts: n/a
 
      11-22-2007
Hi all,

Is it safe/sane/common practice to have a program react to every
single POSIX signal there is out there available in the OS?

Some friends have suggested to just stick to the basic ones such as
TSTP and INT. Meaning, tell the program to do something (like an
email alert) if it receives a control-Z or control-C only. But what
about the others?

My fear is that my chronic paranoia might get in the way, thus making
my programs unstable.
At the same time, I don't want to miss any unseen events that may
affect my programs reliability.

Positively, _*any*_ thoughts are welcome.

for example, to see what I mean if confusing above. I don't know if it
matters but I'm using Linux 2.6.x and AIX 5.3 with perl 5.8.2. Thanks
in advance. :

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

#all this does is print "hello world" every 1 second --given a true
condition.
#if *any* signal is received, the status changes to false exiting the
program gracefully.

#my vars
my $signal;
my $status = 1;
my $pid;
my @all_signals;
my $file_handler;


#sub routine handling the signal received
sub signal_handler {
$signal = shift;
$status = 0;
$SIG{$signal} = \&signal_handler;

}

#get all signals available on AIX
#add them up to an array

sub get_all_my_signals {
foreach my $list (sort keys %SIG){
push (@all_signals, $list);
}

}

sub go {

#get all signals available on this OS
get_all_my_signals();


#if any signal is received, change status to zero
#thus exiting the loop.
foreach (@all_signals){
$SIG{$_} = \&signal_handler;
}

#Current process' PID is
$pid = $$;

#writing pid to a file
open ($file_handler, ">", "test.pid");
print $file_handler $pid;
close $file_handler;

while ($status == 1){
print "hello world\n";
sleep 1;
}
print "out of loop. Got signal \$SIG{$signal}\n";

#house keeping
unlink "test.pid" if (-e "test.pid");
exit(0);
}

###done defniing now let's call it
#call it now..
go();
 
Reply With Quote
 
 
 
 
Peter Makholm
Guest
Posts: n/a
 
      11-22-2007
monk <> writes:

> Some friends have suggested to just stick to the basic ones such as
> TSTP and INT. Meaning, tell the program to do something (like an
> email alert) if it receives a control-Z or control-C only. But what
> about the others?


I would suggest to stick with the signals intended meanings. Do not
redefine SIGINT to mean anything but 'user tried to interrupt the
process'. Only exception is that you're allowed to use SIGHUP for
restarting af server and rereading the configuration.

If you need to use signals for some user defined actions you should
use SIGUSR1 and SIGUSR2.

> My fear is that my chronic paranoia might get in the way, thus making
> my programs unstable.
> At the same time, I don't want to miss any unseen events that may
> affect my programs reliability.


Catching all signals will lead to instabilities. Taking you example,
do you really mean to stop just because you're resizin you window to
see more hellos (SIGWINCH)? And if you using tcp communication, do you
really want to take some action if the other end sends a specially
crafted package (SIGURG) - this can lead to a DoS-attack.

//Makholm
 
Reply With Quote
 
 
 
 
monk
Guest
Posts: n/a
 
      11-22-2007
Thanks for your comments mate.

>I would suggest to stick with the signals intended meanings.

Ok. I'll use HUP, INT, TSTP, and TERM -after reading your
warnings.
As you pointed out, "Catching all signals will lead to instabilities"
which is quite right.

Of all the signal posix, which ones in your opinion are the most
common ones? (besides that ones above and the ones you already
mentioned.)
 
Reply With Quote
 
xhoster@gmail.com
Guest
Posts: n/a
 
      11-23-2007
monk <> wrote:
> Hi all,
>
> Is it safe/sane/common practice to have a program react to every
> single POSIX signal there is out there available in the OS?



Sounds strange to me. If you don't know what the signal is, why you are
getting it, or what to do with it, then why not just let the default
behavior prevail? I'm only going to override the default behavior
(presumably crafted by people who know far more about such system things
than I do) if I have specific knowledge about how my program should
interact with that part of their system.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
threading.Thread vs. signal.signal Jack Orenstein Python 0 09-17-2005 11:24 PM
Async-signal safe functions in signal handlers (unix) Michael Pronath Python 1 01-03-2005 01:10 PM
signal handlers: does %SIG{'CLD'} require explicit SA_NOCLDSTOP via POSIX funcs? steffen staehle Perl 0 09-07-2004 03:22 PM
Re: signal handlers: does %SIG{'CLD'} require explicit SA_NOCLDSTOP via POSIX funcs? steffen staehle Perl 0 09-07-2004 03:22 PM
signal handlers: does %SIG{'CLD'} require explicit SA_NOCLDSTOP via POSIX funcs? steffen staehle Perl 0 09-07-2004 03:22 PM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57