Existe uma necessidade de fechar descritores de arquivo antes de sair?

Question

É claro que a resposta imediata para a maioria das situações é "sim" , e eu sou um firme crente de que um processo deve corretamente a limpeza quaisquer recursos que alocou, mas o que eu tenho na minha situação é uma longa daemon sistema que abre um número fixo de descritores de arquivos na inicialização, e fecha-los todos antes de sair.

Esta é uma plataforma embarcada, e eu estou tentando fazer o código mais compacto possível, apesar de não introduzir qualquer estilo ruim. Mas desde que descritores de arquivos estão fechados antes de sair de qualquer maneira, se este descritor código de limpeza de arquivos servir a qualquer propósito? Você sempre perto todos seus descritores de arquivo?

Answer 1

O encerramento de descritores de arquivos Quando você terminar de usá-los torna seu código mais reutilizável e fácil de estender. Isto soa para mim como um caso onde você tem uma razão válida para deixá-los ficar fechado automaticamente.

Answer 2

Sim, feche os descritores de arquivos e libertar toda a memória heap, mesmo se você sabe que o sistema operacional irá limpá-lo - de que maneira, quando você executar valgrind ou alguma ferramenta similar, você não terá um monte de ruído na resultados, e você pode reconhecer facilmente "legítimas" vazamentos fd.

Answer 3

No mundo maravilhoso da plataforma embarcada, é realmente difícil dizer o que faria acontece. No entanto, se eu estivesse na sua situação, eu tinha acabado manualmente teste para ver se o ID do arquivo são realmente lançado .. E, se o espaço é tão importante, talvez você poderia documentar esse fato em outro lugar.

Answer 4

A única preocupação que eu teria que diz respeito ao sair fechando arquivo-descritores para limpeza automática, seria o quanto você se preocupa com todos os dados que você escreveu para o dito ficheiro-descritores e se você razoavelmente pode lidar com a falta de gravação.

write () não precisa bloquear (dependendo de como fosse open () ed em primeiro lugar) e esperar por dados para comprometer com sucesso, por isso, há casos em que perto pode falhar porque o sub-sistema subjacente não cometer o pendente de gravação, e sai, assim, estreitas com falha e conjuntos de errno para EIO, e dependendo do que você acabou de escrever, você pode ou não quer tomar alguma ação corretiva.

Na verdade, este é um caso canto onde você realmente se preocupam com a consistência dos dados, ou seja, um SGBD tipo aplicações ou relatando sucesso / fracasso de um backup. Em muitos (a maioria?) Dos casos, realmente não importa tanto assim, e você vai ficar bem deixando de fora close () para a limpeza processo / saída.

Answer 5

man 3 saída:

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

Então, eu acredito deixando principal efetivamente chama a função de saída com valor de retorno do principal. Embora eu diria que é ruim estilo. Pessoalmente, eu sempre explicitamente livre / fechar qualquer recursos adquiridos.