Pourquoi utiliser un canal nommé au lieu d'un fichier?

31

J'ai récemment lu des articles sur les tubes nommés et je ne comprenais pas pourquoi ils existaient.
J'ai lu quelque part que l'utilisation d'un canal nommé prend moins de temps que l'utilisation d'un fichier.

Pourquoi est-ce ainsi?

Les canaux nommés doivent également être stockés en mémoire (et peuvent être échangés, comme les fichiers).
Autant que je sache, ils doivent obtenir un inode qui doit être référencé par le répertoire en cours, comme les fichiers. En outre, ils doivent être supprimés par le programmeur, tout comme les fichiers.

Alors, où se situe l’avantage?

    
posée user3122885 17.04.2014 - 18:56
la source

4 réponses

30

Presque tout dans Linux peut être considéré comme un fichier , mais la principale différence entre un fichier normal et un fichier nommé est qu’un fichier nommé pipe est une instance spéciale d'un fichier qui n'a aucun contenu sur le système de fichiers.

Voici la citation de man fifo :

  

Un fichier spécial FIFO (un tube nommé) est similaire à un tube, sauf qu’il est accessible dans le cadre du système de fichiers. Il peut être ouvert par plusieurs processus pour lire ou écrire. Lorsque des processus échangent des données via le FIFO, le noyau transmet toutes les données en interne sans les écrire dans le système de fichiers. Ainsi, le fichier spécial FIFO n'a pas de contenu sur le système de fichiers; l'entrée du système de fichiers sert simplement de point de référence pour que les processus puissent accéder au canal en utilisant un nom dans le système de fichiers.

     

Le noyau conserve exactement un objet pipe pour chaque fichier spécial FIFO ouvert par au moins un processus. Le FIFO doit être ouvert aux deux extrémités (lecture et écriture) avant que les données puissent être transmises. Normalement, l'ouverture des blocs FIFO jusqu'à ce que l'autre extrémité soit ouverte également.

Donc, en fait, un canal nommé ne fait rien tant que certains processus ne le lisent et ne l’écrivent pas. Il ne prend pas de place sur le disque dur (sauf un peu de méta-informations), il n'utilise pas le processeur.

Vous pouvez le vérifier en procédant ainsi:

Créer un canal nommé

$ mkfifo /tmp/testpipe

Accédez à certains répertoires, par exemple /home/user/Documents , et compilez tout ce qu’il contient, en utilisant le canal nommé.

$ cd /home/user/Documents
$ tar cvf - . | gzip > /tmp/testpipe &
[1] 28584

Ici, vous devriez voir le PID du processus gzip. Dans notre exemple, c'était 28584.

Vérifiez maintenant ce que fait ce PID

$ ps u -P 28584
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
c0rp     28584  0.0  0.0  29276  7800 pts/8    S    00:08   0:00 bash

Vous verrez qu’elle utilise pas de ressources . 0% d'utilisation du processeur, 0% d'utilisation de la mémoire.

Vérifier l'analyse concernant l'utilisation de l'espace fichier

$ du -h /tmp/testpipe
0   testpipe

Et encore 0 , rien. Le testpipe pourrait être réutilisé si nécessaire.

N'oubliez pas de tuer gzip, en utilisant kill -15 28584 . Et supprimez notre canal nommé en utilisant rm /tmp/testpipe

Exemples d’utilisation

Vous pouvez rediriger presque tout en utilisant le canal nommé. Comme exemple, vous pouvez consulter cette proxy à une ligne .

De plus, en voici une de plus , une bonne explication de l’utilisation des canaux nommés. Vous pouvez configurer deux processus sur un serveur pour communiquer en utilisant un canal nommé au lieu de la pile TCP / IP. Il est beaucoup plus rapide et ne charge pas les ressources réseau. Par exemple, votre serveur Web peut communiquer directement avec la base de données en utilisant un canal nommé, au lieu d'utiliser localhost address ou d'écouter un port.

    
réponse donnée c0rp 17.04.2014 - 21:13
la source
12

