pipe
Table des matières
Retour à l'index
NOM
pipe – Exposé général sur les tubes et les FIFO
DESCRIPTION
Les tubes et les FIFO (ou tubes nommés) fournissent un canal de
communication interprocessus unidirectionnel. Un tube a une entrée et une
sortie. Les données écrites à l'entrée du tube peuvent être lues à sa
sortie.
Un tube est créé avec l'appel système pipe(2) qui crée un nouveau tube et
renvoie deux descripteurs de fichier, l'un correspondant à l'entrée du tube
et l'autre à la sortie. Les tubes peuvent être utilisés pour créer un canal
de communication entre des processus associés ; consultez pipe(2) pour
un exemple.
Une file d’attente FIFO (abréviation de « First In First Out » ou premier
entré, premier sorti) a un nom sur le système de fichiers (créé avec
mkfifo(3)) et est ouverte avec open(2). Tout processus peut ouvrir une
FIFO si les permissions du fichier l'autorisent. La sortie est ouverte avec
l'option O_RDONLY ; l'entrée est ouverte avec l'option
O_WRONLY. Consultez fifo(7) pour plus de détails. Note : même si
les FIFO ont un nom sur le système de fichiers, les entrées/sorties sur une
FIFO n'impliquent pas d'opérations sur le périphérique sous-jacent (s'il
y en a un).
E/S 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 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-dessous), write(2) bloque jusqu'à
ce que suffisamment de données aient été lues dans le tube pour 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 d’état de fichier ouvert
ou en ouvrant une fifo(7) avec O_NONBLOCK. Si le tube d'un processus
est ouvert en écriture, les lectures échoue avec une erreur EAGAIN ;
autrement, sans processus écrivant potentiel, les lectures réussissent et ne
renvoient rien.
Le canal de communication fourni par un tube est un flux d'octets : il
n'y a pas de notion de limite de 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 ; cela permet d'assurer que la condition de fin de ficher et
SIGPIPE/EPIPE soient renvoyés correctement.
Il n'est pas possible d'invoquer 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, selon que l'attribut O_NONBLOCK est activé ou non
(voir ci-dessous). 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 de manière à ce qu'un processus
écrivant ne soit pas bloqué.
Avant Linux 2.6.11, la capacité d'un tube était la même que la taille d'une
page système (par exemple 4 096 octets sur i386). Depuis Linux 2.6.11, la
capacité d'un tube est par défaut de 16 pages (c’est-à-dire 65 536 octets
sur un système avec 4 096 octets comme taille de page). Depuis Linux 2.6.35,
la capacité d’un tube est de 16 pages, mais la capacité peut être recherchée
et définie en utilisant les opérations F_GETPIPE_SZ et F_SETPIPE_SZ de
fcntl(2). Consultez fcntl(2) pour davantage d’informations.
L’opération ioctl(2) suivante, qui peut être appliquée à un descripteur
de fichier faisant référence à n’importe quelle extrémité du tube, place un
certain nombre d’octets non lus dans le tube dans le tampon int pointé
par le dernier argument de l’appel :
ioctl(fd, FIONREAD, &nbytes);
L’opération FIONREAD n’est précisée dans aucune norme, mais est fournie
dans beaucoup d’implémentations.
Fichiers /proc
Dans Linux, les fichiers suivants contrôlent la quantité de mémoire pouvant
être utilisée pour les tubes :
- /proc/sys/fs/pipe-max-pages (uniquement pour Linux 2.6.34)
-
Une limite supérieure, en nombre de pages, sur la quantité qu’un utilisateur
non privilégié (n’ayant pas la capacité CAP_SYS_RESOURCE) peut être
définie pour un tube.
-
La valeur par défaut pour cette limite est de 16 fois la quantité par défaut
pour le tube (voir ci-dessus). La limite basse est de deux pages.
-
Cette interface a été supprimée dans Linux 2.6.35, en faveur de
/proc/sys/fs/pipe-max-size.
- /proc/sys/fs/pipe-max-size (depuis Linux 2.6.35)
-
La taille maximale (en octet) de tubes particuliers pouvant être définie par
les utilisateurs n’ayant pas la capacité CAP_SYS_RESOURCE. La valeur
assignée dans ce fichier peut être arrondie à la valeur supérieure pour
refléter la valeur réellement employée pour une mise en œuvre pratique. Pour
déterminer cette valeur arrondie, affichez le contenu de ce fichier après
lui avoir assigné une valeur.
-
La valeur par défaut pour ce fichier est 1 048 576 (1 Mibit). La valeur
minimale qui peut être assignée à cette page est la taille de page du
système. Un essai d’une limite inférieure à cette taille de page provoque
l’échec de write(2) avec l’erreur EINVAL.
-
Depuis Linux 4.9, la valeur dans ce fichier agit comme un plafond pour la
capacité par défaut pour un nouveau tube ou une FIFO nouvellement ouverte.
- /proc/sys/fs/pipe-user-pages-hard (depuis Linux 4.5)
-
La limite dure de la taille totale (en nombre de pages) de tous les tubes
créés ou définis par un utilisateur particulier non privilégié (c’est-à-dire
n’ayant ni la capacité CAP_SYS_RESOURCE ni la capacité
CAP_SYS_ADMIN). Aussi longtemps que le nombre total de pages allouées
pour les tampons de tube pour cet utilisateur est à cette limite, les essais
pour créer de nouveaux tubes n’aboutiront pas et les essais pour augmenter
la capacité de tube n’aboutiront pas.
-
Quand la valeur de cette limite est zéro (comportement par défaut ), aucune
limite dure n’est appliquée.
- /proc/sys/fs/pipe-user-pages-soft (depuis Linux 4.5)
-
La limite douce de la taille totale (en nombre de pages) de tous les tubes
créés ou définis par un utilisateur particulier non privilégié (c’est-à-dire
n’ayant ni la capacité CAP_SYS_RESOURCE ni la capacité
CAP_SYS_ADMIN). Aussi longtemps que le nombre total de pages allouées
pour les tampons de tube pour cet utilisateur est à cette limite, les tubes
individuels créés par l’utilisateur seront limités à une page et les essais
pour augmenter la capacité de tube n’aboutiront pas.
-
Quand la valeur de cette limite est zéro, aucune limite douce n’est
appliquée. La valeur par défaut dans ce fichier est 16 384 qui permet de
créer jusqu’à 1 024 tubes avec la capacité par défaut.
Avant Linux 4.9, quelques bogues affectaient la gestion des limites
pipe-user-pages-soft et pipe-user-pages-hard. Consultez la section
BOGUES.
PIPE_BUF
POSIX.1-2001 indique que les écritures de moins de PIPE_BUF octets
doivent être atomiques : les données produites sont écrites dans le tube
de façon contiguë. Les écritures de plus de PIPE_BUF octets 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 de 512 octets ; sous Linux, PIPE_BUF vaut 4 096 octets. La
sémantique précise dépend de l'attribut non bloquant du descripteur de
fichier (O_NONBLOCK), du nombre de processus écrivant 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.
Attributs d'état de fichier ouvert
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
dans le tube. La cible de réception du signal doit être définie en utilisant
la commande F_SETOWN de fcntl(2). Sous Linux, O_ASYNC n'est
possible sur les tubes et les FIFO que depuis Linux 2.6.
Notes sur la portabilité
Sur certains systèmes (mais pas sous Linux), les tubes sont bidirectionnels : des données peuvent être transmises dans les deux directions entre les
extrémités 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.
BOGUES
Avant Linux 4.9, quelques bogues affectaient la gestion des limites
pipe-user-pages-soft et pipe-user-pages-hard lors de l’utilisation de
l’opération F_SETPIPE_SZ de fcntl(2) pour modifier la capacité d’un
tube :
- (a)
-
Lors de l’augmentation de la capacité du tube, les vérifications sur les
limites douce et dure sont faites sur la consommation existante et excluent
la mémoire nécessaire pour la capacité augmentée du tube. La nouvelle
augmentation de capacité du tube pourrait pousser la mémoire totale utilisée
par l’utilisateur pour les tubes au-dessus (possiblement très au delà) de la
limite. Cela pourrait aussi déclencher le problème exposé ci-après.
-
Depuis Linux 4.9, la vérification de limite inclut la mémoire nécessaire
pour la nouvelle capacité de tube.
- (b)
-
Les vérifications de limite sont réalisées même si la nouvelle capacité du
tube est inférieure à la capacité du tube existant. Cela pourrait conduire à
des problèmes si un utilisateur définit une capacité importante de tube et
que les limites sont abaissées, avec comme résultat que l’utilisateur ne
pourrait plus abaisser la capacité du tube.
-
Depuis Linux 4.9, les vérifications des limites sont réalisées uniquement
lors de l’augmentation de capacité de tube. Un utilisateur non privilégié
peut toujours diminuer la capacité de tube.
- (c)
-
La prise en compte et la vérification sur les limites sont faites comme
suit :
-
- (1)
-
Test pour savoir si l’utilisateur a dépassé la limite.
- (2)
-
Allocation du tampon pour le nouveau tube.
- (3)
-
Comparaison de la nouvelle allocation avec les limites.
-
Cela est risqué. Plusieurs processus peuvent passer le point (1)
simultanément et puis allouer des tampons de tube qui sont pris en compte
lors de l’étape (3), avec comme résultat que l’allocation du tampon de tube
de l’utilisateur peut dépasser la limite.
-
Depuis Linux 4.9, l’étape de prise en compte est réalisée avant l’allocation
et l’opération échoue si la limite est dépassée.
Avant Linux 4.9, des bogues similaires aux points (a) et (c) pourraient se
produire quand le noyau alloue de la mémoire pour le nouveau tampon de tube,
c’est-à-dire lors de l’appel pipe(2) et lors de l’ouverture d’une
nouvelle FIFO précédemment non ouverte.
VOIR AUSSI
mkfifo(1), dup(2), fcntl(2), open(2), pipe(2), poll(2),
select(2), socketpair(2), splice(2), stat(2), tee(2),
vmsplice(2), mkfifo(3), epoll(7), fifo(7)
TRADUCTION
La traduction française de cette page de manuel a été créée par
Christophe Blaess <https://www.blaess.fr/christophe/>,
Stéphan Rafin <stephan.rafin@laposte.net>,
Thierry Vignaud <tvignaud@mandriva.com>,
François Micaux,
Alain Portal <aportal@univ-montp2.fr>,
Jean-Philippe Guérard <fevrier@tigreraye.org>,
Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>,
Julien Cristau <jcristau@debian.org>,
Thomas Huriaux <thomas.huriaux@gmail.com>,
Nicolas François <nicolas.francois@centraliens.net>,
Florentin Duneau <fduneau@gmail.com>,
Simon Paillard <simon.paillard@resel.enst-bretagne.fr>,
Denis Barbier <barbier@debian.org>,
David Prévot <david@tilapin.org>,
Cédric Boutillier <cedric.boutillier@gmail.com>,
Frédéric Hantrais <fhantrais@gmail.com>
et
Jean-Paul Guillonneau <guillonneau.jeanpaul@free.fr>
Cette traduction est une documentation libre ; veuillez vous reporter à la
GNU General Public License version 3
concernant les conditions de copie et
de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message à
Index
- NOM
-
- DESCRIPTION
-
- E/S sur les tubes et les FIFO
-
- Capacité d'un tube
-
- Fichiers /proc
-
- PIPE_BUF
-
- Attributs d'état de fichier ouvert
-
- Notes sur la portabilité
-
- BOGUES
-
- VOIR AUSSI
-
- TRADUCTION
-
This document was created by
man2html,
using the manual pages.
Time: 05:06:38 GMT, September 19, 2025