Provided by: manpages-fr-dev_3.57d1p1-1_all 
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.57 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> ».