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