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

Linux                                            19. April 2013                                        SIGNAL(2)