VFORK
Section : Manuel du programmeur Linux (
2)
Mise à jour de la version anglaise : 26 juillet 2007
Index
Menu principal
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 standard
(D'après SUSv2 / draft POSIX).
L'appel système
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 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 invoque
execve(2),
ou
_exit(2).
Le fils partage toute la mémoire avec son père, y compris la pile,
jusqu'à ce que
execve(2)
soit appelé par le fils.
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
ait mis à jour la mémoire du père.
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 père son espace d'adressage et son fil de contrôle
jusqu'à un appel à
execev(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.
Les contraintes que les standards apportent sur l'appel
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'à un appel
execve(2),
ou
_exit(2),
ni sur le comportement de la mémoire partagée.
NOTES
Notes Linux
Les gestionnaires de bifurcation établis en utilisant
pthread_atfork(3)
ne sont pas appelés lorsqu'un programme multithreadé utilise les appels
vfork()
de la bibliothèque de thread NPTL.
Les gestionnaires de bifurcation sont appelés dans ce cas
dans un programme qui utilise la bibliothèque de gestion des threads
LinuxThreads.
(Voir
pthreads(7)
pour une description des bibliothèques de « threading » 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 : voir
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,
et qu'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 de possibles situations de blocage,
les processus qui sont des fils au milieu d'un
vfork()
ne reçoivent jamais les signaux
SIGTTOU
ou
SIGTTIN ;
à la place, des sorties ou des requêtes
iotcl
sont autorisées et des tentatives d'entrées
indiqueront une fin de fichier. »
VOIR AUSSI
clone(2),
execve(2),
fork(2),
unshare(2),
wait(2)
TRADUCTION
Ce document est une traduction réalisée par Christophe Blaess
<http://www.blaess.fr/christophe/> le 9 octobre 1996
et révisée le 23 juin 2008.
L'équipe de traduction a fait le maximum pour réaliser une adaptation
française de qualité. La version anglaise la plus à jour de ce document est
toujours consultable via la commande : « LANG=C man 2 vfork ».
N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute
erreur dans cette page de manuel.
Index
- NOM
-
- SYNOPSIS
-
- DESCRIPTION
-
- Description standard
-
- Description Linux
-
- Description historique
-
- CONFORMITÉ
-
- NOTES
-
- Notes Linux
-
- Historique
-
- BOGUES
-
- VOIR AUSSI
-
- TRADUCTION
-
Dernière mise à jour : 23 juin 2008