Man page 7 : pipe

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 E/S sur les tubes et les FIFO ont strictement les mêmes sémantiques. Si un processus essaie de lire dans un tube vide, read(2) bloquera jusqu'à ce que des données soient disponibles. Si un processus essaie d'écrire dans un tube plein (voir ci(hydessous), write(2) bloque jusqu'à ce que suffisamment de données aient été lues dans le tube avant de permettre la réussite de l'écriture. Des E/S non bloquantes sont possibles en utilisant l'opération F_SETFL de fcntl(2) pour activer l'attribut O_NONBLOCK. Le canal de communication fourni par un tube est un flot d'octets : il n'y a pas de notion de limite entre messages. Si tous les descripteurs de fichier correspondant à l'entrée d'un tube sont fermés, une tentative de lecture sur le tube renverra une condition de fin de fichier (read(2) renverra 0). Si tous les descripteurs de fichier correspondant à la sortie d'un tube sont fermés, une tentative d'écriture provoquera l'envoi du signal SIGPIPE au processus appelant. Si le processus appelant ignore ce signal, write(2) échoue avec l'erreur EPIPE. Une application utilisant pipe(2) et fork(2) doit utiliser des appels à close(2) afin de fermer les descripteurs de fichier superflus ; ceci permet d'assurer que la condition de fin de ficher et SIGPIPE/EPIPE sont renvoyés correctement. Il n'est pas possible d'invoquer lseek(2) sur un tube.

Un tube a une capacité limitée. Si le tube est plein, un write(2) bloquera ou échouera, selon que l'attribut O_NONBLOCK est activé ou non (voir ci(hydessous). Différentes implémentations ont différentes limites de capacité des tubes. Les applications ne doivent pas dépendre d'une capacité particulière, mais être conçues pour qu'un processus lecteur lise les données dès qu'elles sont disponibles, pour qu'un processus écrivain ne soit pas bloqué. Dans les versions de Linux antérieures à 2.6.11, la capacité d'un tube était la taille d'une page système (p.ex. 4096 octets sur i386). Depuis Linux 2.6.11, la capacité d'un tube est de 65536 octets.

POSIX.1-2001 indique que les écritures de moins que PIPE_BUF octets doivent être atomiques : les données sont écrites dans le tube de façon contiguë. Les écritures de plus que PIPE_BUF peuvent ne pas être atomiques : le noyau peut entrelacer les données avec des données écrites par d'autres processus. POSIX.1-2001 demande que PIPE_BUF soit au moins 512 octets. (Sous Linux, PIPE_BUF vaut 4096 octets.) La sémantique précise dépend de l'attribut non-bloquant du descripteur de fichier (O_NONBLOCK), du nombre d'écrivains dans le tube, et de n, le nombre d'octets à écrire :

• O_NONBLOCK désactivé, n <= PIPE_BUF
      Les n octets sont écrits de manière atomique ; write(2) peut bloquer s'il n'y a pas de place pour écrire n octets immédiatement.
• O_NONBLOCK activé, n <= PIPE_BUF
      S'il y a la place d'écrire n octets dans le tube, write(2) réussit immédiatement, en écrivant les n octets ; sinon, write(2) échoue, et définit errno à EAGAIN.
• O_NONBLOCK désactivé, n > PIPE_BUF
      L'écriture est non atomique : les données fournies à write(2) peuvent être entrelacées avec des écritures d'autres processus ; l'écriture bloque jusqu'à ce que n octets aient été écrits.
• O_NONBLOCK activé, n > PIPE_BUF
      Si le tube est plein, write(2) échoue, en plaçant errno à EAGAIN. Sinon, entre 1 et n octets peuvent être écrits (une « écriture partielle » peut se produire ; l'appelant doit vérifier la valeur de retour de write(2) pour voir combien d'octets ont réellement été écrits), et ces octets peuvent être entrelacés avec des écritures d'autres processus.

Les seuls attributs d'état de fichier ouvert qui peuvent s'appliquer aux tubes et aux FIFO sont O_NONBLOCK et O_ASYNC. Activer l'attribut O_ASYNC à la sortie d'un tube provoque l'envoi d'un signal (SIGIO par défaut) lorsque de nouvelles données sont disponibles sur le tube (consultez fcntl(2) pour les détails). Sous Linux, O_ASYNC n'est possible sur les tubes et les FIFO que depuis le noyau 2.6.

Sur certains systèmes (mais pas sous Linux), les tubes sont bidirectionnels : des données peuvent être transmises dans les deux directions entre les bouts du tube. Selon POSIX.1-2001, les tubes sont uniquement décrits comme unidirectionnels. Les applications portables doivent éviter de s'appuyer sur une sémantique bidirectionnelle des tubes.