Provided by: manpages-fr-dev_3.65d1p1-1_all bug

NOM

       vfork - Créer un processus fils et bloquer le père

SYNOPSIS

       #include <sys/types.h>
       #include <unistd.h>

       pid_t vfork(void);

   Exigences    de    macros    de   test   de   fonctionnalités   pour   la   glibc   (consultez
   feature_test_macros(7)) :

       vfork() :
           Depuis la glibc 2.12 :
               _BSD_SOURCE ||
                   (_XOPEN_SOURCE >= 500 ||
                       _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED) &&
                   !(_POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700)
           Avant la glibc 2.12 : _BSD_SOURCE || _XOPEN_SOURCE >= 500 ||
               _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED

DESCRIPTION

   Description des normes
       (D'après POSIX.1).  La  routine  vfork()  a  le  même  effet  que  fork(2),  sauf  que  le
       comportement  est  indéfini  si  le  processus créé par vfork() effectue l'une des actions
       suivantes avant d'appeler avec succès _exit(2) ou une  routine  de  la  famille  exec(3) :
       modification  d'une  donnée  autre  que  la  variable  de type pid_t stockant le retour de
       vfork(), revenir de la fonction dans laquelle vfork() a été  invoqué,  appel  d'une  autre
       fonction.

   Description de l'implémentation Linux
       vfork(),  tout  comme fork(2), crée un processus fils à partir du processus appelant. Pour
       plus de détails sur les valeurs renvoyées et les erreurs possibles, consultez fork(2).

       vfork() est conçu comme un cas particulier  de  clone(2).  Il  sert  à  créer  un  nouveau
       processus  sans  effectuer  de copie de la table des pages mémoire du processus père. Ceci
       peut être utile dans des applications nécessitant une grande rapidité d'exécution,  si  le
       fils doit invoquer immédiatement un appel execve(2).

       vfork()  diffère  aussi de fork(2) car le thread appelant reste suspendu jusqu'à ce que le
       fils se termine (soit normalement, en appelant _exit(2),  soit  de  façon  anormale  après
       l'envoie  d'un signal fatal) ou qu'il appelle execve(2). Jusqu'à ce point, le fils partage
       toute la mémoire avec son père, y compris la pile. Le processus  fils  ne  doit  donc  pas
       revenir  de la fonction en cours, ni invoquer une nouvelle routine. Il ne doit pas appeler
       exit(3), mais à la place _exit(2).

       Comme avec fork(2), le processus fils créé par vfork()  hérite  des  copies  de  plusieurs
       attributs   du   processus  appelant  (par  exemple  les  descripteurs  de  fichiers,  les
       dispositions des signaux et le répertoire de travail actuel) ;  l'appel  vfork()   diffère
       seulement par le traitement de l'espace d'adressage virtuel, comme décrit ci-dessus.

       Les  signaux  pour  le processus père sont délivrés après que le fils libère la mémoire du
       père (c'est-à-dire après que le fils se termine ou qu'il appelle execve(2)).

   Description historique
       Sous Linux, fork(2) est implémenté en utilisant un mécanisme de copie en  écriture,  ainsi
       ses  seuls  coûts sont le temps et la mémoire nécessaire pour dupliquer la table des pages
       mémoire du processus père, et créer une structure de tâche pour le fils. Toutefois,  jadis
       fork(2)  nécessitait  malheureusement  une  copie  complète de l'espace d'adresse du père,
       souvent inutile car un appel exec(3) est souvent réalisé immédiatement par le  fils.  Pour
       améliorer  les  performances,  BSD  a  introduit un appel système vfork() qui ne copie pas
       l'espace d'adressage du père, mais emprunte au parent son espace d'adressage et son fil de
       contrôle  jusqu'à  un appel à execve(2) ou exit. Le processus père était suspendu tant que
       le fils utilisait les ressources. L'utilisation de vfork() était loin d'être  facile,  car
       pour  éviter  de  modifier  les  données  du  processus  père,  il fallait être capable de
       déterminer quelles variables se trouvaient dans des registres du processeur.

CONFORMITÉ

       BSD 4.3, POSIX.1-2001 (mais la déclare obsolète). POSIX.1-2008 supprime  la  spécification
       de vfork().

       Les  exigences  que les standards apportent sur vfork() sont plus relâchées que celles sur
       fork(2), ainsi il est possible d'avoir une implémentation conforme où les deux appels sont
       synonymes.  En  particulier,  un programmeur ne doit pas s'appuyer sur le fait que le père
       reste bloqué jusqu'à  ce  que  le  fils  se  termine  ou  appelle  execve(2),  ni  sur  le
       comportement par rapport à la mémoire partagée.

NOTES

       Certaines  personnes considèrent la sémantique de vfork() comme une verrue architecturale,
       et la page de manuel de BSD 4.2 indique que « cet appel système sera  supprimé  quand  des
       mécanismes  de  partage  appropriés  seront  implémentés.  Il ne faut pas essayer de tirer
       profit du partage mémoire induit par vfork(), car dans ce cas il sera  rendu  synonyme  de
       fork(2) ».  Cependant,  même  si  le  matériel  de  gestion  mémoire matériel a diminué la
       différence de performances entre fork(2) et  vfork(),  il  existe  diverses  raisons  pour
       lesquelles Linux et d'autres systèmes ont conservé vfork() :

       *  Certaines  applications  de  haute  performance  ont  besoin  du petit gain apporté par
          vfork().

       *  vfork() peut être implémenté sur des systèmes sans unité de gestion mémoire (MMU,  pour
          « memory-management  unit »),  mais  fork(2)  ne  peut  pas être implémenté sur de tels
          systèmes (POSIX.1-2008 a supprimé vfork() de la norme ; la raison  invoquée  par  POSIX
          pour la fonction posix_spawn(3) note que cette fonction, qui fournit une fonctionnalité
          équivalente à fork(2)+exec(3), est conçue pour être implémentable sur des systèmes sans
          MMU).

   Notes sur Linux
       Les  gestionnaires  enregistrés  avec  pthread_atfork(3)  ne  sont  pas  appelés lorsqu'un
       programme multithreadé utilisant la bibliothèque  de  threads  NPTL  appelle  vfork().  En
       revanche   ces  gestionnaires  sont  appelés  si  le  programme  utilise  la  bibliothèque
       LinuxThreads. (Consultez pthreads(7) pour une description  des  bibliothèques  de  threads
       pour Linux.)

       Un appel à vfork()  est équivalent à appeler clone(2)  avec flags valant :

            CLONE_VM | CLONE_VFORK | SIGCHLD

   Historique
       L'appel  système  vfork() est apparu dans BSD 3.0. Dans BSD 4.4, il est devenu synonyme de
       fork(2),  mais  NetBSD  l'a  réintroduit  à  nouveau   (consultez   ⟨http://www.netbsd.org
       /Documentation/kernel/vfork.html⟩).  Sous  Linux,  il fut l'équivalent de fork(2) jusqu'au
       noyau 2.2.0-pre-6. Depuis le 2.2.0-pre-9 il s'agit  d'un  appel  système  indépendant.  Le
       support dans la bibliothèque a été introduit dans la glibc 2.0.112.

BOGUES

       Les détails de la gestion des signaux sont compliqués, et varient suivant les systèmes. La
       page de manuel BSD indique : « Pour éviter  une  possible  situation  d'interblocage,  les
       processus  qui  sont des fils au milieu d'un vfork() ne reçoivent jamais le signal SIGTTOU
       ou SIGTTIN ; des sorties et des ioctl sont  autorisés,  mais  des  tentatives  de  lecture
       donneront une indication de fin de fichier. »

VOIR AUSSI

       clone(2), execve(2), fork(2), unshare(2), wait(2)

COLOPHON

       Cette  page  fait partie de la publication 3.65 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

       Depuis    2010,    cette   traduction   est   maintenue   à   l'aide   de   l'outil   po4a
       <http://po4a.alioth.debian.org/> par l'équipe de traduction francophone au sein du  projet
       perkamon <http://perkamon.alioth.debian.org/>.

       Christophe    Blaess    <http://www.blaess.fr/christophe/>   (1996-2003),   Alain   Portal
       <http://manpagesfr.free.fr/>  (2003-2006).  Julien  Cristau  et  l'équipe  francophone  de
       traduction de Debian (2006-2009).

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