signal

Legt die Verarbeitung des Unterbrechungssignals fest.

Wichtig

Verwenden Sie diese Methode nicht zum Herunterfahren einer Microsoft Store-App, außer in Test- oder Debugszenarien. Programmgesteuerte oder Benutzeroberflächen-Methoden zum Schließen einer Store-App sind gemäß den Richtlinien Microsoft Store zulässig. Weitere Informationen finden Sie unter Lebenszyklus von UWP-Apps.

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 von 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 errnoInformationen zu _doserrnoRückgabecodes _sys_errlistfinden Sie _sys_nerr unter , , und .

Bemerkungen

Die signal-Funktion ermöglicht einem Prozess, eine von mehreren Methoden zur Verarbeitung eines Unterbrechungssignals vom Betriebssystem auszuwählen. Das Argument ist der Interrupt, auf signal den reagiert. Es sig muss eine der folgenden Manifestkonst constants sein, die in definiert sindSIGNAL.H.

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 keinem der oben genannten Werte entspricht, wird der Handler für ungültige Parameter aufgerufen, wie in Parameter Validation (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 eines von Ihnen geschriebenen Signalhandlers oder einer der vordefinierten Konstanten SIG_DFL oder SIG_IGN, die auch in SIGNAL.H. definiert sind. Wenn func eine Funktion ist, 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 Gleitkommaausnahmen (SIGFPE) testen, func zeigt auf eine Funktion, die ein optionales zweites Argument verwendet, bei dem es sich um eine von mehreren Manifestkonst konstanten handelt, die in FLOAT.Hder Form definiert sind FPE_xxx. Wenn ein SIGFPE-Signal auftritt, können Sie den Wert des zweiten Arguments testen, um die Art der Gleitkommaausnahme zu bestimmen. Anschließend können Sie entsprechende Maßnahmen ergreifen. Dieses Argument und seine möglichen Werte sind Microsoft-Erweiterungen.

Für Gleitkommaausnahmen wird der Wert von func 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, die Wiederherstellung mithilfe von setjmp zu ermöglichen longjmp. 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 sofort fort, und zwar von dem Punkt aus, an dem das Unterbrechungssignal empfangen wurde. Dies gilt 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 im Fall einer Unterbrechung normalerweise asynchron aufgerufen werden, kann Ihre Signalhandlerfunktion möglicherweise die Kontrolle übernehmen, wenn ein Laufzeitvorgang unvollständig ist und einen unbekannten Status aufweist. In der folgenden Liste sind die Einschränkungen zusammengefasst, die bestimmen, welche Funktionen Sie in der Signalhandlerroutine verwenden können.

  • Geben Sie keine Routinen auf niedriger Ebene STDIO.H oder E/A-Routinen aus (z. B. printf oder fread).

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

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

  • Verwenden Sie longjmp nicht, es sei denn, die Unterbrechung wurde durch eine Gleitkommaausnahme verursacht (d. h. sig entspricht SIGFPE). Initialisieren Sie in diesem Fall mithilfe eines Aufrufs von _fpreset zuerst das Gleitkommapaket neu.

  • Verwenden Sie keine Overlayroutinen.

Ein Programm muss Gleitkommacode enthalten, wenn er die SIGFPE-Ausnahme mithilfe der Funktion abfangen soll. Wenn Ihr Programm keinen Gleitkommacode enthält und den Signalverarbeitungscode der Laufzeitbibliothek erfordert, deklarieren Sie einfach ein flüchtiges Double und initialisieren Sie es mit Null:

volatile double d = 0.0f;

Die Signale SIGILL und SIGTERM werden unter Windows nicht generiert. Sie sind zur Gewährleistung der ANSI-Kompatibilität enthalten. Daher können Sie Signalhandler für signaldiese Signale mit festlegen, und Sie können diese Signale auch explizit generieren, indem Sie aufrufen raise.

In gestarteten Prozessen, die durch Aufrufe der Funktion _exec oder _spawn erstellt werden, werden Signaleinstellungen nicht beibehalten. Die Signaleinstellungen werden im neuen Prozess auf die Standardwerte zurückgesetzt.

Anforderungen

-Routine zurückgegebener Wert Erforderlicher Header
signal <signal.h>

Zusätzliche Informationen zur Kompatibilität finden Sie unter Compatibility.

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 Runtimeversion ab, davon, ob es sich bei der App um eine Konsole oder eine Windows handelt, und von Windows Registrierungseinstellungen. Für eine Konsolen-App kann etwa die folgende Meldung an stderr gesendet werden:

Debug Error!

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

R6010

- abort() has been called

Siehe auch

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