Provided by: manpages-fr-dev_3.17.1-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 (voir
   feature_test_macros(7)) :

       vfork() : _BSD_SOURCE || _XOPEN_SOURCE >= 500

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 limplé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, voir 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 processus père  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).

       Les gestionnaires de  signaux  sont  hérités  mais  pas  partagés.  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.  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

   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.  (Voir
       pthreads(7)  pour  une  description  des  bibliothèques de threads pour
       Linux.)

   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

       Il  est  regrettable  que  Linux ait ressuscité ce spectre du passé. La
       page de manuel de BSD 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) ».

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