Processus multithreadés et close()¶

Il est probablement imprudent de fermer des descripteurs de fichier alors qu'ils peuvent peut-être être utilisés par des appels système dans d'autres threads du même processus. Puisqu'un descripteur de fichier peut être réutilisé, il y a des conditions de concurrence obscures qui peuvent provoquer des effets de bord non désirés.

Par ailleurs, imaginez un scénario où deux threads effectuent plusieurs opérations sur le même descripteur de fichier :

(1)

Un thread est bloqué dans un appel système E/S sur le descripteur de fichier. Par exemple, il essaie de write(2) dans un tube déjà plein ou de read(2) depuis le socket d'un flux qui n'a pas de données disponibles actuellement.

(2)

Un autre thread ferme le descripteur de fichier.

Dans cette situation, le comportement varie selon les systèmes. Sur certains, quand le descripteur de fichier est fermé, l'appel système qui bloque renvoie immédiatement une erreur.

Sur Linux (et probablement d'autres systèmes), le comportement est différent : l'appel système E/S bloquant conserve une référence à la description du fichier ouvert sous-jacent et celle-ci garde la description ouverte jusqu'à ce que l'appel système E/S se termine (voir open(2) pour un point sur les descriptions de fichiers ouverts). Ainsi, l'appel système bloquant du premier thread peut se terminer avec succès après le close() du deuxième thread.

Gérer les erreurs renvoyées par close()¶

Un programmeur prudent vérifiera le code de retour de close(), car il est possible qu'une erreur correspondant à un appel write(2) antérieur ne soit rapportée que lors du close() final. Ne pas vérifier le code de retour lorsqu’un fichier est fermé peut conduire à une perte silencieuse de données. Cela est principalement vrai dans le cas de systèmes de fichiers NFS, ou avec l'utilisation des quotas de disques.

Remarquez cependant que la valeur de retour ne devrait être utilisée que pour les diagnostics (à savoir pour prévenir une application qu'il peut rester des E/S en attente ou échouées) ou de correction (comme pour écrire un fichier une ou plusieurs fois ou pour créer une sauvegarde).

Réessayer close() après un renvoi d'échec n'est pas la bonne manière de faire, car il peut en résulter que le descripteur d'un fichier qui serait réutilisé à partir d'un autre thread se ferme. Cela est possible car le noyau Linux abandonne toujours tôt le descripteur de fichier lors d'une opération de fermeture, ce qui le libère pour être réutilisé ; les étapes de renvoi d'erreur telles que l'effacement des données sur le système de fichiers ou le périphérique arrivent plus tard dans l'opération de fermeture.

Many other implementations similarly always close the file descriptor (except in the case of EBADF, meaning that the file descriptor was invalid) even if they subsequently report an error on return from close(). POSIX.1-2008 was silent on this point.

Un programmeur prudent qui veut savoir les erreurs E/S doit faire précéder close() d'un appel fsync(2).

The EINTR error is a somewhat special case. Regarding the EINTR error, POSIX.1-2008 said:

This permits the behavior that occurs on Linux and many other implementations, where, as with other errors that may be reported by close(), the file descriptor is guaranteed to be closed. However, it also permits another possibility: that the implementation returns an EINTR error and keeps the file descriptor open. (According to its documentation, HP-UX's close() does this.) The caller must then once more use close() to close the file descriptor, to avoid file descriptor leaks. This divergence in implementation behaviors provides a difficult hurdle for portable applications, since on many implementations, close() must not be called again after an EINTR error, and on at least one, close() must be called again.

POSIX.1-2024 standardized the behavior of HP-UX, making Linux and many other implementations non-conforming. There are no plans to change the behavior on Linux.