signal(2) - phpMan

Command: man perldoc info search(apropos)  

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  behavior of signal() varies across Unix versions, and has also varied histori-
       cally across different versions of Linux.  Avoid its use: use sigaction(2) instead.
       See Portability below.

       signal()  sets  the  disposition  of  the signal signum to handler, which is either
       SIG_IGN, SIG_DFL, or the address of a programmer-defined function (a  "signal  han-

       If  the  signal  signum is delivered to the process, then one of the following hap-

       *  If the disposition is set to SIG_IGN, then the signal is ignored.

       *  If the disposition is set to SIG_DFL, then the default  action  associated  with
          the signal (see signal(7)) occurs.

       *  If  the  disposition  is set to a function, then first either the disposition is
          reset to SIG_DFL, or the signal is blocked (see  Portability  below),  and  then
          handler is called with argument signum.  If invocation of the handler caused the
          signal to be blocked, then the signal is unblocked upon return from the handler.

       The signals SIGKILL and SIGSTOP cannot be caught or ignored.

       signal() returns the previous value of the signal handler, or SIG_ERR on error.

       EINVAL signum is invalid.

       C89, C99, POSIX.1-2001.

       The effects of signal() in a multithreaded process are unspecified.

       According  to  POSIX,  the  behavior  of  a process is undefined after it ignores a
       SIGFPE, SIGILL, or SIGSEGV signal that was not generated by  kill(2)  or  raise(3).
       Integer  division by zero has undefined result.  On some architectures it will gen-
       erate a SIGFPE signal.  (Also dividing the most negative integer by -1 may generate
       SIGFPE.)  Ignoring this signal might lead to an endless loop.

       See sigaction(2) for details on what happens when SIGCHLD is set to SIG_IGN.

       See  signal(7)  for  a  list  of the async-signal-safe functions that can be safely
       called from inside a signal handler.

       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.  Without use of such a type, the  decla-
       ration of signal() is the somewhat harder to read:

           void ( *signal(int signum, void (*handler)(int)) ) (int);

       The  only  portable  use of signal() is to set a signal's disposition to SIG_DFL or
       SIG_IGN.  The semantics when using signal() to  establish  a  signal  handler  vary
       across  systems  (and POSIX.1 explicitly permits this variation); do not use it for
       this purpose.

       POSIX.1 solved the portability mess  by  specifying  sigaction(2),  which  provides
       explicit control of the semantics when a signal handler is invoked; use that inter-
       face instead of signal().

       In the original Unix systems, when a handler that was  established  using  signal()
       was  invoked  by  the  delivery of a signal, the disposition of the signal would be
       reset to SIG_DFL, and the system did not block delivery of further instances of the
       signal.  System V also provides these semantics for signal().  This was bad because
       the signal might be delivered again before the handler had a chance to  reestablish
       itself.  Furthermore, rapid deliveries of the same signal could result in recursive
       invocations of the handler.

       BSD improved on this situation by changing the semantics of signal  handling  (but,
       unfortunately, silently changed the semantics when establishing a handler with sig-
       nal()).  On BSD, when a signal handler is invoked, the signal  disposition  is  not
       reset,  and  further instances of the signal are blocked from being delivered while
       the handler is executing.

       The situation on Linux is as follows:

       * The kernel's signal() system call provides System V semantics.

       * By default, in glibc 2 and later, the signal() wrapper function does  not  invoke
         the  kernel  system call.  Instead, it calls sigaction(2) using flags that supply
         BSD semantics.  This default behavior is provided as long as the _BSD_SOURCE fea-
         ture  test  macro  is  defined.   By  default, _BSD_SOURCE is defined; it is also
         implicitly defined if one defines _GNU_SOURCE, and can of  course  be  explicitly

         On  glibc 2 and later, if the _BSD_SOURCE feature test macro is not defined, then
         signal() provides System  V  semantics.   (The  default  implicit  definition  of
         _BSD_SOURCE  is  not  provided if one invokes gcc(1) in one of its standard modes
         (-std=xxx or -ansi)  or  defines  various  other  feature  test  macros  such  as
         _POSIX_SOURCE, _XOPEN_SOURCE, or _SVID_SOURCE; see feature_test_macros(7).)

       * The  signal()  function  in Linux libc4 and libc5 provide System V semantics.  If
         one on a libc5 system includes <bsd/signal.h> instead of  <signal.h>,  then  sig-
         nal() provides BSD semantics.

       kill(1),  alarm(2),  kill(2),  killpg(2), pause(2), sigaction(2), signalfd(2), sig-
       pending(2), sigprocmask(2), sigqueue(2),  sigsuspend(2),  bsd_signal(3),  raise(3),
       siginterrupt(3),  sigsetops(3),  sigvec(3), sysv_signal(3), feature_test_macros(7),

       This page is part of release 3.22 of the Linux man-pages project.  A description of
       the  project, and information about reporting bugs, can be found at http://www.ker-

Linux                             2008-07-11                         SIGNAL(2)

Generated by $Id: phpMan.php,v 4.55 2007/09/05 04:42:51 chedong Exp $ Author: Che Dong
On Apache
Under GNU General Public License
2017-12-13 03:33 @ CrawledBy CCBot/2.0 (
Valid XHTML 1.0!Valid CSS!