Fermez explicitement les descripteurs de fichiers ou laissez le système d'exploitation les fermer en programmation Unix C?

Question

Dans la programmation Unix C, est-il considéré comme une bonne pratique de fermer explicitement les descripteurs de fichiers avant la fin du processus, ou bien de laisser le système d'exploitation fermer les descripteurs de fichiers afin d'éviter tout code inutile?

Lequel des deux serait généralement considéré comme la solution privilégiée?

Exemple:

int main (int argc, char* argv[])
{
    int sd;
    sd = socket(...);

    // Snip

   close(sd); // Good or bad practice?
   return 0;
}

Answer 1

En général, le code qui effectue l'ouverture et la fermeture ne sait pas si le processus va se terminer immédiatement. Il est donc préférable d'inclure du code explicite.

Même si le code réside dans la fonction main () de niveau supérieur, ce serait toujours une bonne idée de le réutiliser éventuellement.

Answer 2

Il est considéré comme une bonne pratique de les fermer vous-même.

Probablement parce que c'est une bonne habitude, au cas où votre programme grossirait et ne sortirait pas avant un certain temps après avoir fini d'utiliser un "fichier" particulier.

Les exceptions stdin, stdout et stderr n'ont pas été ouvertes par votre processus.

Incidemment, le terme UNIX est "descripteur de fichier".

Answer 3

C'est une bonne pratique de les fermer si vous le pouvez.

Si votre programme change pour que le fichier soit fermé le plus tôt possible, vous n'avez pas besoin de vous rappeler d'ajouter close () ultérieurement lorsque le fichier d'E / S sera refactoré.

Answer 4

Je n'ai pas utilisé unix depuis l'université, mais en vous fiant aux poignées de fermeture de fichiers unix, vous réduisez le nombre de façons dont votre code peut être utilisé.

Vous construisez un cauchemar pour vous-même si votre code doit jamais être porté sur une autre plate-forme, ou si votre code doit être modifié pour fonctionner en tant que service long, sans gestion explicite des ressources, vous allez bientôt en manquer de ressources.

J'espère que vous trouvez cela utile,

Answer 5

C’est une très bonne pratique de fermer le descripteur si votre programme continue, mais que le descripteur n’est plus nécessaire.

Là encore, cela dépend du type de descripteur de fichier. fermer () une socket va la vider, par exemple, et si cela échoue, vous pouvez vouloir réessayer.

Answer 6

Je pense que c'est presque "universel", si vous avez des ressources de système d'exploitation ouvertes, vous devriez toujours les fermer juste après les avoir finies de les utiliser. De cette façon, vous libérez ces ressources pour qu'elles puissent être utilisées par d'autres applications.

En s’appuyant sur le système d’exploitation pour fermer vos poignées, il les ferme quand il pense que vous n’en avez plus besoin (par exemple, la sortie de l’application). Vous devez toujours libérer les ressources système.

Answer 7

La fermeture de tout fichier que vous ouvrez est considérée comme une bonne chose, de manière extrêmement importante, afin de vous permettre de connaître les erreurs d'E / S et de les signaler à l'utilisateur. Pour la même raison, c’est probablement une bonne idée de vider (ou éventuellement de fermer) stdout et stderr si vous leur écrivez.