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



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 han-
       dler  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.


RETURN VALUE
       The  signal()  function	returns the previous value of the signal han-
       dler, 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  instead of 
       then signal is redefined as __bsd_signal and signal has the BSD seman-
       tics. 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.


NOTES
       The effects of this call in a multi-threaded process are	 unspecified.

       The  routine  handler must be very careful, since processing elsewhere
       was interrupted at some arbitrary point.	 POSIX	has  the  concept  of
       "safe  function".  If a signal interrupts an unsafe function, and han-
       dler 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()	 con-
       nect()  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() lis-
       ten()  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() symlink() 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 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 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), sig-
       nal(7), sigsetops(3), sigvec(2), alarm(2)



Linux 2.2			  2000-04-28			    SIGNAL(2)