SIGNAL(2) Linux Programmer’s Manual SIGNAL(2)
NAME
signal - ANSI C signal handling
SYNOPSIS
#include <signal.h>
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);
DESCRIPTION
The signal() system call installs a new signal handler for the signal with number
signum. The signal handler is set to sighandler which may be a user specified
function, or either SIG_IGN or SIG_DFL.
Upon arrival of a signal with number signum the following happens. If the corre-
sponding handler is set to SIG_IGN, then the signal is ignored. If the handler is
set to SIG_DFL, then the default action associated to the signal (see signal(7))
occurs. Finally, if the handler is set to a function sighandler then first either
the handler is reset to SIG_DFL or an implementation-dependent blocking of the sig-
nal is performed and next sighandler is called with argument signum.
Using a signal handler function for a signal is called "catching the signal". The
signals SIGKILL and SIGSTOP cannot be caught or ignored.
RETURN VALUE
The signal() function returns the previous value of the signal handler, or SIG_ERR
on error.
PORTABILITY
The original Unix signal() would reset the handler to SIG_DFL, and System V (and
the Linux kernel and libc4,5) does the same. On the other hand, BSD does not reset
the handler, but blocks new instances of this signal from occurring during a call
of the handler. The glibc2 library follows the BSD behaviour.
If one on a libc5 system includes <bsd/signal.h> instead of <signal.h> then signal
is redefined as __bsd_signal and signal has the BSD semantics. This is not recom-
mended.
If one on a glibc2 system defines a feature test macro such as _XOPEN_SOURCE or
uses a separate sysv_signal function, one obtains classical behaviour. This is not
recommended.
Trying to change the semantics of this call using defines and includes is not a
good idea. It is better to avoid signal altogether, and use sigaction(2) instead.
NOTES
The effects of this call in a multi-threaded process are unspecified.
The routine handler must be very careful, since processing elsewhere was inter-
rupted at some arbitrary point. POSIX has the concept of "safe function". If a
signal interrupts an unsafe function, and handler calls an unsafe function, then
the behavior is undefined. Safe functions are listed explicitly in the various
standards. The POSIX 1003.1-2003 list is
_Exit() _exit() abort() accept() access() aio_error() aio_return() aio_suspend()
alarm() bind() cfgetispeed() cfgetospeed() cfsetispeed() cfsetospeed() chdir()
chmod() chown() clock_gettime() close() connect() creat() dup() dup2() execle()
execve() fchmod() fchown() fcntl() fdatasync() fork() fpathconf() fstat() fsync()
ftruncate() getegid() geteuid() getgid() getgroups() getpeername() getpgrp() get-
pid() getppid() getsockname() getsockopt() getuid() kill() link() listen() lseek()
lstat() mkdir() mkfifo() open() pathconf() pause() pipe() poll()
posix_trace_event() pselect() raise() read() readlink() recv() recvfrom() recvmsg()
rename() rmdir() select() sem_post() send() sendmsg() sendto() setgid() setpgid()
setsid() setsockopt() setuid() shutdown() sigaction() sigaddset() sigdelset()
sigemptyset() sigfillset() sigismember() signal() sigpause() sigpending() sigproc-
mask() sigqueue() sigset() sigsuspend() sleep() socket() socketpair() stat() sym-
link() sysconf() tcdrain() tcflow() tcflush() tcgetattr() tcgetpgrp() tcsendbreak()
tcsetattr() tcsetpgrp() time() timer_getoverrun() timer_gettime() timer_settime()
times() umask() uname() unlink() utime() wait() waitpid() write().
According to POSIX, the behaviour of a process is undefined after it ignores a
SIGFPE, SIGILL, or SIGSEGV signal that was not generated by the kill(2) or the
raise(3) functions. Integer division by zero has undefined result. On some archi-
tectures it will generate a SIGFPE signal. (Also dividing the most negative inte-
ger by -1 may generate SIGFPE.) Ignoring this signal might lead to an endless
loop.
According to POSIX (3.3.1.3) it is unspecified what happens when SIGCHLD is set to
SIG_IGN. Here the BSD and SYSV behaviours differ, causing BSD software that sets
the action for SIGCHLD to SIG_IGN to fail on Linux.
The use of sighandler_t is a GNU extension. Various versions of libc predefine
this type; libc4 and libc5 define SignalHandler, glibc defines sig_t and, when
_GNU_SOURCE is defined, also sighandler_t.
CONFORMING TO
ANSI C
SEE ALSO
kill(1), kill(2), killpg(2), pause(2), raise(3), sigaction(2), signal(7), sigse-
tops(3), sigvec(2), alarm(2)
Linux 2.2 2000-04-28 SIGNAL(2)
Generated by $Id: phpMan.php,v 4.55 2007/09/05 04:42:51 chedong Exp $ Author: Che Dong
On Apache/1.3.41 (Unix) PHP/5.2.5 mod_perl/1.30 mod_gzip/1.3.26.1a
Under GNU General Public License
2009-01-09 01:22 @38.103.63.58 CrawledBy CCBot/1.0 (+http://www.commoncrawl.org/bot.html)