View Source: signal(2) - Waikato Linux Users Group

Edit PageHistory Diff Info LikePages
SIGNAL
!!!SIGNAL
NAME
SYNOPSIS
DESCRIPTION
RETURN VALUE
PORTABILITY
NOTES
CONFORMING TO
SEE ALSO
----
!!NAME


signal - ANSI C signal handling
!!SYNOPSIS


__#include __


__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 corresponding 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 the
signal is blocked and ''sighandler'' is called with
argument ''signum''. The signal remains blocked during
the execution of the signal handler.


Using a signal handler function for a signal is called
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.


In a libc5 system including ____
instead of ____ makes __signal__ to be
redefined as ____bsd_signal__ and signal has the BSD
semantics. This is not recommended.


In a glibc2 system defining a feature test macro such as
___XOPEN_SOURCE__ or using a separate __sysv_signal__
function, the classical behaviour is obtained. 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


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 architectures
it will generate a __SIGFPE__ signal. (Also dividing the
most negative integer 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 the __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), sigsetops(3), sigvec(2),
alarm(2)
----
25 pages link to signal(2):
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.
Last edited on Tuesday, June 4, 2002 12:23:47 am by "perry"
Edit PageHistory Diff Info LikePages