Ubuntu Manpage: pipe – Exposé général sur les tubes et les FIFO

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.

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é.

Before Linux 2.6.11, the capacity of a pipe was the same as the system page size (e.g.,
4096 bytes on i386). Since Linux 2.6.11, the pipe capacity is 16 pages (i.e., 65,536 bytes
in a system with a page size of 4096 bytes). Since Linux 2.6.35, the default pipe capacity
is 16 pages, but the capacity can be queried and set using the fcntl(2) F_GETPIPE_SZ and
F_SETPIPE_SZ operations. See fcntl(2) for more information.

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 says that writes of less than PIPE_BUF bytes must be atomic: the output data is
written to the pipe as a contiguous sequence. Writes of more than PIPE_BUF bytes may be
nonatomic: the kernel may interleave the data with data written by other processes.
POSIX.1 requires PIPE_BUF to be at least 512 bytes. (On Linux, PIPE_BUF is 4096 bytes.)
The precise semantics depend on whether the file descriptor is nonblocking (O_NONBLOCK),
whether there are multiple writers to the pipe, and on n, the number of bytes to be
written:

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.

Setting the O_ASYNC flag for the read end of a pipe causes a signal (SIGIO by default) to
be generated when new input becomes available on the pipe. The target for delivery of
signals must be set using the fcntl(2) F_SETOWN command. On Linux, O_ASYNC is supported
for pipes and FIFOs only since 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.

(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.

This was racey. Multiple processes could pass point (1) simultaneously, and then
allocate pipe buffers that were accounted for only in step (3), with the result that
the user's pipe buffer allocation could be pushed over the limit.

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.

Before Linux 4.9, bugs similar to points (a) and (c) could also occur when the kernel
allocated memory for a new pipe buffer; that is, when calling pipe(2) and when opening a
previously unopened FIFO.

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  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  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 à ⟨debian-l10n-french@lists.debian.org⟩.