gestori di segnale e la registrazione in Python

Question

Documentation for logging module dice che

Se si implementa gestori di segnali asincroni che utilizzano il modulo di segnalazione, non si può essere in grado di utilizzare la registrazione dall'interno di tali gestori. Questo perché le implementazioni di blocco nel modulo di threading non sono sempre rientranti e quindi non possono essere richiamate da tali gestori di segnale.

Questo suggerisce che non si dovrebbero effettuare chiamate di registrazione dal codice invocato dal gestore di segnale direttamente o indirettamente. Se lo fai una volta ogni tanto il programma rimane uno stato quando solo kill -9 aiuta.

La domanda importante per me ora è la seguente. Questo problema di blocco può verificarsi anche quando gli altri thread chiamano i metodi di registrazione nel momento in cui il thread principale sta elaborando un segnale?

Answer 1

I gestori di segnale necessitano di una gestione speciale nella programmazione UNIX. Solo un elenco definito di funzioni POSIX C viene dichiarato come rientranti e può essere chiamato all'interno di un gestore di segnale POSIX. IEEE Std 1003.1 elenca 118 funzioni UNIX rientranti che si trovano a https://www.opengroup.org/ (login richiesto).

segnali

Ma Python sono asincroni: Il signal module hanno una precisazione:

Sebbene Python gestori di segnale sono chiamati asincrono quanto l'utente Python è interessato, possono avvenire solo tra il “atomico” istruzioni dell'interprete Python . Ciò significa che i segnali che arrivano durante i calcoli lunghi implementati esclusivamente in C (come le corrispondenze di espressioni regolari su grandi corpi di testo ) possono essere ritardati per un intervallo di tempo arbitrario.

In questo caso, i segnali in Python sono rinviate fino GIL è libera.

Torna alla tua domanda. No, a patto che si utilizzino le funzioni di rientro all'interno della funzione di elaborazione del segnale. Se la registrazione viene utilizzata solo nei thread, non ci saranno problemi.

Answer 2

Il GIL (Global Interpreter Lock) impedisce l'esecuzione di qualsiasi codice Python allo stesso tempo, quindi tecnicamente il thread principale non può elaborare un segnale mentre altri thread sono in esecuzione. Può "apparire" in questo modo, ma esiste un grande mutex che consente di eseguire un solo thread Python alla volta.

Il meglio che posso immaginare, il problema con i segnali e il threading è che un segnale è normalmente causato da un interrupt che può verificarsi in qualsiasi momento. Quindi immagino che Python interrompa ciò che sta facendo e chiama il gestore. A questo punto potrebbe essere già stato acquisito un blocco e quindi se la registrazione tenta di bloccarsi di nuovo, si ottiene un deadlock. In alcune implementazioni questo funziona bene perché il mutex può essere bloccato più volte (ri-entrante) ma altri c'è solo un lucchetto.

Speriamo che qualcun altro possa eseguire il backup.