Wie behandeln Sie das signal in python auf windows-Maschine

Python ' s os.kill umschließt zwei fremden auf dem Windows-APIs. Es fordert GenerateConsoleCtrlEvent, wenn die sig parameter ist CTRL_C_EVENT oder CTRL_BREAK_EVENT. In diesem Fall ist der pid parameter eine Prozess-Gruppen-ID. Wenn dieser Aufruf fehlschlägt, und für alle anderen sig Werte, ruft OpenProcess und dann TerminateProcess. In diesem Fall ist der pid parameter eine Prozess-ID, und die sig Wert übergeben wird, wird als exit-code. Beenden einer Windows-Prozess ist vergleichbar mit dem senden SIGKILL zu einem POSIX-Prozess. In der Regel sollte dies vermieden werden, da es sich nicht erlauben, den Prozess zu beenden sauber.

Beachten Sie, dass die Dokumente für os.kill fälschlicherweise behaupten, dass "kill() außerdem dauert der Prozess behandelt, getötet zu werden", das war nie wahr. Es fordert OpenProcess um einen Prozess handle.

Die Entscheidung über die WinAPI CTRL_C_EVENT und CTRL_BREAK_EVENT statt SIGINT und SIGBREAK ist schade für cross-Plattform-code. Es ist auch nicht definiert, was GenerateConsoleCtrlEvent tut, wenn Sie übergeben eine Prozess-ID, das ist nicht ein Prozess-Gruppen-ID. Mit dieser Funktion in eine API, die eine Prozess-ID ist bedenklich am besten, und potenziell sehr falsch.

Für Ihre Bedürfnisse zu finden Sie können schreiben, eine adapter-Funktion macht os.kill etwas freundlicher für cross-Plattform-code. Zum Beispiel:

import os
import sys
import time
import signal

if sys.platform != 'win32':
    kill = os.kill
    sleep = time.sleep
else: 
    # adapt the conflated API on Windows.
    import threading

    sigmap = {signal.SIGINT: signal.CTRL_C_EVENT,
              signal.SIGBREAK: signal.CTRL_BREAK_EVENT}

    def kill(pid, signum):
        if signum in sigmap and pid == os.getpid():
            # we don't know if the current process is a
            # process group leader, so just broadcast
            # to all processes attached to this console.
            pid = 0
        thread = threading.current_thread()
        handler = signal.getsignal(signum)
        # work around the synchronization problem when calling
        # kill from the main thread.
        if (signum in sigmap and
            thread.name == 'MainThread' and
            callable(handler) and
            pid == 0):
            event = threading.Event()
            def handler_set_event(signum, frame):
                event.set()
                return handler(signum, frame)
            signal.signal(signum, handler_set_event)                
            try:
                os.kill(pid, sigmap[signum])
                # busy wait because we can't block in the main
                # thread, else the signal handler can't execute.
                while not event.is_set():
                    pass
            finally:
                signal.signal(signum, handler)
        else:
            os.kill(pid, sigmap.get(signum, signum))

    if sys.version_info[0] > 2:
        sleep = time.sleep
    else:
        import errno

        # If the signal handler doesn't raise an exception,
        # time.sleep in Python 2 raises an EINTR IOError, but
        # Python 3 just resumes the sleep.

        def sleep(interval):
            '''sleep that ignores EINTR in 2.x on Windows'''
            while True:
                try:
                    t = time.time()
                    time.sleep(interval)
                except IOError as e:
                    if e.errno != errno.EINTR:
                        raise
                interval -= time.time() - t
                if interval <= 0:
                    break

def func(signum, frame):
    # note: don't print in a signal handler.
    global g_sigint
    g_sigint = True
    #raise KeyboardInterrupt

signal.signal(signal.SIGINT, func)

g_kill = False
while True:
    g_sigint = False
    g_kill = not g_kill
    print('Running [%d]' % os.getpid())
    sleep(2)
    if g_kill:
        kill(os.getpid(), signal.SIGINT)
    if g_sigint:
        print('SIGINT')
    else:
        print('No SIGINT')

Diskussion

Windows nicht implementieren Signale an die system-Ebene [*]. Microsoft C runtime implementiert die sechs Signale, die erforderlich sind, durch standard-C: SIGINT, SIGABRT, SIGTERM, SIGSEGV, SIGILL, und SIGFPE.

