2012-07-12 8 views
13

si la función llamada por pthread_create tiene la siguiente estructura¿por qué pthread_exit arroja algo atrapado por elipsis?

try{ 
    ...code.... 
    pthread_detach(pthread_self()); 
    pthread_exit(NULL); 
}catch(...){ 
    std::cout<<"I am here"<<std::endl; 
} 

¿por qué el controlador de excepciones para los puntos suspensivos ser llamado por la ejecución de pthread_exit? (tenga en cuenta que std::exception, por ejemplo, están sin torcer)

+0

¿En qué compilador ves esto? –

+0

@Fabio Quizás esté arrojando algún destructor de un objeto en la pila. –

+0

@DaveS g ++ Gracias TorstenRobitzki, pensé lo mismo, pero el caso fue el explicado por eran –

Respuesta

22

pthread_exit podría lanzar una excepción ___forced_unwind, que se utiliza para desconectar la pila durante la salida de rosca. No hereda de std::exception y, por lo tanto, no se puede capturar como uno solo. Si usted coge esa excepción, asegúrese de volver a throw que lo que puede hacer su trabajo:

try { 
... 
} catch (abi::___forced_unwind&) { 
    throw; 
} catch (...) { 
    // whatever 
} 

La razón se produce una excepción es que pthread_exit se especifica para no volver jamás. Tenerlo arroja garantiza la limpieza de las variables asignadas por la pila, y la no ejecución del código después de su ubicación (a menos que detecte la excepción de desenrollado ...).

Por cierto, este es otro caso donde la expresión catch (...) hace más daño que bien. A veces se usa para "estabilizar" el código que arroja excepciones desconocidas. Pero eso solo difiere la visibilidad del daño a un tiempo y lugar posterior, lo que hace imposible identificar el origen real del problema. Lo único razonable que se puede hacer en una captura como esta es la limpieza mínima, posiblemente la tala y luego volver a tirar. Un proceso que falla debido a una excepción no controlada no es una vista agradable, pero puede proporcionar un volcado de falla debugible que muestra claramente el comando defectuoso. Pero eso es solo mi rencor contra catch (...), que apenas se relaciona con pthread_exit ...

+0

Muchas gracias, este fue exactamente el caso! y creo que su lanzamiento es para prevenir FATAL: excepción no resuelto gracias! –

+0

+1 ¡Muy interesante! –

+1

@Fabio: la excepción 'abi :: __ forced_unwind' también se puede lanzar en subprocesos que se han cancelado con' pthread_cancel'. Tenga cuidado con la captura de puntos suspensivos cuando termine pthreads. –

Cuestiones relacionadas