Los manejadores de señales y la tala en Python

Question

Documentation for logging module dice que

Si va a implementar manejadores de señales asíncronas utilizando el módulo de señales, que no puede ser capaz de utilizar el registro desde el interior de dichos controladores. Esto se debe a que las implementaciones de bloqueo en el módulo de subprocesamiento no siempre son reentrantes, por lo que no pueden invocarse desde dichos manejadores de señal.

Esto sugiere que no se deben realizar llamadas desde el código invocado por el manejador de señal directa o indirectamente. Si lo haces de vez en cuando, el programa que quedará es un estado en el que solo kill -9 ayuda.

Pregunta importante para mí ahora sigue. ¿Puede este problema de bloqueo también ocurrir cuando otros hilos llaman a los métodos de registro en el momento en que el hilo principal está procesando una señal?

Answer 1

Los controladores de señales necesitan un manejo especial en la programación de UNIX. Solo una lista definida de funciones POSIX C se declara como reentrante y se puede llamar dentro de un manejador de señal POSIX. IEEE Std 1003.1 enumera 118 funciones UNIX reentrantes que se encuentran en https://www.opengroup.org/ (se requiere iniciar sesión).

señales

pero Python son asíncronas: El signal module tienen una aclaración:

Aunque los gestores de señales de Python se denominan de forma asíncrona en lo que concierne al usuario Python, que puede sólo se producen entre el “atómica” instrucciones del intérprete de Python . Esto significa que las señales que llegan durante los cálculos largos implementados puramente en C (como coincidencias de expresiones regulares en grandes cuerpos de texto ) pueden retrasarse durante un tiempo arbitrario .

En este caso, las señales en Python se posponen hasta que el GIL es libre.

Volver a tu pregunta. No, siempre que utilice funciones de reentrada dentro de la función de procesamiento de señal. Si el registro se usa solo en hilos, no habrá problemas.

Answer 2

El GIL (Global Interpreter Lock) impide que se ejecute cualquier código de Python al mismo tiempo, por lo que técnicamente el hilo principal no puede procesar una señal mientras se están ejecutando otros hilos. Puede "aparecer" de esa manera, pero hay un gran mutex que solo permite que se ejecute un subproceso de python a la vez.

Lo mejor que puedo adivinar, el problema con las señales y el enhebrado es que una señal normalmente es causada por una interrupción que puede ocurrir en cualquier momento. Entonces me imagino que Python detiene lo que está haciendo y llama al controlador. En este punto, es posible que ya se haya adquirido un bloqueo y, si el registro intenta volver a bloquearlo, se produce un punto muerto. En algunas implementaciones, esto funciona bien porque el mutex se puede bloquear varias veces (reentrantes) pero otros solo tienen un bloqueo.

Esperemos que alguien más pueda respaldar esto.