Provided by: manpages-fr-dev_3.27fr1.4-1_all bug

NOM

       vfork - Creer un processus fils et bloquer le pere

SYNOPSIS

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

       pid_t vfork(void);

   Exigences  de  macros  de  test de fonctionnalites 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'apres POSIX.1). La routine vfork() a le meme effet que fork(2), sauf
       que  le  comportement  est  indefini  si  le processus cree par vfork()
       effectue l'une  des  actions  suivantes  avant  d'appeler  avec  succes
       _exit(2)  ou  une  routine  de  la famille exec(3) : modification d'une
       donnee autre que la variable  de  type  pid_t  stockant  le  retour  de
       vfork(),  revenir  de  la fonction dans laquelle vfork() a ete invoque,
       appel d'une autre fonction.

   Description de l'impl'ementation Linux
       vfork(), tout comme  fork(2),  cree  un  processus  fils  a  partir  du
       processus  appelant.  Pour plus de details sur les valeurs renvoyees et
       les erreurs possibles, consultez fork(2).

       vfork() est concu comme un cas particulier de clone(2). Il sert a creer
       un  nouveau  processus  sans  effectuer  de copie de la table des pages
       memoire du processus pere. Ceci peut etre utile dans  des  applications
       necessitant  une  grande rapidite d'execution, si le fils doit invoquer
       immediatement un appel execve(2).

       vfork() differe aussi de fork(2) car le processus pere  reste  suspendu
       jusqu'a  ce  que  le  fils  se  termine  (soit normalement, en appelant
       _exit(2), soit de facon anormale apres l'envoie d'un signal  fatal)  ou
       qu'il  appelle  execve(2).  Jusqu'a  ce point, le fils partage toute la
       memoire avec son pere, 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 a la place _exit(2).

       Les gestionnaires de  signaux  sont  herites  mais  pas  partages.  Les
       signaux  pour  le processus pere sont delivres apres que le fils libere
       la memoire du pere (c'est-a-dire apres que le fils se termine ou  qu'il
       appelle execve(2)).

   Description historique
       Sous  Linux,  fork(2) est implemente en utilisant un mecanisme de copie
       en ecriture, ainsi  ses  seuls  couts  sont  le  temps  et  la  memoire
       necessaire pour dupliquer la table des pages memoire du processus pere,
       et creer une structure de tache pour le fils. Toutefois, jadis  fork(2)
       necessitait malheureusement une copie complete de l'espace d'adresse du
       pere,  souvent  inutile  car  un  appel  exec(3)  est  souvent  realise
       immediatement  par  le  fils.  Pour  ameliorer  les performances, BSD a
       introduit  un  appel  systeme  vfork()  qui  ne  copie   pas   l'espace
       d'adressage  du pere, mais emprunte au parent son espace d'adressage et
       son fil de controle jusqu'a un appel a execve(2) ou exit. Le  processus
       pere  etait  suspendu  tant  que  le  fils  utilisait  les  ressources.
       L'utilisation de vfork() etait loin d'etre facile, car pour  eviter  de
       modifier  les  donnees  du  processus  pere, il fallait etre capable de
       determiner quelles  variables  se  trouvaient  dans  des  registres  du
       processeur.

CONFORMIT'E

       BSD 4.3,   POSIX.1-2001.  POSIX.1-2008  supprime  la  specification  de
       vfork(). Les exigences que les standards  apportent  sur  vfork()  sont
       plus  relachees  que  celles sur fork(2), ainsi il est possible d'avoir
       une implementation conforme ou  les  deux  appels  sont  synonymes.  En
       particulier,  un  programmeur  ne doit pas s'appuyer sur le fait que le
       pere reste bloque  jusqu'a  ce  que  le  fils  se  termine  ou  appelle
       execve(2), ni sur le comportement par rapport a la memoire partagee.

NOTES

   Notes sur Linux
       Les  gestionnaires  enregistres  avec  pthread_atfork(3)  ne  sont  pas
       appeles lorsqu'un programme multithreade utilisant la  bibliotheque  de
       threads  NPTL  appelle  vfork().  En  revanche  ces  gestionnaires sont
       appeles  si  le  programme  utilise   la   bibliotheque   LinuxThreads.
       (Consultez  pthreads(7)  pour  une  description  des  bibliotheques  de
       threads pour Linux.)

   Historique
       L'appel systeme vfork() est apparu dans BSD 3.0. Dans BSD 4.4,  il  est
       devenu  synonyme  de  fork(2),  mais  NetBSD  l'a reintroduit a nouveau
       (consultez http://www.netbsd.org/Documentation/kernel/vfork.html). Sous
       Linux,  il  fut  l'equivalent  de  fork(2)  jusqu'au noyau 2.2.0-pre-6.
       Depuis le 2.2.0-pre-9 il s'agit  d'un  appel  systeme  independant.  Le
       support dans la bibliotheque a ete introduit dans la glibc 2.0.112.

BOGUES

       Il  est  regrettable  que  Linux ait ressuscite ce spectre du passe. La
       page de manuel de BSD indique que << cet appel  systeme  sera  supprime
       quand  des  mecanismes  de partage appropries seront implementes. Il ne
       faut pas essayer de tirer profit du partage memoire induit par vfork(),
       car dans ce cas il sera rendu synonyme de fork(2) >>.

       Les  details  de  la  gestion  des  signaux sont compliques, et varient
       suivant les systemes. La page de manuel BSD  indique :  << Pour  eviter
       une  possible situation d'interblocage, les processus qui sont des fils
       au milieu d'un  vfork()  ne  recoivent  jamais  le  signal  SIGTTOU  ou
       SIGTTIN ;  des sorties et des ioctl sont autorises, 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.27  du  projet  man-pages
       Linux.  Une description du projet et des instructions pour signaler des
       anomalies      peuvent      etre       trouvees       a       l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

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

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

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

       Vous pouvez toujours avoir acces a la version anglaise de  ce  document
       en utilisant la commande << man -L C <section> <page_de_man> >>.