BEZEICHNUNG

       signal - Handhabung von Signalen in ANSI C

ÜBERSICHT

       #include <signal.h>

       typedef void (*sighandler_t)(int);

       sighandler_t signal(int signum, sighandler_t handler);

BESCHREIBUNG

       Das  Verhalten  von  signal()  unterscheidet  sich  zwischen  UNIX-Versionen  und hat sich
       historisch auch zwischen verschiedenen Linux-Versionen geändert. Vermeiden Sie den Einsatz
       dieser  Funktion  und  verwenden  Sie  stattdessen sigaction(2); siehe Portabilität weiter
       unten.

       signal() ordnet dem Signal signum den handler zu. Das ist entweder SIG_IGN,  SIG_DFL  oder
       die Adresse einer vom Programmierer definierten Funktion (eines »Signal Handlers«).

       Falls  dem  Prozess  das  Signal  signum  zugestellt  wird, wird einer der folgenden Fälle
       eintreten:

       *  Falls SIG_IGN zugewiesen wurde, wird das Signal ignoriert.

       *  Falls SIG_DFL zugewiesen wurde, wird die standardmäßig dem  Signal  zugewiesene  Aktion
          ausgeführt, wenn das Signal eintrift (siehe signal(7)).

       *  Falls  eine  Funktion  zugewiesen  wurde,  dann  wird zuerst entweder die Zuweisung auf
          SIG_DFL zurückgesetzt oder das Signal wird  blockiert  (siehe  Portability  unten)  und
          anschließend  handler mit dem Argument signum aufgerufen. Falls der Aufruf des Handlers
          ein Blockieren des Signals verursachte, wird die Blockade nach  der  Rückkehr  aus  dem
          Handler aufgehoben.

       Die Signale SIGKILL und SIGSTOP können nicht abgefangen oder ignoriert werden.

RÜCKGABEWERT

       signal()   returns  the  previous value of the signal handler, or SIG_ERR on error. In the
       event of an error, errno is set to indicate the cause.

FEHLER

       EINVAL signum ist ungültig.

KONFORM ZU

       C89, C99, POSIX.1-2001.

ANMERKUNGEN

       Die Auswirkungen von signal() in einem Multithread-Prozess sind nicht spezifiziert.

       Gemäß  POSIX  ist  das  Verhalten  eines  Prozesses  nicht  definiert,  nachdem   er   ein
       SIGFPE-Signal,  ein  SIGILL-Signal  oder  ein  SIGSEGVSignal,  das  nicht von kill(2) oder
       raise(3) erzeugt wurde, ignoriert. Eine Integer-Division durch Null hat ein  undefiniertes
       Ergebnis.  Auf  einigen  Architekturen wird die Division ein SIGFPE-Signal erzeugen. (Auch
       die Division der größten negativen Zahl durch -1 kann ein SIGFPE auslösen.) Ein Ignorieren
       dieses Signals könnte zu einer Endlosschleife führen.

       Siehe sigaction(2) für Einzelheiten des Geschehens, wenn SIGCHLD auf SIG_IGN gesetzt wird.

       Siehe signal(7) für eine Liste von Funktionen, die sicher mit asynchronen Signalen umgehen
       können und daher sicher aus einem Signal Handler heraus aufgerufen werden können.

       Die Verwendung von sighandler_t ist eine GNU-Erweiterung, die  durch  die  Definition  von
       _GNU_SOURCE  verfügbar  wird; Glibc definiert zusätzlich (das von BSD abgeleitete)  sig_t,
       wenn _BSD_SOURCE definiert wird. Ohne die Nutzung eines solches Typs ist  die  Deklaration
       von signal() etwas schwerer zu lesen:

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

   Portabilität
       Die einzige portable Verwendung von signal() ist die Zuweisung von SIG_DFL oder SIG_IGN zu
       einem Signal. Die Semantik bei der Einrichtung  eines  Signal  Handlers  mittels  signal()
       unterscheidet  sich  zwischen  Systemen (und POSIX.1 erlaubt diese Unterschiede explizit);
       verwenden Sie die Funktion nicht für diesen Zweck.

       POSIX.1 löste das Portabilitätschaos durch die Beschreibung  von  sigaction(2),  die  eine
       explizite  Kontrolle  der Semantik beim Aufruf eines Signal-Handlers ermöglicht; verwenden
       Sie diese Schnittstelle anstatt von 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. This is
       equivalent to calling sigaction(2)  with the following flags:

           sa.sa_flags = SA_RESETHAND | SA_NODEFER;

       Auch System V bietet diese Semantik für signal(). Das war schlecht, weil das Signal wieder
       eintreffen konnte, bevor der Signal Handler Gelegenheit hatte, sich  erneut  einzurichten.
       Darüber  hinaus  konnten schnell aufeinander folgende Zustellungen des gleichen Signals zu
       rekursiven Aufrufen des Handlers führen.

       BSD improved on this situation, but  unfortunately  also  changed  the  semantics  of  the
       existing signal()  interface while doing so. 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. Furthermore, certain blocking system calls
       are automatically restarted if interrupted by a signal handler (see  signal(7)).  The  BSD
       semantics are equivalent to calling sigaction(2)  with the following flags:

           sa.sa_flags = SA_RESTART;

       Die Situation unter Linux ist wie folgt:

       * Das signal()-System des Kernels stellt System-V-Semantik bereit.

       * Standardmäßig  nutzt  in  Glibc  2  und  später  die signal()-Wrapper-Funktion nicht den
         Kernel-Systemaufruf.  Stattdessen  ruft  sie  sigaction  (2)  mit  Flags   auf,   welche
         BSD-Semantik  bereitstellen.  Dieses  Standardverhalten  wird  so  lange bereitgestellt,
         solange das Feature-Test-Makro _BSD_SOURCE definiert ist. Standardmäßig ist  _BSD_SOURCE
         definiert.  Es  ist  auch  implizit definiert, wenn man _GNU_SOURCE definiert. Natürlich
         kann es auch explizit definiert werden.

         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 signal()  provides BSD
         semantics.

SIEHE AUCH

       kill(1), alarm(2), kill(2), killpg(2), pause(2), sigaction(2), signalfd(2), sigpending(2),
       sigprocmask(2),  sigsuspend(2),  bsd_signal(3),  raise(3),  siginterrupt(3),  sigqueue(3),
       sigsetops(3), sigvec(3), sysv_signal(3), signal(7)

KOLOPHON

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

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde  von  René  Tschirley  <gremlin@cs.tu-
       berlin.de>,    Martin    Schulze   <joey@infodrom.org>   und   Martin   Eberhard   Schauer
       <Martin.E.Schauer@gmx.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation;  lesen  Sie  die  GNU  General  Public  License
       Version   3  oder  neuer  bezüglich  der  Copyright-Bedingungen.  Es  wird  KEINE  HAFTUNG
       übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
       Mail an <debian-l10n-german@lists.debian.org>.