pipe − Vue d’ensemble des tubes et des FIFO.

Les tubes et les FIFO (également appelées tubes nommés) fournissent un canal de communication inter-processus unidirectionnel. Un tube a une extrémité lecture et une extrémité écriture. Les données écrites sur l’extrémité écriture d’un tube peuvent être lues sur l’extrémité lecture du tube.

Un nouveau tube est créé avec pipe(2) qui renvoie deux descripteurs de fichier, un faisant référence à l’extrémité lecture du tube, l’autre faisant référence à l’extrémité écriture.

Les tubes sont utilisés pour créer un canal de communication entre processus en relation ; voir pipe(2) pour un exemple.

Une FIFO (anagramme de First In First Out ; Ndt : premier entré, premier sorti) a un nom sur le système de fichier (créé avec mkfifo(3)), et peut être ouverte avec open(2). Tout processus peut ouvrir une FIFO, du moment où les permissions du fichier l’autorisent. L’extrémité lecture est ouverte avec l’attribut O_RDONLY ; l’extrémité écriture est ouverte avec l’attribut O_WRONLY. Voir fifo(7) pour plus de détails. Note : Bien que les FIFO aient un nom de chemin sur le système de fichier, les entrées-sorties sur les FIFO n’impliquent pas des opérations sur le périphérique sous-jacent (s’il y en a un).

Entrées-sorties sur les tubes et les FIFO

La seule différence entre les tubes et les FIFO est la manière dont ils sont créés et ouverts. Une fois ces tâches accomplies, les entrées-sorties sur les tubes et les FIFO ont exactement la même sémantique.

Si un processus tente de lire dans un tube vide, read(2) bloquera jusqu’à ce que des données soient disponibles. Si un processus tente d’écrire dans un tube plein (voir plus loin), write(2) bloquera jusqu’à ce que suffisamment de données aient été lues dans le tube pour permettre une écriture complète. Des entrées-sorties non bloquantes sont possible si on utilise l’opération F_SETFL de fcntl(2) pour activer le drapeau d’état fichier ouvert O_NONBLOCK.

Le canal de communication fourni par un tube est un flux d’octets : il n’y a aucun concept de frontières de message.

Si tous les descripteurs de fichier faisant référence à l’extrémité écriture d’un tube ont été fermés, une tentative de lecture sur le tube mettra en évidence une fin-de-fichier (read(2) renverra 0). Si tous les descripteurs de fichier faisant référence à l’extrémité lecture d’un tube ont été fermés, une tentative d’écriture (write(2)) fera qu’un signal SIGPIPE sera généré pour le processus appelant. Si le processus appelant ignore ce signal, write(2) échouera avec l’erreur EPIPE. Une application qui utilise pipe(2) et fork(2) devrait utiliser des appels close(2) appropriés pour fermer les descripteurs de fichier non nécessaires afin de s’assurer que la fin-de-fichier et SIGPIPE/EPIPE soient délivrés lorsque c’est approprié.

Il n’est pas possible d’appliquer lseek(2) sur un tube.

Capacité d’un tube

Un tube a une capacité limitée. Si le tube est plein, un write(2) bloquera ou échouera, suivant que l’attribut O_NONBLOCK est positionné ou non (voir plus loin). Différentes implémentations ont différentes limites pour la capacité d’un tube. Les applications ne devraient pas compter sur une capacité particulière : une application devrait être conçue de telle manière qu’un processus de lecture consomme les données aussitôt qu’elles sont disponibles afin qu’un processus d’écriture ne reste pas bloqué.

Dans les versions de Linux précédant la 2.6.11, la capacité d’un tube était la même que la taille de page système (par exemple, 4096 octets sur x86). Depuis Linux 2.6.11, la capacité des tubes est 65536 octets.

PIPE_BUF

POSIX.1-2001 dit que les écritures de moins de PIPE_BUF octets doivent être atomiques : les données de sortie sont écrites sur le tube comme une séquence contiguë. Les écritures de plus de PIPE_BUF peuvent ne pas être atomiques : le noyau peut mélanger les données avec des données écrites par d’autres processus. POSIX.1-2001 réclame que PIPE_BUF soit au moins 512 octets. (Sous Linux, PIPE_BUF est 4096 octets.) La sémantique précise dépend de si le descripteur de fichier est non bloquant (O_NONBLOCK), s’il y a plusieurs « écrivains » sur le tube, et de n, le nombre d’octets à écrire :

O_NONBLOCK désactivé, n <= PIPE_BUF

Tous les n octets sont écrits atomiquement ; write(2) peut bloquer s’il n’y a pas la place pour écrire n octets immédiatement.

O_NONBLOCK activé, n <= PIPE_BUF

S’il y a la place pour écrire n dans le tube, write(2) réussit immédiatement, écrivant tous les n octets ; autrement write(2) échoue, avec errno contenant EAGAIN.

O_NONBLOCK désactivé, n > PIPE_BUF

L’écriture n’est pas atomique : les données fournies à write(2) peuvent être mélangées avec d’autres écritures par d’autres processus ; write(2) bloquera jusqu’à ce que n octets soient écrits.

O_NONBLOCK activé, n > PIPE_BUF

Si le tube est plein, write(2) échouera avec errno contenant EAGAIN. Autrement, de 1 à n octets peuvent être écrits (c’est-à -dire que l’on peut avoir une écriture partielle ; l’appelant devrait analyser la valeur de retour de write(2) pour voir combien d’octets ont été écrits), et ces octets peuvent être mélangés avec des écritures effectuées par d’autres processus.

Drapeaux d’état fichier ouvert

Les seuls drapeaux d’état fichier ouvert qui peuvent être significativement appliqués à un tube ou une FIFO sont O_NONBLOCK et O_ASYNC.

Positionner le drapeau O_ASYNC pour le coté lecture d’un tube fera qu’un signal (SIGIO par défaut) sera généré lorsqu’une nouvelle entrée sera disponible sur le tube (voir fcntl(2) pour les détails). Sous Linux, O_ASYNC n’est supporté pour les tubes et les FIFO que depuis le noyau 2.6.

Notes de portabilité

Sur certains systèmes (pas Linux), les tubes sont bidirectionnels : les données peuvent être transmises dans les deux directions entre les extrémités du tube. Selon POSIX.1-2001, les tubes n’ont besoin que d’être unidirectionnels. Les applications portables devraient éviter la dépendance à la sémantique des tubes bidirectionnels.

dup(2), fcntl(2), open(2), pipe(2), poll(2), select(2), socketpair(2), stat(2), mkfifo(3), fifo(7), epoll(7)

Ce document est une traduction réalisée par Alain Portal <aportal AT univ-montp2 DOT fr> le 17 juillet 2006 et révisée le 14 août 2006.

L’équipe de traduction a fait le maximum pour réaliser une adaptation française de qualité. La version anglaise la plus à jour de ce document est toujours consultable via la commande : « LANG=C man 7 pipe ». N’hésitez pas à signaler à l’auteur ou au traducteur, selon le cas, toute erreur dans cette page de manuel.