Descripteur de fichier et fork

15

Lorsqu'un enfant est bifurqué, il hérite des descripteurs de fichiers du parent.Si l'enfant ferme le descripteur de fichier, que se passera-t-il? Si l'enfant commence à écrire ce qui arrivera au dossier à la fin du parent? Qui gère ces incohérences, noyau ou utilisateur?

lorsqu'un processus appelle la closefonction pour fermer un fichier ouvert particulier via le descripteur de fichier. Dans la table de fichiers du processus, le décompte de références est décrémenté de un. Mais puisque le parent et l'enfant détiennent tous deux le même fichier, le nombre de références est 2 et après la fermeture, il est réduit à 1. Puisqu'il n'est pas nul, le processus continue à utiliser le fichier sans aucun problème.

Voir Programmation système Terrence Chan UNIX, (prise en charge du noyau Unix pour les fichiers).

Madan Ram
la source
D'accord, peu importe ce dernier commentaire;) Dans les pages de manuel pour open()et fork()il y a une distinction entre un descripteur de fichier ou et un descipt-ion de fichier - le premier fait référence au dernier, et bien que les descripteurs dans un fork soient des copies, ils se réfèrent à la même description. Cependant, lorsqu'il est testé, il est évident que cela ne signifie pas que la fermeture de la poignée de l'enfant ferme la poignée des parents. Je pense que cela pourrait faire une différence subtile dans l'entrelacement des données lorsque les deux poignées écrivent - mais c'est de toute façon indéterminé, donc comment exactement cela se produit n'est pas si important.
goldilocks

Réponses:

28

Lorsqu'un enfant est bifurqué, il hérite des descripteurs de fichiers du parent.Si l'enfant ferme le descripteur de fichier, que se passera-t-il?

Il hérite d'une copie du descripteur de fichier. Ainsi, la fermeture du descripteur chez l'enfant le fermera pour l'enfant, mais pas pour le parent, et vice versa.

Si l'enfant commence à écrire ce qui arrivera au dossier à la fin du parent? Qui gère ces incohérences, noyau ou utilisateur?

C'est exactement (comme dans, exactement littéralement) la même chose que deux processus écrivant dans le même fichier. Le noyau planifie les processus indépendamment, vous obtiendrez donc probablement des données entrelacées dans le fichier.

Cependant, Posix (auquel systèmes * nix se conforment en grande partie ou totalement), précise que read()et les write()fonctions de l'API C (qui carte pour les appels système) sont « atomique par rapport à l'autre [...] quand ils fonctionnent sur les fichiers réguliers ou liens symboliques ". Le GNU C manuellement le promet également provisoirement en ce qui concerne les tuyaux (notez que la valeur par défaut PIPE_BUF, qui fait partie de la réserve, est de 64 Ko). Cela signifie que les appels dans d'autres langues / outils, tels que l'utilisation de echoou cat, devraient être inclus dans ce contrat, donc si deux processus indépendants essaient d'écrire "bonjour" et "monde" simultanément dans le même canal, ce qui sortira de l'autre la fin est soit "helloworld" ou "worldhello", et jamais quelque chose comme "

quand un processus appelle la fonction de fermeture pour fermer un fichier ouvert particulier via un descripteur de fichier. à 1) car il n'est pas nul, le processus continue donc à utiliser le fichier sans aucun problème.

Il existe DEUX processus, le parent et l'enfant. Il n'y a pas de "décompte de références" commun aux deux. Ils sont indépendants. WRT ce qui se passe lorsque l'un d'eux ferme un descripteur de fichier, voir la réponse à la première question.

boucle d'or
la source
1

Chaque fois fork()qu'un nouvel enfant est créé, les descripteurs de fichiers ne sont pas du tout conservés - ils sont modifiés.

Bien que le fichier soit un doublon, il aura un descripteur de fichier différent.

mannukaushikece
la source