2010-07-29 7 views

Respuesta

23

Se puede llamar a un manejador de señal en cualquier momento, incluso cuando hay otra llamada en el malloc en curso. Si esto sucede, una de dos cosas va a ocurrir:

  1. Su proceso será punto muerto dentro del manejador de la señal, porque malloc no podrán adquirir el bloqueo montón.
  2. Su proceso dañará su montón, porque mallochace adquirir el bloqueo (o no cree que lo necesite), luego procede a procesar el montón inconsistente, lo que lleva a un bloqueo posterior.
+0

Interesante. ¿Pero puede explicar por qué esto no puede suceder durante el cambio de contexto de hilo normal? El montón también se comparte entre todos los hilos en un proceso. ¿Malloc() no se puede preevaluar excepto durante la invocación del manejador de señal? –

+9

Esto es antiguo, pero vale la pena responder: cuando llega una señal, se maneja DENTRO de un hilo dentro del proceso. El caso más simple en el que puedo pensar involucra un hilo que capta una señal cuando está llamando malloc (digamos, después de que adquiere un bloqueo). Entonces, el manejador de señal llama malloc. Cuando intenta adquirir el bloqueo, ve que el bloqueo ya está retenido, por lo que espera en el bloqueo. La parte del hilo que eventualmente liberará el bloqueo NUNCA se ejecutará, porque está esperando que finalice el controlador de señal. El controlador de señal nunca terminará porque está esperando el bloqueo –

+0

Ese es el problema del interbloqueo. El problema de corrupción ocurre cuando el bloqueo reentrante. En este caso, el manejador de señal * es * capaz de obtener el bloqueo (ya que está retenido por el mismo hilo), y procede a arruinar el montón ya que está ejecutando una solicitud malloc completamente nueva mientras que la existente (en el mismo hilo) ya está en progreso. Esto no puede suceder sin señales, ya que otros hilos usan el bloqueo para coordinar. – BeeOnRope

Cuestiones relacionadas