Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

RedHat 9 (Linux i386) - man page for sgetmask (redhat section 2)

SIGNAL(2)			    Linux Programmer's Manual				SIGNAL(2)

       signal - ANSI C signal handling

       #include <signal.h>

       typedef void (*sighandler_t)(int);

       sighandler_t signal(int signum, sighandler_t handler);

       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 first either the handler is reset to  SIG_DFL
       or  an implementation-dependent blocking of the signal 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.

       The  signal()  function	returns  the  previous value of the signal handler, or SIG_ERR on

       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 recommended.

       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.

       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 ( 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.

       ANSI C

       kill(1), kill(2), killpg(2), pause(2), raise(3),  sigaction(2),	signal(7),  sigsetops(3),
       sigvec(2), alarm(2)

Linux 2.2				    2000-04-28					SIGNAL(2)

All times are GMT -4. The time now is 11:25 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password