Loading

NOM

       pipe - Panorama des tubes et des FIFO

       Les  tubes  et  les  FIFO  (ou  tubes  nommés)  fournissent un canal de
       communication interprocessus unidirectionnel. Un tube a une  entre  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 liés ; voir pipe(2)
       pour un exemple.

       Un FIFO (abréviation de First In First Out) a un nom sur le système  de
       fichiers  (créé  avec  mkfifo(3)),  et  est  ouvert  avec open(2). Tout
       processus  peut  ouvrir  un  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. Voir 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  un  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  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 doctets : 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.

   Capacité dun 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, 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.

   PIPE_BUF
       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 fixe 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
       sur le tube (voir 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.

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

VOIR AUSSI

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

COLOPHON

       Cette  page  fait  partie  de  la  publication 3.23 du projet man-pages
       Linux. Une description du projet et des instructions pour signaler  des
       anomalies       peuvent       être       trouvées      à      l’adresse
       http://www.kernel.org/doc/man-pages/.

TRADUCTION

       Cette page de manuel a été traduite  et  mise  à  jour  par  Christophe
       Blaess  <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
       Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et  mise  à
       disposition sur http://manpagesfr.free.fr/.

       Les mises à jour et corrections de la version présente dans Debian sont
       directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
       francophone de traduction de Debian.

       Veuillez   signaler   toute   erreur   de   traduction  en  écrivant  à
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
       paquet manpages-fr.

       Vous  pouvez  toujours avoir accès à la version anglaise de ce document
       en utilisant la commande « man -L C <section> <page_de_man> ».