¿Cómo puedo determinar si un subthread separado todavía está vivo?¿Cómo puedo determinar si un pthread está vivo?
Tengo un canal de comunicación con el hilo (una cola unidireccional que apunta hacia fuera del hilo) pero ¿qué sucede si el hilo muere sin un grito?
¿Debo resignarme a la utilización de procesos señales o puedo sonda para la vivacidad hilo de alguna manera?
Puede utilizar pthread_kill así:
int ret = pthread_kill(YOUR_PTHREAD_ID, 0);
Si se obtiene un valor ESRCH, que podría ser el caso de que el hilo está muerto.
ACTUALIZACIÓN: al parecer, mi respuesta es incorrecta. No puedo borrarlo ya que es una respuesta aceptada.
De los comentarios:
The answer is wrong because if the thread is detached and is not alive, the pthread_t is invalid. You can't pass it to pthread_kill. It could, for example, be a pointer to a structure that was freed, causing your program to crash. POSIX says, "A conforming implementation is free to reuse a thread ID after its lifetime has ended. If an application attempts to use a thread ID whose lifetime has ended, the behavior is undefined." – Thanks @DavidSchwartz
es probable que sea un comportamiento indefinido cuando se envía una señal a un hilo ya muerto. Su aplicación puede bloquearse. ver http://sourceware.org/bugzilla/show_bug.cgi?id=4509 y http://udrepper.livejournal.com/16844.html
Esta pregunta asume un diseño con una condición de carrera inevitable.
Es de suponer, que va a hacer algo como esto:
El problema es que esta secuencia no es atómico y no puede ser arreglado Específicamente, ¿qué ocurre si el hilo que está comprobando muere entre el paso (1) y el paso (2)?
Las condiciones de carrera son malas; raras condiciones de carrera doblemente. Echar mano de algo 90% confiable con algo 99.999% confiable es una de las peores decisiones que puede tomar.
La respuesta correcta a su pregunta es "no hagas eso". En su lugar, arregle su aplicación para que los hilos no mueran aleatoriamente.
Si eso es imposible, y algunos hilos son propensos a fallar, y necesita recuperarse de eso ... Entonces su diseño es fundamentalmente defectuoso y no debe usar un hilo. Ponga esa cosa poco confiable en un proceso diferente y use una tubería para comunicarse con ella. La muerte del proceso cierra los descriptores de archivos, y la lectura de una tubería cuyo otro extremo se ha cerrado tiene un comportamiento bien definido, fácil de detectar y sin carreras.
El problema se derivaba de un procedimiento de cierre y no de uno de recuperación de fallos. – jldupont
Corto y dulce ... gracias! – jldupont
El problema con eso es que 'YOUR_PTHREAD_ID' podría haber sido reciclado por otro hilo mientras tanto. Por lo tanto, debería ser: __Si obtiene ESRCH, su hilo está muerto, de lo contrario no puede estar seguro__ (a menos que sepa las ID de los hilos recién creados). – RedGlyph
@RedGlyph: este es un caso muy típico de enigma de reciclaje de identificadores.En mi caso, estoy dispuesto a vivir con la pequeña probabilidad de colisión en la que incurro porque estaré sondeando en una frecuencia razonable. – jldupont