signal

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

Ändert die Behandlung des Signals sig. Abhängig vom Wert von handler kann das Signal ignoriert, auf Standard gesetzt oder durch eine benutzerdefinierte Funktion behandelt werden, die als (*handler)(sig) aufgerufen wird.

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

Parameter

void fun(int sig);

Rückgabewert

Vorheriger Signalhandler bei Erfolg oder SIG_ERR bei Misserfolg (das Setzen eines Signalhandlers kann in manchen Implementierungen deaktiviert sein).

Signalhandler

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 Ergebnis 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 Signalhandler eine Funktion in der Standardbibliothek aufruft, außer

• abort
• _Exit
• quick_exit
• signal mit dem ersten Argument, das die Nummer des aktuell behandelten Signals ist (asynchroner Handler kann sich selbst, aber keine anderen Signale erneut registrieren).
• atomare Funktionen aus <stdatomic.h>, wenn die atomaren Argumente sperrfrei (lock-free) sind
• atomic_is_lock_free (mit beliebigen atomaren Argumenten)

• der Signalhandler auf ein Objekt mit statischer oder thread-lokaler(seit C11) Speicherdauer verweist, das nicht sperrfrei atomic(seit C11) ist, außer durch Zuweisung an ein statisches volatile sig_atomic_t.

Beim Eintritt in den Signalhandler ist der Zustand der Gleitkomma-Umgebung und die Werte aller Objekte unspezifiziert, mit Ausnahme von

• Objekten vom Typ volatile sig_atomic_t
• Objekten sperrfreier atomarer Typen (seit C11)
• sichtbaren Seiteneffekten durch atomic_signal_fence (seit C11)

Bei Rückkehr von einem Signalhandler ist der Wert jedes Objekts, das vom Signalhandler modifiziert wurde und nicht volatile sig_atomic_t oder sperrfrei atomar(seit C11) ist, undefiniert.

Das Verhalten ist undefiniert, wenn signal in einem Multithread-Programm verwendet wird. Es muss nicht threadsicher sein.

Anmerkungen

POSIX verlangt, dass signal threadsicher ist, und spezifiziert eine Liste asynchron-signalsicherer Bibliotheksfunktionen, die von jedem Signalhandler aus aufgerufen werden dürfen.

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

POSIX empfiehlt sigaction anstelle von signal, aufgrund seines unterspezifizierten Verhaltens und erheblicher Implementierungsunterschiede in Bezug auf die Signalzustellung, während ein Signalhandler ausgeführt wird.

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