VFORK(2)

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 fonctionalité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. Le processus fils ne doit donc pas revenir de la fonction en cours, ni invoquer une nouvelle routine. Il ne doit pas appeler exit(2), 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 le partage avec le fils. 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 « threading » 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. 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 synomyme de fork(2). Les détails de la gestion des signaux sont compliqués, et varient suivant les systèmes. La page de manuel indique : « Pour éviter de possibles situations de blocage, les processus qui ont 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 19 décembre 2007.

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.