SIGABRT und SIGTERM implementiert sind nur für den aktuellen Prozess. Sie können rufen Sie die handler über C raise. Zum Beispiel (in Python 3.5):

>>> import signal, ctypes
>>> ucrtbase = ctypes.CDLL('ucrtbase')
>>> c_raise = ucrtbase['raise']
>>> foo = lambda *a: print('foo')
>>> signal.signal(signal.SIGTERM, foo)
<Handlers.SIG_DFL: 0>
>>> c_raise(signal.SIGTERM)
foo
0

SIGTERM ist nutzlos.

Können Sie auch nicht viel mit SIGABRT mit dem signal-Modul, weil die Abbrechen Funktion tötet den Prozess, sobald der handler zurückkehrt, passiert das sofort, wenn mit dem signal-Modul die interne handler (es Reisen ein flag für die eingetragene Python aufrufbar aufgerufen werden, in dem Haupt-thread). Für Python 3 können Sie stattdessen die faulthandler Modul. Oder rufen Sie die CRT ' s signal Funktion über ctypes um eine ctypes callback als handler.

CRT implementiert SIGSEGV, SIGILL, und SIGFPE durch setzen eines Windows structured exception handler für die entsprechende Windows-Ausnahmen:

STATUS_ACCESS_VIOLATION          SIGSEGV
STATUS_ILLEGAL_INSTRUCTION       SIGILL
STATUS_PRIVILEGED_INSTRUCTION    SIGILL
STATUS_FLOAT_DENORMAL_OPERAND    SIGFPE
STATUS_FLOAT_DIVIDE_BY_ZERO      SIGFPE
STATUS_FLOAT_INEXACT_RESULT      SIGFPE
STATUS_FLOAT_INVALID_OPERATION   SIGFPE
STATUS_FLOAT_OVERFLOW            SIGFPE
STATUS_FLOAT_STACK_CHECK         SIGFPE
STATUS_FLOAT_UNDERFLOW           SIGFPE
STATUS_FLOAT_MULTIPLE_FAULTS     SIGFPE
STATUS_FLOAT_MULTIPLE_TRAPS      SIGFPE

Dem CRT Umsetzung dieser Signale ist nicht kompatibel mit Python-signal handling. Der Ausnahme-filter ruft die registrierten handler und kehrt dann EXCEPTION_CONTINUE_EXECUTION. Jedoch, Python-handler nur Reisen, eine Flagge für den Interpreten zu nennen, die eingetragene callable irgendwann später in der Haupt-thread. Also den fehlerhaften code, der die Ausnahme ausgelöst wird weiter auslösen in einer endlos-Schleife. In Python 3 können Sie den faulthandler-Modul für diese Ausnahme-basierte Signale.

Dass Blätter SIGINT, um die Windows-fügt die nicht-standard -SIGBREAK. Beide Konsole und nicht Konsole Prozesse können raise diese Signale, aber nur eine Konsole verarbeiten kann, erhalten Sie von einem anderen Prozess. Die CRT implementiert dies durch die Registrierung, die Kontrolle über eine Konsole event-handler über SetConsoleCtrlHandler.

Die Konsole sendet ein control-Ereignis durch erstellen eines neuen Threads in einem beigefügten Prozess, der mit der Ausführung beginnt bei CtrlRoutine im kernel32.dll oder kernelbase.dll (ohne Papiere). Dass der handler nicht ausgeführt wird auf dem Haupt-thread kann dazu führen, Probleme bei der Synchronisierung (z.B. in der REPL oder mit input). Auch ein control-Ereignis wird nicht unterbrechen Sie den Haupt-thread, wenn es blockiert beim warten auf ein synchronisationsobjekt warten oder synchroner I/O abgeschlossen ist. Pflege muss getroffen werden, um zu vermeiden, Blockierung der Haupt-thread, wenn es sein sollte, unterbrochen durch SIGINT. Python 3 versuche um dies zu umgehen, indem Sie einen Windows-Ereignis-Objekt, das kann auch verwendet werden, in wartet, der sollte unterbrechbar durch SIGINT.

Wenn die Konsole sendet der Prozess eine CTRL_C_EVENT oder CTRL_BREAK_EVENT, die CRT-handler ruft die registrierten SIGINT oder SIGBREAK handler, beziehungsweise. Die SIGBREAK - handler wird auch als für die CTRL_CLOSE_EVENT dass die Konsole sendet, wenn das Fenster geschlossen ist. Python standardmäßig Umgang SIGINT durch rasing eine KeyboardInterrupt im Haupt-thread. Allerdings SIGBREAK ist zunächst die Standard - CTRL_BREAK_EVENT handler, welche Anrufe ExitProcess(STATUS_CONTROL_C_EXIT).

