signal

Legt die Verarbeitung des Unterbrechungssignals fest.

Wichtig

Verwenden Sie diese Methode nicht, um eine Microsoft Store-App herunterzufahren, mit Ausnahme von Test- oder Debuggingszenarien. Programmgesteuerte oder UI-Methoden zum Schließen einer Store-App sind gemäß den Microsoft Store-Richtlinien nicht zulässig. Weitere Informationen finden Sie im Lebenszyklus der UWP-App.

Syntax

void __cdecl *signal(int sig, int (*func)(int, int));

Parameter

sig
Signalwert.

func
Der zweite Parameter ist ein Zeiger auf die auszuführende Funktion. Der erste Parameter ist ein Signalwert, und der zweite Parameter ist ein Untercode, der verwendet werden kann, wenn der erste Parameter ist SIGFPE.

Rückgabewert

signal gibt den vorherigen Wert des Func zurück, der dem angegebenen Signal zugeordnet ist. Wenn der vorherige Wert von func beispielsweise SIG_IGN lautete, lautet auch der Rückgabewert SIG_IGN. Der Rückgabewert SIG_ERR gibt einen Fehler an. In diesem Fall wird errno auf EINVAL festgelegt.

Weitere Informationen zu Rückgabecodes finden Sie unter , , _doserrno, _sys_errlistund _sys_nerr.errno

Hinweise

Die signal-Funktion ermöglicht einem Prozess, eine von mehreren Methoden zur Verarbeitung eines Unterbrechungssignals vom Betriebssystem auszuwählen. Das sig Argument ist der Interrupt, auf den signal geantwortet wird; es muss eine der folgenden Manifestkonstanten sein, die definiert SIGNAL.Hsind.

Wert vom Typ sig	Beschreibung
SIGABRT	Nicht ordnungsgemäße Beendigung
SIGFPE	Gleitkommafehler
SIGILL	Ungültige Anweisung
SIGINT	STRG+C-Signal
SIGSEGV	Ungültiger Speicherzugriff
SIGTERM	Beendigungsanforderung

Wenn sig es sich nicht um einen der obigen Werte handelt, wird der ungültige Parameterhandler aufgerufen, wie in der Parameterüberprüfung definiert. Wenn die weitere Ausführung zugelassen wird, legt diese Funktion errno auf EINVAL fest und gibt SIG_ERR zurück.

Standardmäßig beendet signal das aufrufende Programm mit Exitcode 3, unabhängig vom Wert von sig.

Hinweis

SIGINT wird nicht für jede Win32-Anwendung unterstützt. Wenn es zu einer STRG+C-Unterbrechung kommt, generieren Win32-Betriebssysteme einen neuen Thread, um speziell diese Unterbrechung zu verarbeiten. Dies kann dazu führen, dass eine Singlethreadanwendung, z. B. eine Anwendung in UNIX, zu einer Multithreadanwendung wird und ein unerwartetes Verhalten verursacht.

Das func Argument ist eine Adresse für einen von Ihnen geschriebenen Signalhandler oder an eine der vordefinierten SignalaktionskonstantenSIG_DFL oder SIG_IGN, die auch in SIGNAL.H definiert sind. Wenn func es sich um eine Funktion handelt, wird sie als Signalhandler für das angegebene Signal installiert. Der Prototyp des Signalhandlers erfordert ein formales Argument, sig, vom Typ int. Das Betriebssystem stellt das tatsächliche Argument über sig bereit, wenn eine Unterbrechung auftritt. Das Argument ist das Signal, das die Unterbrechung generiert hat. Daher können Sie die sechs (in der vorangehenden Tabelle aufgeführten) Manifestkonstanten in Ihrem Signalhandler verwenden, um zu bestimmen, welche Unterbrechung aufgetreten ist, und entsprechende Maßnahmen ergreifen. Beispielsweise können Sie signal zweimal aufrufen, um zwei unterschiedlichen Signalen den gleichen Handler zuzuweisen, und dann das sig-Argument im Handler testen, um verschiedene Aktionen auf Grundlage des empfangenen Signals zu ergreifen.

Wenn Sie auf Gleitkomma-Ausnahmen (SIGFPE) testen, func verweist auf eine Funktion, die ein optionales zweites Argument verwendet, das eine von mehreren Manifestkonstanten ist, die in FLOAT.Hder Form FPE_xxxdefiniert sind. Wenn ein SIGFPE Signal auftritt, können Sie den Wert des zweiten Arguments testen, um die Art der Gleitkomma-Ausnahme zu ermitteln und dann geeignete Maßnahmen zu ergreifen. Dieses Argument und seine möglichen Werte sind Microsoft-Erweiterungen.