Il est vrai que vous n'utiliserez pas la mémoire système, mais le fait de ne pas utiliser cpu dans votre exemple est uniquement dû au fait que vous ne lisez pas le canal, le processus est en attente.

Prenons l'exemple suivant:

mkfifo /tmp/testpipe
tar cvf - / | gzip > /tmp/testpipe

Maintenant, ouvrez une nouvelle console et exécutez:

watch -n 1 'ps u -P $(pidof tar)

Et dans une troisième console:

cat /tmp/testpipe > /dev/null

Si vous regardez la montre cmd (2ème terme), cela montrera une augmentation de la consommation de processeurs!

    
réponse donnée GARCIN David 21.08.2014 - 19:06
la source
0

Vous pouvez laisser un programme rester immobile et écouter un canal nommé pour un événement extérieur. Dès que l'événement extérieur se produit (par ex. Arrivée de nouvelles données) Cela pourrait être détecté par un autre programme qui à son tour ouvre le canal d'écriture, en écrivant les données d'événement pertinentes sur le canal. Lorsque l'instruction close est émise, le programme d'écoute reçoit le flux de données via le canal via une instruction de lecture et est prêt à traiter ce qu'il a. N'oubliez pas de fermer le tuyau après avoir lu le contenu. Le programme d'écoute pourrait également renvoyer les résultats de son traitement via le même, ou via un autre canal nommé. De telles communications inter-programmes sont très pratique par moments.

    
réponse donnée Per Anton Ronning 01.11.2016 - 10:17
la source
0

Voici un cas d'utilisation où les canaux nommés peuvent vous faire gagner beaucoup de temps en supprimant les E / S.

Supposons que vous avez un BigFile, par exemple 10G.

Vous avez également des fractionnements de ce BigFile en morceaux de 1G, BigFileSplit_01 à BigFile_Split_10.

Vous avez maintenant un doute sur l'exactitude de BigFileSplit_05

Naïvement, sans canaux nommés, vous créez une nouvelle partition à partir de BigFile et vous comparez:

dd if=BigFile of=BigFileSplitOrig_05 bs=1G skip=4 count=1
diff -s BigFileSplitOrig_05 BigFileSplit_05
rm BigFileSplitOrig_05

Avec les tubes nommés, vous feriez

mkfifo BigFileSplitOrig_05
dd if=BigFile of=BigFileSplitOrig_05 bs=1G skip=4 count=1 &
diff -s BigFileSplitOrig_05 BigFileSplit_05
rm BigFileSplitOrig_05

Cela peut ne pas sembler à première vue une grande différence ... mais avec le temps, la différence est énorme!

Option 1:

  • dd: lire 1G / écrire 1G (1)
  • diff: lire 2G
  • rm: clusters alloués libres / suppression de l’entrée de répertoire

Option 2:

  • dd: rien! (va au tube nommé)
  • diff: lire 2G
  • rm: pas de cluster alloué à gérer (nous n’avons rien écrit sur le système de fichiers) / suppression de l’entrée de répertoire

Donc, fondamentalement, le canal nommé vous enregistre une lecture et une écriture de 1G plus un nettoyage du système de fichiers (puisque nous n’avons rien écrit sur le système de fichiers mais sur le nœud fifo vide).

Ne pas faire d’E / S, en particulier d’écrire, est également utile pour éviter l’usure de vos disques. Cela est encore plus intéressant lorsque vous travaillez avec des disques SSD, car leur nombre d’écritures est limité avant que les cellules ne meurent.

(1) Évidemment, une autre option consisterait à créer ce fichier temporaire en RAM, par exemple si / tmp est monté en RAM (tmpfs). Néanmoins, vous seriez limité par la taille du disque RAM, alors que le "trick pipe" n'a pas de limites.

    
réponse donnée Zakhar 06.08.2017 - 11:54
la source

Lire d'autres questions sur les étiquettes