2011-01-05 13 views
5

Hablando de Signal handlers and logging in Python surgió en mi mente la pregunta qué funciones son reentrantes en Python.Qué funciones son reentrantes en Python para el procesamiento de la biblioteca de señales

El signal library menció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 los atómicas 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 .

que re-entrada no es típico es señalado por el logging library:

Si va a implementar asíncronos manejadores de señales mediante el módulo de señales , es posible que no pueda utilizar registro de dentro de tales manejadores. 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 controladores de señal.

Estoy un poco confundido porque la biblioteca de señales habla sobre el GIL (bloqueo de intérprete global) como ".. entre las instrucciones atómicas ..". En este caso, las señales se posponen y ejecutan tan pronto como se deja el GIL/desbloqueado. Un tipo de cola de señal.

Eso tiene sentido, pero no importa si las funciones que son llamadas por el manejador de señal pospuesto son re-entrantes, ya que no son llamados en el verdadero gestor de señales POSIX con el "re-entrante" -Limitación:

Sólo una lista definida de POSIX C funciones se declaran como reentrante y se puede llamar dentro de un manejador de señales POSIX . IEEE Std 1003.1 enumera 118 funciones de UNIX reentrantes que encuentra en https://www.opengroup.org/ (se requiere iniciar sesión en ).

Respuesta

2

Creo que lo que hace que el módulo de registro no reentrante es que utiliza un threading.Lock (en lugar de un RLock) para sincronizar varios hilos de registro para los mismos manipuladores (para que los mensajes no llegan entretejido).

Esto significa que si una llamada de registro que ha adquirido un bloqueo es interrumpida por un manejador de señal y los controladores de señal intentan iniciar sesión, se bloqueará para siempre la liberación del anterior acquire.

Estos bloqueos no tienen nada que ver con el GIL por cierto, son bloqueos "creados por el usuario" para decirlo de alguna manera, el GIL es un candado utilizado por el intérprete (un detalle de implementación).

+0

He comprobado la versión de Python 2.7.1 y su suposición es incorrecta.Compruebe la función '_acquireLock()' en http://svn.python.org/view/python/tags/r271/Lib/logging/__init__.py?revision=86833&view=markup –

+0

Me corrigen, es en realidad ' RLock'. Gracias por desenterrarlo. Sin embargo, de acuerdo con los documentos, la implementación podría no ser siempre reentrante: "Esto se debe a que las implementaciones de bloqueo en el módulo de subprocesamiento no siempre son reentrantes" (http://docs.python.org/library/logging.html). # thread-safety) – albertov

+0

Esto es lo que mencioné en mi pregunta. Podemos hacer hincapié en que cada módulo que utiliza la biblioteca de threading no es reentrante en el sentido de ser utilizado en un controlador de señal * real * POSIX. Pero, ¿Python no pospone el procesamiento de la señal? –

Cuestiones relacionadas