Können Sie senden ein control-Ereignis für alle Prozesse an die aktuelle Konsole über GenerateConsoleCtrlEvent. Dies kann Ziel einer Teilmenge der Prozesse, die gehören zu einer Gruppe Prozess oder das Ziel der Gruppe 0 um das Ereignis zu senden, um alle Prozesse an die aktuelle Konsole.

Prozess-Gruppen sind nicht gut dokumentiert Aspekt des Windows-API. Es gibt keine öffentliche API zur Abfrage der Gruppe von einem Prozess, aber jeder Prozess in einer Windows-Sitzung gehört zu einer Prozessgruppe, auch wenn es nur die wininit.exe group (services-Sitzung) oder winlogon.exe Gruppe (interaktive Sitzung). Eine neue Gruppe wird erstellt, indem die Schaffung Flagge CREATE_NEW_PROCESS_GROUP beim erstellen eines neuen Prozesses. Die Gruppen-ID ist die Prozess-ID des erzeugten Prozesses. Meines Wissens, ist die Konsole das einzige system, das verwendet die Prozess-Gruppe, und das ist nur für GenerateConsoleCtrlEvent.

Was die Konsole macht, wenn die Ziel-ID ist nicht ein Prozess-Gruppen-ID ist nicht definiert und sollte nicht herangezogen werden. Wenn sowohl der Prozess und seine übergeordneten Prozess sind an der Konsole, schickt es dann ein control-Ereignis im Grunde wirkt wie das Ziel der Gruppe 0. Wenn der übergeordnete Prozess nicht an die aktuelle Konsole, dann GenerateConsoleCtrlEvent schlägt fehl, und die os.kill Anrufe TerminateProcess. Komischerweise, wenn Sie als Ziel "System" - Prozess (PID 4) - und seine Kind-Prozess smss.exe (session manager), wird der Anruf erfolgreich ausgeführt, aber es passiert nichts, ausser, dass das Ziel versehentlich Hinzugefügt, um die Liste der angeschlossenen Prozesse (z.B. GetConsoleProcessList). Es ist wahrscheinlich, weil der übergeordnete Prozess ist die "Leerlauf" - Verfahren, das, seit es PID 0, wird implizit angenommen, da die broadcast-PGID. Die übergeordnete Prozess-Regel gilt auch für nicht-Konsole-Prozesse. Auf einer nicht-Konsole-Kind-Prozess tut nichts-außer versehentlich beschädigt die Konsole Prozess-Liste, indem die angefügten Prozess. Ich hoffe, es ist klar, dass Sie sollten nur senden ein control-Ereignis entweder der Gruppe 0 oder eine bekannt - Prozess-Gruppe, die Sie erstellt haben, über CREATE_NEW_PROCESS_GROUP.

Verlassen Sie sich nicht auf die in der Lage zu senden CTRL_C_EVENT nichts aber die Gruppe 0, da es zunächst deaktiviert, in eine neue Prozess-Gruppe. Es ist nicht unmöglich, schicken Sie diese Veranstaltung, um eine neue Gruppe, aber das Ziel-Prozess zuerst aktivieren muss CTRL_C_EVENT durch den Aufruf SetConsoleCtrlHandler(NULL, FALSE).

CTRL_BREAK_EVENT ist alles, was Sie sich verlassen können, denn es kann nicht deaktiviert werden. Das senden dieser Veranstaltung ist eine einfache Möglichkeit, würdevoll zu töten, ein Kind-Prozess gestartet wurde mit CREATE_NEW_PROCESS_GROUP, vorausgesetzt, es hat eine Windows CTRL_BREAK_EVENT oder C SIGBREAK handler. Wenn nicht, wird der default-handler wird den Prozess zu beenden, Einstellung der exit-code STATUS_CONTROL_C_EXIT. Zum Beispiel:

>>> import os, signal, subprocess
>>> p = subprocess.Popen('python.exe',
...         stdin=subprocess.PIPE,
...         creationflags=subprocess.CREATE_NEW_PROCESS_GROUP)
>>> os.kill(p.pid, signal.CTRL_BREAK_EVENT)
>>> STATUS_CONTROL_C_EXIT = 0xC000013A
>>> p.wait() == STATUS_CONTROL_C_EXIT
True

