solicita - llamada al sistema exec
¿Qué hacer si falla una llamada de posix close? (2)
Antes que nada: EINTR significa exactamente eso: Se interrumpió la llamada al sistema, si esto sucede en una llamada close() , no hay nada que puedas hacer.
Además de tal vez hacer un seguimiento del hecho, si el fd pertenecía a un archivo, este archivo posiblemente esté dañado, no hay mucho que pueda hacer sobre los errores en close() en absoluto, dependiendo del valor de retorno. AFAIK, el único caso en el que se puede volver a intentar un cierre está en EBUSY , pero todavía no lo he visto.
Asi que:
- Si no se comprueba el resultado de
close()posible que se pierda la corrupción de archivos, especialmente el truncamiento. - Dependiendo del error, la mayoría de las veces no puede hacer nada: un
close()fallidoclose()solo significa que algo salió muy mal fuera del alcance de su aplicación.
En mi sistema (Ubuntu Linux, glibc), la página man de una llamada close especifica varios valores de retorno de error que puede devolver. También dice
No verificar el valor de retorno de close () es un error de programación común pero serio.
y al mismo tiempo
Tenga en cuenta que el valor de retorno solo se debe usar para el diagnóstico. En particular, close () no debería volverse a intentar después de un EINTR, ya que esto puede provocar que se cierre un descriptor reutilizado de otro hilo.
Por lo tanto, no puedo ignorar el valor de retorno ni volver a intentar la llamada.
Dado que, ¿cómo manejaré el error de llamada close() ?
Si el error ocurrió cuando estaba escribiendo algo en el archivo, se supone que debo tratar de escribir la información en otro lugar para evitar la pérdida de datos.
Si solo estaba leyendo el archivo, ¿puedo registrar el error y continuar el programa simulando que no pasó nada? ¿Hay alguna advertencia, filtración de descriptores de archivos o lo que sea?
En la práctica, close nunca se debe volver a intentar por error, y el fd que pasó para close siempre es inválido (cerrado) después de que devuelve el close , independientemente de si se produjo un error. En algunos casos, un error puede indicar que se perdieron datos (ciertas configuraciones NFS) o condiciones de hardware inusuales para los dispositivos (por ejemplo, la cinta no se pudo rebobinar), por lo que puede tener cuidado para evitar la pérdida de datos, pero nunca debe intentar cierra el fd de nuevo.
En teoría, POSIX no estaba claro en el pasado si el fd permanece abierto cuando el close falla con EINTR , y los sistemas no estuvieron de acuerdo. Dado que es importante conocer el estado (si no tiene fd fugas o errores de doble cierre que son extremadamente peligrosos en programas de subprocesos múltiples), la resolución del número 529 de Austin Group especificó el comportamiento estrictamente para versiones futuras de POSIX, que EINTR significa el Fd permanece abierto. Este es el comportamiento correcto consistente con la definición de EINTR otros lugares, pero Linux se niega a aceptarlo. (FWIW hay una solución fácil para esto que es posible en el nivel de contenedor libc syscall, vea glibc PR # 14627 ). Afortunadamente nunca se presenta en la práctica de todos modos.
Algunas preguntas relacionadas que puede encontrar informativas: