Pregunta

Por supuesto, la respuesta inmediata para la mayoría de las situaciones es " yes " , y creo firmemente que un proceso debe limpiar correctamente los recursos que ha asignado, pero lo que tengo en mi situación es un demonio de sistema de larga ejecución que abre un número fijo de descriptores de archivos al inicio y los cierra todos antes de salir.

Esta es una plataforma integrada, y estoy tratando de hacer que el código sea lo más compacto posible, sin introducir ningún mal estilo. Pero dado que los descriptores de archivo están cerrados antes de salir de todos modos, ¿este código de limpieza de descriptor de archivo tiene algún propósito? ¿Siempre cierra todos los descriptores de sus archivos?

¿Fue útil?

Solución

Cerrar los descriptores de archivos cuando haya terminado de usarlos hace que su código sea más reutilizable y más fácil de extender. Esto me parece un caso en el que tienes un motivo válido para permitir que se cierren automáticamente.

Otros consejos

Sí, cierre los descriptores de archivos y libere toda la memoria de almacenamiento dinámico, incluso si sabe que el sistema operativo lo limpiará; de esa forma, cuando ejecute valgrind o alguna herramienta similar, no obtendrá mucho ruido en el resultados, y puede reconocer fácilmente "legítimo" fd fugas.

En el hermoso mundo de la plataforma integrada, es realmente difícil decir qué sucedería. Sin embargo, si estuviera en su situación, simplemente probaría manualmente para ver si la ID del archivo realmente se libera ... Y, si el espacio es tan importante, tal vez podría documentar este hecho en otro lugar.

La única preocupación que tendría con respecto a dejar el cierre de los descriptores de archivos para la limpieza automática, sería cuánto le importan los datos que ha escrito a dichos descriptores de archivos y si razonablemente puede lidiar con un fallo escribir.

write () no necesita bloquear (dependiendo de cómo se abrió () ed en primer lugar) y esperar a que los datos se confirmen correctamente, por lo que hay casos en los que puede fallar el cierre porque el subsistema subyacente no puede confirmar el pendiente de escritura y, por lo tanto, cierra las salidas con error y establece errno en EIO, y dependiendo de lo que acaba de escribir, es posible que desee o no tomar alguna medida correctiva.

Es cierto que este es un caso de esquina en el que REALMENTE le importa la consistencia de los datos, es decir, aplicaciones de tipo DBMS o informes de éxito / falla de una copia de seguridad. En la mayoría de los casos (¿la mayoría?), Realmente no importa tanto, y estará bien si se cierra () para procesar la limpieza / salida.

salida man 3:

....
All open stdio(3) streams are flushed and closed.  Files created by tmpfile(3) are removed.

Así que creo que dejar main llama efectivamente a la función de salida con el valor de retorno de main. Aunque yo diría que es un mal estilo. Personalmente, siempre libero / cierro explícitamente cualquier recurso adquirido.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top