Manejo de EINTR: reintentar la operación específica sin renovar todo su plazo

Qué es

La documentación de señales de Linux explica que una interfaz bloqueante interrumpida puede reiniciarse automáticamente o fallar con EINTR, según la interfaz y SA_RESTART. Algunas operaciones que ya transfirieron datos informan del progreso en su lugar. El comportamiento documentado es específico de cada interfaz, por lo que «reintentar toda syscall fallida» no constituye un envoltorio general sólido. Manual de señales de Linux

Por qué importa

Un agente puede manejar la interrupción volviendo a ejecutar toda la operación con un tiempo límite nuevo. Un flujo de señales puede entonces mantener el trabajo activo más allá de su presupuesto previsto. Conviene separar el intento de syscall de la operación de la aplicación, y preservar el progreso, el plazo y el estado de cancelación de esta última.

Cómo aplicarlo

• Leer el manual de la interfaz exacta y la plataforma de destino. Registrar si puede devolver EINTR, reiniciarse automáticamente o informar de un progreso parcial para el descriptor y los ajustes en cuestión.
• Manejar el progreso positivo antes de considerar los reintentos por error. Mantener el estado restante de entrada o salida en lugar de reiniciar desde el principio una operación de varios pasos.
• Representar el tiempo límite de la aplicación como un plazo fijo, y recalcular la espera restante antes de cada nuevo intento admisible. Comprobar la condición de cancelación antes de reintentar.
• Evitar macros amplias que reintenten operaciones no relacionadas sin considerar su semántica particular. Mantener las excepciones visibles y justificadas en la implementación del envoltorio.
• Proponer pruebas controladas que entreguen una señal durante la operación bloqueada, con y sin la política de reinicio correspondiente. Verificar la finalización acotada y el registro correcto del progreso parcial.

Trampas

Las reglas de reinicio difieren entre sistemas Unix y entre interfaces de un mismo sistema. Los runtimes de lenguajes de alto nivel también pueden envolver las llamadas al sistema, por lo que conviene inspeccionar esa capa antes de duplicar su comportamiento. Un fixture de señales sintético no puede demostrar todos los calendarios de interrupción posibles. Este artículo propone una estrategia acotada de revisión y prueba; no afirma que se haya ejecutado ningún experimento con señales, ni que todos los casos de EINTR deban ocultarse a quienes llaman.