Home
Main website
Display Sidebar
Hide Ads
Recent Changes
View Source:
sgetmask(2)
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) ----
2 pages link to
sgetmask(2)
:
Man2s
syscalls(2)
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.
