signal

Setzt den Fehlerbehandler für das Signal sig . Der Signalbehandler kann so eingestellt werden, dass entweder die Standardbehandlung erfolgt, das Signal ignoriert wird oder eine benutzerdefinierte Funktion aufgerufen wird.

Wenn ein Signal-Handler auf eine Funktion gesetzt wird und ein Signal auftritt, ist implementierungsdefiniert, ob signal ( sig, SIG_DFL ) unmittelbar vor dem Start des Signal-Handlers ausgeführt wird. Zudem kann die Implementierung verhindern, dass eine implementierungsdefinierte Menge von Signalen auftritt, während der Signal-Handler läuft.

Parameter

Rückgabewert

Vorheriger Signal-Handler bei Erfolg oder SIG_ERR bei Fehler (das Setzen eines Signal-Handlers kann auf einigen Implementierungen deaktiviert sein).

Signal-Handler

Die folgenden Einschränkungen gelten für die benutzerdefinierte Funktion, die als Signalhandler installiert wird.

Wenn die benutzerdefinierte Funktion bei der Behandlung von SIGFPE , SIGILL oder SIGSEGV zurückkehrt, ist das Verhalten undefiniert.

Wenn der Signalhandler als Folge von abort oder raise aufgerufen wird, ist das Verhalten undefiniert, wenn der Signalhandler raise aufruft.

Wenn der Signalhandler NICHT als Ergebnis von abort oder raise aufgerufen wird (mit anderen Worten, der Signalhandler ist asynchron ), ist das Verhalten undefiniert, wenn

• der Signal-Handler ruft eine beliebige Funktion innerhalb der Standardbibliothek auf, außer

• abort
• _Exit
• quick_exit
• signal mit dem ersten Argument als Nummer des aktuell behandelten Signals (asynchrone Handler können sich selbst erneut registrieren, aber keine anderen Signale).
• atomare Funktionen aus <stdatomic.h> falls die atomaren Argumente lock-free sind
• atomic_is_lock_free (mit beliebigen atomaren Argumenten)

• der Signal-Handler bezieht sich auf jedes Objekt mit statischer oder thread-lokaler (since C11) Speicherdauer , das kein lock-freies atomic (since C11) ist, außer durch Zuweisung zu einem statischen volatile sig_atomic_t .

Beim Eintritt in den Signal-Handler ist der Zustand der Gleitkomma-Umgebung und die Werte aller Objekte nicht spezifiziert, außer für

• Objekte vom Typ volatile sig_atomic_t
• Objekte von lock-freien atomaren Typen (seit C11)
• Nebeneffekte, sichtbar gemacht durch atomic_signal_fence (seit C11)

Bei Rückkehr von einem Signal-Handler ist der Wert jedes Objekts, das durch den Signal-Handler geändert wurde und nicht volatile sig_atomic_t oder lock-frei atomar (seit C11) ist, undefiniert.

Das Verhalten ist undefiniert, wenn signal in einem Multithread-Programm verwendet wird. Es ist nicht erforderlich, dass es thread-sicher ist.

Hinweise

POSIX erfordert, dass signal thread-sicher ist, und spezifiziert eine Liste von asynchron-signalsicheren Bibliotheksfunktionen , die von jedem Signal-Handler aufgerufen werden können.

Neben abort und raise legt POSIX fest, dass kill , pthread_kill und sigqueue synchrone Signale erzeugen.

POSIX empfiehlt sigaction anstelle von signal , aufgrund seines nicht ausreichend spezifizierten Verhaltens und erheblicher Implementierungsunterschiede bezüglich der Signalzustellung während der Ausführung eines Signal-Handlers.

Beispiel

#include <signal.h>
#include <stdio.h>
volatile sig_atomic_t gSignalStatus;
void signal_handler(int signal)
{
  gSignalStatus = signal;
}
int main(void)
{
  signal(SIGINT, signal_handler);
  printf("SignalValue: %d\n", gSignalStatus);
  printf("Sending signal: %d\n", SIGINT);
  raise(SIGINT);
  printf("SignalValue: %d\n", gSignalStatus);
}

SignalValue: 0
Sending signal: 2
SignalValue: 2

Referenzen

Siehe auch