Est-il nécessaire de fermer les descripteurs de fichier avant de quitter?

Question

Bien sûr, dans la plupart des situations, la réponse immédiate est "oui" , et je suis fermement convaincu qu'un processus doit nettoyer correctement toutes les ressources qu'il a allouées, mais ce que j'ai dans ma situation est un démon système de longue durée qui ouvre un nombre fixe de descripteurs de fichiers au démarrage et les ferme tous avant de quitter.

Il s’agit d’une plate-forme intégrée, et j’essaie de rendre le code aussi compact que possible sans introduire de mauvais style. Mais puisque les descripteurs de fichier sont fermés avant de quitter de toute façon, ce code de nettoyage de descripteur de fichier a-t-il une quelconque utilité? Fermez-vous toujours tous vos descripteurs de fichiers?

Answer 1

La fermeture des descripteurs de fichiers lorsque vous avez fini de les utiliser rend votre code plus réutilisable et plus facile à étendre. Cela me semble être un cas où vous avez une raison valable de les laisser se fermer automatiquement.

Answer 2

Oui, fermez vos descripteurs de fichiers et libérez toute la mémoire morte, même si vous savez que le système d’exploitation le nettoiera. Ainsi, lorsque vous exécutez valgrind ou un outil similaire, vous n'obtiendrez pas beaucoup de bruit. résultats, et vous pouvez facilement reconnaître "légitime". fd fuit.

Answer 3

Dans le magnifique monde de la plate-forme intégrée, il est vraiment difficile de dire ce qui se passerait. Cependant, si j'étais dans votre situation, je testerais simplement manuellement si les identifiants de fichiers sont réellement publiés. Et, si l'espace est si important, vous pourriez peut-être documenter ce fait ailleurs.

Answer 4

La seule chose qui me préoccuperait en ce qui concerne le nettoyage automatique des descripteurs de fichiers, serait de savoir à quel point vous vous souciez des données que vous avez écrites dans ces descripteurs et si vous pouviez raisonnablement traiter un manquement. écrire.

write () n’a pas besoin de bloquer (en fonction de la manière dont elle a été ouverte en premier lieu) et d’attendre que les données soient validées; il existe donc des cas où la fermeture peut échouer car le sous-système sous-jacent échoue. en attente d'écriture, et ferme donc les sorties avec échec et définit errno sur EIO, et en fonction de ce que vous venez d'écrire, vous pouvez choisir de ne pas prendre certaines mesures correctives.

Certes, il s’agit d’un cas épineux dans lequel vous vous souciez VRAIMENT de la cohérence des données, c’est-à-dire des applications de type SGBD ou des rapports sur les succès / échecs d’une sauvegarde. Dans beaucoup de cas (la plupart?), Cela n'a pas vraiment d'importance, et vous pourrez laisser close () pour traiter le nettoyage / la sortie.

Answer 5

man 3 exit:

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

Je pense donc que quitter main appelle la fonction de sortie avec la valeur de retour de main. Bien que je dirais que c'est un mauvais style. Personnellement, je toujours libère / ferme explicitement les ressources acquises.