Bei Gleitkomma-Ausnahmen wird der Wert des func Werts nicht zurückgesetzt, wenn das Signal empfangen wird. Zur Behandlung von Gleitkommaausnahmen verwenden Sie try/except-Klauseln, um die Gleitkommaoperationen zu umschließen. Es ist auch möglich, mithilfe von setjmplongjmp. In beiden Fällen setzt der aufrufende Prozess die Ausführung fort und lässt den Gleitkommazustand des Prozesses undefiniert.

Wenn der Signalhandler zurückgibt, setzt der aufrufende Prozess die Ausführung unmittelbar nach dem Punkt fort, an dem es das Interruptsignal empfangen hat, unabhängig von der Art des Signals oder des Betriebsmodus.

Bevor die angegebene Funktion ausgeführt wird, wird der Wert von func auf SIG_DFL festgelegt. Das nächste Unterbrechungssignal wird wie für SIG_DFL beschrieben behandelt, sofern ein zwischenzeitlicher Aufruf von signal nichts anderes vorsieht. Sie können diese Funktion verwenden, um Signale in der aufgerufenen Funktion zurückzusetzen.

Da Signalhandlerroutinen häufig asynchron aufgerufen werden, wenn ein Interrupt auftritt, erhält die Signalhandlerfunktion möglicherweise die Steuerung, wenn ein Laufzeitvorgang unvollständig und in einem unbekannten Zustand ist. In der folgenden Liste sind die Einschränkungen zusammengefasst, die bestimmen, welche Funktionen Sie in der Signalhandlerroutine verwenden können.

• Geben Sie keine Low-Level- oder STDIO.H E/A-Routinen aus (zprintf. B. ).fread

• Rufen Sie keine Heaproutinen oder Routinen auf, mallocdie die Heap-Routinen (z. B. , , _strdupoder _putenv) verwenden. Weitere Informationen finden Sie unter malloc.

• Verwenden Sie keine Funktion, die einen Systemaufruf generiert (z _getcwd . B. oder time).

• Verwenden longjmp Sie dies nur, sigSIGFPEwenn der Interrupt durch eine Gleitkomma-Ausnahme verursacht wird (d. h. Initialisieren Sie in diesem Fall mithilfe eines Aufrufs von _fpreset zuerst das Gleitkommapaket neu.

• Verwenden Sie keine Überlagerungsroutinen.

Ein Programm muss Gleitkommacode enthalten, wenn er die SIGFPE Ausnahme mithilfe der Funktion abfangen soll. Wenn Ihr Programm keinen Gleitkommacode aufweist und den Signalbehandlungscode der Laufzeitbibliothek erfordert, deklarieren Sie einfach ein veränderliches Double, und initialisieren Sie ihn auf Null:

volatile double d = 0.0f;

Die SIGILL Signale werden SIGTERM unter Windows nicht generiert. Sie sind für die ANSI-Kompatibilität enthalten. Daher können Sie Signalhandler für diese Signale mithilfe signalvon Signalen festlegen, und Sie können diese Signale auch explizit durch Aufrufen raisegenerieren.

Signaleinstellungen bleiben in Spawned-Prozessen, die durch Aufrufe _exec oder _spawn Funktionen erstellt werden, nicht erhalten. Die Signaleinstellungen werden im neuen Prozess auf die Standardwerte zurückgesetzt.

Anforderungen

Routine	Erforderlicher Header
signal	<signal.h>

Weitere Informationen zur Kompatibilität finden Sie unter Kompatibilität.

Beispiel

Das folgende Beispiel zeigt, wie signal verwendet wird, um dem SIGABRT-Signal ein benutzerdefiniertes Verhalten hinzuzufügen. Weitere Informationen zum Abbruchverhalten finden Sie unter _set_abort_behavior.

// crt_signal.c
// compile with: /EHsc /W4
// Use signal to attach a signal handler to the abort routine
#include <stdlib.h>
#include <signal.h>

void SignalHandler(int signal)
{
    if (signal == SIGABRT) {
        // abort signal handler code
    } else {
        // ...
    }
}

int main()
{
    typedef void (*SignalHandlerPointer)(int);

    SignalHandlerPointer previousHandler;
    previousHandler = signal(SIGABRT, SignalHandler);

    abort();
}

Die Ausgabe hängt von der verwendeten Laufzeitversion ab, unabhängig davon, ob es sich bei der App um eine Konsole oder Windows-App und um Windows-Registrierungseinstellungen handelt. Bei einer Konsolen-App kann etwa die folgende Nachricht an stderr gesendet werden:

Debug Error!

Program: c:\Projects\crt_signal\Debug\crt_signal.exe

R6010

- abort() has been called

Siehe auch

Prozess- und Umgebungskontrolle
abort
_exec, _wexec Funktionen
exit, _Exit, _exit
_fpreset
_spawn, _wspawn Funktionen