Beachten Sie, dass CTRL_BREAK_EVENT war nicht geschickt, um den aktuellen Prozess, weil das Beispiel Ziele der Gruppe Prozess der Kind-Prozess (einschließlich aller seiner Kind-Prozesse an der Konsole, und so weiter). Wenn das Beispiel verwendet hatten, der Gruppe 0, den aktuellen Prozess hätte auch getötet, da ich nicht definieren SIGBREAK handler. Lassen Sie uns versuchen, aber mit einem hf-set:

>>> ctrl_break = lambda *a: print('^BREAK')
>>> signal.signal(signal.SIGBREAK, ctrl_break)
<Handlers.SIG_DFL: 0>
>>> os.kill(0, signal.CTRL_BREAK_EVENT)
^BREAK

[*]

Windows hat asynchrone Prozeduraufrufe (APC) in die Warteschlange ein Ziel-Funktion, um einen thread. Siehe den Artikel Innen-NT ist eine Asynchrone Prozedur-Aufruf für eine in-depth-Analyse von Windows APCs, insbesondere zur Klärung der Rolle der kernel-mode APCs. Sie können in die Warteschlange ein user-mode APC, um einen thread über QueueUserAPC. Sie bekommen auch in der Warteschlange von ReadFileEx und WriteFileEx für die I/O completion-routine.

Ein user-mode APC ausgeführt wird, wenn der thread gibt eine warnbare wartet (z.B. WaitForSingleObjectEx oder SleepEx mit bAlertable als TRUE). Kernel-mode APCs, auf der anderen Seite erhalten, Versand sofort (wenn der IRQL unten APC_LEVEL). Sie sind in der Regel verwendet, durch die I/O-manager, um vollständige asynchrone I/O-Request-Pakete im Kontext des thread, der die Anforderung ausgegeben hat (z.B. kopieren von Daten aus dem IRP, um eine Benutzer-Modus-Puffer). Sehen Wartet und APCs für eine Tabelle, die zeigt, wie die APCs beeinflussen warnbare und nicht-warnbare wartet. Beachten Sie, dass die kernel-mode APCs unterbrechen Sie nicht warten, sondern ausgeführt werden intern durch die wait-routine.

Windows umsetzen konnte POSIX-ähnliche Signale mit Hilfe von APCs, aber in der Praxis nutzt andere Mittel für den gleichen enden. Zum Beispiel:

• Structured Exception Handling, z.B. __try, __außer, __endlich, __leave, RaiseException, AddVectoredExceptionHandler.

• Kernel Dispatcher-Objekte (d.h. Synchronisierung Von Objekten), z.B. SetEvent, SetWaitableTimer.

• Fenster Nachrichten, z.B. SendMessage (ein-Fenster-Verfahren), PostMessage (zu einem thread eine Nachrichtenwarteschlange geschickt werden, um eine window-Prozedur), PostThreadMessage (zu einem thread-message-queue), WM_CLOSE, WM_TIMER.

Fenster Nachrichten gesendet werden können, und veröffentlicht für alle threads, die den Aufruf thread ' s desktop und sind bei gleicher oder niedriger Integritätsstufe. Senden Sie ein Fenster mit der Meldung heißt es in einer system-queue aufrufen, um die Fensterprozedur, wenn der thread ruft PeekMessage oder GetMessage. Eine Nachricht Hinzugefügt, um die thread-message-queue, die ein Kontingent von 10.000 Nachrichten. Einen thread mit message queue sollte eine message-Schleife zum verarbeiten der Warteschlange über GetMessage und DispatchMessage. Threads in einem nur für die Konsole Prozess in der Regel nicht über eine message queue. Jedoch die Konsolen-host-Prozess, conhost.exe offensichtlich tut. Wenn die schließen-Schaltfläche geklickt wird, oder wenn der primäre Prozess der Konsole getötet wird über den task-manager oder taskkill.exe, ein WM_CLOSE Nachricht gesendet, um die Nachrichten-queue der Konsole-Fenster-thread ist. Die Konsole schaltet sendet eine CTRL_CLOSE_EVENT alle angeschlossenen Prozesse. Wenn ein Prozess das Ereignis behandelt, es gab 5 Sekunden, um würdevoll beenden, bevor es gewaltsam beendet.