Dokumentation für das Protokollierungsmodul sagt das
Wenn Sie asynchrone Signalhandler mit dem Signalmodul implementieren, können Sie möglicherweise die Protokollierung nicht in solchen Handlern verwenden. Dies liegt daran, dass Sperrenimplementierungen im Threading-Modul nicht immer neu sind und daher nicht von solchen Signalbehandlungsroutinen aufgerufen werden können.
Dies deutet darauf hin, dass man keine Logging-Aufrufe von dem direkt oder indirekt vom Signal-Handler aufgerufenen Code vornehmen darf. Wenn du es ab und zu mal programmierst bleibt ein Zustand wenn nur kill -9 hilft.
Wichtige Frage für mich ist jetzt folgende. Kann dieses Sperrproblem auch auftreten, wenn andere Threads Protokollierungsmethoden zu dem Zeitpunkt aufrufen, wenn der Haupt-Thread ein Signal verarbeitet ?
?Signalhandler benötigen spezielle Handhabung in der UNIX-Programmierung überhaupt. Nur eine definierte Liste von POSIX C-Funktionen wird als reentrant deklariert und kann innerhalb eines POSIX-Signalhandlers aufgerufen werden. IEEE Std 1003.1 listet 118 Reentrant-UNIX-Funktionen auf, die Sie unter Ссылка finden (Anmeldung erforderlich).
Aber Python-Signale sind asynchron: Das Signalmodul hat eine Klarstellung:
Obwohl Python Signalhandler sind asynchron aufgerufen, soweit der Python-Benutzer ist betroffen, sie können nur zwischen dem "atomaren" auftreten Anweisungen des Python Dolmetscher. Dies bedeutet, dass Signale Ankunft während langer Berechnungen rein in C implementiert (wie z regulärer Ausdruck passt auf groß Textkörper) kann um einen beliebig viel Zeit.
In diesem Fall werden Signale in Python verschoben, bis die GIL frei ist.
Zurück zu Ihrer Frage. Nein , solange Sie wiederkehrende Funktionen innerhalb der Signalverarbeitungsfunktion verwenden. Wenn die Protokollierung nur in Threads verwendet wird, gibt es keine Probleme.
Die GIL (Global Interpreter Lock) verhindert, dass Python-Code zur gleichen Zeit ausgeführt wird. Daher kann der Haupt-Thread technisch gesehen kein Signal verarbeiten, während andere Threads ausgeführt werden. Es mag auf diese Weise "erscheinen", aber es gibt einen großen Mutex, der nur einen Python-Thread gleichzeitig laufen lässt.
Das Beste, was ich erraten kann, ist das Problem mit Signalen und Threading, dass ein Signal normalerweise durch einen Interrupt verursacht wird, der jederzeit passieren kann. Ich würde mir also vorstellen, dass Python aufhört zu tun und den Handler aufruft. Zu diesem Zeitpunkt ist möglicherweise bereits eine Sperre aktiviert, und wenn die Protokollierung versucht, erneut zu sperren, wird ein Deadlock ausgelöst. In einigen Implementierungen funktioniert das OK, weil der Mutex mehrfach gesperrt werden kann (Re-Entrant), während andere nur eine Sperre haben.
Hoffentlich kann jemand anderes dies bestätigen.