¿Cuál sería la mejor manera de manejar errores en programas paralelos?

Con algoritmos paralelos tocando a la puerta, podría ser un buen momento para pensar en el manejo de errores.

Así que al principio había códigos de error. Esos apestaron. Era gratis ignorarlos, por lo que podría fallar tarde y producir código difícil de depurar.

Luego vinieron las excepciones. Se hizo imposible ignorarlos una vez que ocurrieron, y la mayoría de las personas (excepto Joel) les gustan más.

Y ahora tenemos bibliotecas que ayudan al código paralelo. El problema es que no puede manejar excepciones en código paralelo tan fácilmente como lo haría con código no paralelo. Si inicia una tarea de forma asincrónica y arroja una excepción, no hay rastro de pila más allá para desenrollarla; lo mejor que puede hacer es capturarlo y registrarlo en el objeto de la tarea, si existe tal objeto. Sin embargo, derrota la fuerza principal de las excepciones: debe verificarlas y puede ignorarlas sin ningún esfuerzo adicional , mientras que en el código de un solo subproceso una excepción necesariamente desencadenará las acciones apropiadas (incluso si eso significa terminar su programa).

¿Cómo deberían las implementaciones de lenguaje o las bibliotecas admitir errores en código paralelo?

programming-languages parallelism exceptions

— zneak
fuente

¿No debería pertenecer a stackoverflow ?

— Graviton

@Ngu Soon Hui Es subjetivo y se trata de características que no necesariamente existen, así que creo que pertenece aquí.

— zneak

Pero se trata de programación, no de programadores. :)

— bzlm

Las preguntas frecuentes de @bzlm dicen "Programadores: Stack Exchange es para programadores expertos que estén interesados en discusiones subjetivas sobre el desarrollo de software". y SO desalienta explícitamente las discusiones subjetivas.

— zneak

Respuestas:

Me gustan mucho las devoluciones de llamada por errores que se pueden manejar. Y se puede hacer que funcionen bien asincrónicamente ...

Pero para errores que no se pueden manejar, errores verdaderamente excepcionales , prefiero ver la información relevante guardada y el programa finalizado. Dado que esto generalmente se logra a través de algún tipo de controlador de errores global de todos modos, no veo la necesidad de convertir las excepciones en algo que funcione para esto, pero sería mejor un mejor soporte de plataforma para detectar errores críticos y producir volcados de memoria, etc.

— Shog9
fuente

Yo segundo devoluciones de llamada. La idea anterior me parece bastante perfecta.

— Pax Noctis

-2

Parece que querrás asegurarte de que la tarea maneje sus propias excepciones, y luego devolver algo que le permita al programa de llamadas saber que el hilo debe cerrarse. Entonces tendría lógica procesar el resultado de todos los hilos, sabiendo que algunos de esos hilos habían fallado.

"devolviendo algo" - ¿a quién? La persona que llama ya se ha movido.

— Mark H

Como dijo @sparkie, no puedes hacer eso. Incluso si mantiene la pila de llamadas como raíz de la rutina, la persona que llama probablemente estará muy, muy lejos. Como mencioné, las excepciones fueron diseñadas para que detengan su programa , ahora . Si lo comprueba usted mismo más tarde, lo derrota por completo, ya que las excepciones pueden pasar desapercibidas.

— zneak

@Zneak, supongo que cuando mencioné excepciones que no estaba usando su definición (estándar), solo quise decir que se detectó el error. Una vez finalizada cualquier función, debe regresar a algún lugar, en ese punto se puede tratar la "excepción" / error (en ese nivel). No estoy seguro de por qué se están refiriendo a que el programa de llamadas está muy lejos, cualquier valor de retorno de la función tiene que ser tratado de alguna manera. Me doy cuenta de que esto no funcionará tan bien si los resultados de los hilos se combinan entre sí de forma dependiente.

No todas las tareas paralelas "regresan" a alguna parte. Por ejemplo, podría delegar una tarea larga en un hilo separado mientras hace otra cosa en el hilo principal, (erróneamente) sin preguntarse si se completó correctamente. Por ejemplo, podría escribir un software de edición de imágenes que escriba en archivos desde un subproceso secundario y regresar del cuadro de diálogo Guardar tan pronto como se inicie la tarea. No necesitaré el valor de retorno, sea lo que sea, para cualquier otra operación, por lo que, excepto por errores, no hay razón para verificarlo.

— zneak