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.

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.