.\" -*- coding: UTF-8 -*- .\" Copyright (c) 1999 Andries Brouwer (aeb@cwi.nl), 1 Nov 1999 .\" and Copyright 2006, 2012, 2017 Michael Kerrisk .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" 1999-11-10: Merged text taken from the page contributed by .\" Reed H. Petty (rhp@draper.net) .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH vfork 2 "5 février 2023" "Pages du manuel de Linux 6.03" .SH NOM vfork \- Créer un processus enfant et bloquer le parent .SH BIBLIOTHÈQUE Bibliothèque C standard (\fIlibc\fP, \fI\-lc\fP) .SH SYNOPSIS .nf \fB#include \fP .PP \fBpid_t vfork(void);\fP .fi .PP .RS -4 Exigences de macros de test de fonctionnalités pour la glibc (consulter \fBfeature_test_macros\fP(7))\ : .RE .PP \fBvfork\fP()\ : .nf .\" || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED Depuis la glibc 2.12 : (_XOPEN_SOURCE >= 500) && ! (_POSIX_C_SOURCE >= 200809L) || /* Depuis la glibc 2.19 : */ _DEFAULT_SOURCE || /* glibc <= 2.19 : */ _BSD_SOURCE Avant la glibc 2.12 : _BSD_SOURCE || _XOPEN_SOURCE >= 500 .fi .SH DESCRIPTION .SS "Description des normes" (D'après POSIX.1). La routine \fBvfork\fP() a le même effet que \fBfork\fP(2), sauf que le comportement est indéfini si le processus créé par \fBvfork\fP() effectue l'une des actions suivantes avant d'appeler avec succès \fB_exit\fP(2) ou une routine de la famille \fBexec\fP(3)\ : modification d'une donnée autre que la variable de type \fIpid_t\fP stockant le retour de \fBvfork\fP(), revenir de la fonction dans laquelle \fBvfork\fP() a été invoqué, appel d'une autre fonction. .SS "Description de l'implémentation Linux" \fBvfork\fP(), tout comme \fBfork\fP(2), crée un processus enfant à partir du processus appelant. Pour plus de détails sur les valeurs renvoyées et les erreurs possibles, consultez \fBfork\fP(2). .PP \fBvfork\fP() est conçu comme un cas particulier de \fBclone\fP(2). Il sert à créer un nouveau processus sans effectuer de copie de la table des pages mémoire du processus parent. Cela peut être utile dans des applications nécessitant une grande rapidité d'exécution, si l'enfant doit invoquer immédiatement un appel \fBexecve\fP(2). .PP \fBvfork\fP() diffère de \fBfork\fP(2) en ce que le thread appelant reste suspendu jusqu'à ce que l'enfant se termine (soit normalement, en appelant \fB_exit\fP(2), soit de façon anormale après l'envoi d'un signal fatal) ou qu'il appelle \fBexecve\fP(2). Jusqu'à ce point, l'enfant partage toute la mémoire avec son parent, y compris la pile. Le processus enfant ne doit pas revenir de la fonction en cours, ni appeler \fBexit\fP(3) (ce qui aurait pour effet d'appeler les gestionnaires de sortie établis par le processus parent et de vider les tampons \fBstdio\fP(3) du parent), mais appeler à \fB_exit\fP(2). .PP Comme avec \fBfork\fP(2), le processus enfant créé par \fBvfork\fP() 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 \fBvfork\fP() diffère seulement par le traitement de l'espace d'adressage virtuel, comme décrit ci\-dessus. .PP Les signaux pour le processus parent sont délivrés après que l'enfant libère la mémoire du parent (c'est\-à\-dire après que l'enfant se termine ou qu'il appelle \fBexecve\fP(2)). .SS "Description historique" Sous Linux, \fBfork\fP(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 parent, et créer une seulestructure de tâche pour l'enfant. Toutefois, jadis \fBfork\fP(2) nécessitait malheureusement une copie complète de l'espace de données du parent, souvent inutilement, car un appel \fBexec\fP(3) est souvent réalisé immédiatement par l'enfant. Pour améliorer les performances, BSD a introduit un appel système \fBvfork\fP() qui ne copie pas l'espace d'adressage du parent, mais emprunte au parent son espace d'adressage et son fil de contrôle jusqu'à un appel à \fBexecve\fP(2) ou qu'une sortie survienne. Le processus parent était suspendu tant que l'enfant utilisait les ressources. L'utilisation de \fBvfork\fP() était loin d'être facile, car, pour éviter de modifier les données du processus parent, il fallait être capable de déterminer quelles variables se trouvaient dans des registres du processeur. .SH STANDARDS 4.3BSD, POSIX.1\-2001 (mais la déclare obsolète). POSIX.1\-2008 supprime la spécification de \fBvfork\fP(). .PP .\" In AIXv3.1 vfork is equivalent to fork. Les exigences que les normes apportent sur \fBvfork\fP() sont plus relâchées que celles sur \fBfork\fP(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 parent reste bloqué jusqu'à ce que l'enfant se termine ou appelle \fBexecve\fP(2), ni sur le comportement par rapport à la mémoire partagée. .SH NOTES Certaines personnes considèrent la sémantique de \fBvfork\fP() comme une verrue architecturale, et la page de manuel de 4.2BSD 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 \fBvfork\fP(), car dans ce cas il serait rendu synonyme de \fBfork\fP(2)\ ». Cependant, même si le matériel de gestion mémoire moderne a diminué la différence de performances entre \fBfork\fP(2) et \fBvfork\fP(), il existe diverses raisons pour lesquelles Linux et d'autres systèmes ont conservé \fBvfork\fP()\ : .IP \[bu] 3 Certaines applications de haute performance ont besoin du petit gain apporté par \fBvfork\fP(). .IP \[bu] .\" http://stackoverflow.com/questions/4259629/what-is-the-difference-between-fork-and-vfork .\" http://developers.sun.com/solaris/articles/subprocess/subprocess.html .\" http://mailman.uclinux.org/pipermail/uclinux-dev/2009-April/000684.html .\" \fBvfork\fP() peut être implémenté sur des systèmes sans unité de gestion mémoire (MMU, pour «\ memory\-management unit\ »), mais \fBfork\fP(2) ne peut pas être implémenté sur de tels systèmes (POSIX.1\-2008 a supprimé \fBvfork\fP() de la norme\ ; la raison invoquée par POSIX pour la fonction \fBposix_spawn\fP(3) note que cette fonction, qui fournit une fonctionnalité équivalente à \fBfork\fP(2)+\fBexec\fP(3), est conçue pour être implémentable sur des systèmes sans MMU). .IP \[bu] .\" Sur les systèmes où la mémoire est restreinte, \fBvfork\fP évite le besoin d'allouer de la mémoire temporairement (voir la description de \fI/proc/sys/vm/overcommit_memory\fP dans \fBproc\fP(5)) afin d'exécuter un nouveau programme. Cela peut être particulièrement bénéfique lorsqu'un grand processus parent souhaite exécuter un petit programme d'assistance dans un processus enfant. Par contraste, l'utilisation de \fBfork\fP(2) dans ce scénario nécessite soit l'allocation d'une quantité de mémoire égale à la taille du processus parent (si la gestion stricte du dépassement est en cours) soit un dépassement de mémoire avec le risque qu'un processus soit terminé par la mise à mort sur mémoire saturée (OOM killer). .SS "Mises en garde" Le processus enfant devrait veiller à ne pas modifier la mémoire d'une manière inattendue, dans la mesure où les modifications seront vues par le processus parent une fois que l'enfant s'est achevé ou exécute un autre programme. À cet égard, les gestionnaires de signaux peuvent être particulièrement problématiques\ : si un gestionnaire de signal qui est invoqué dans l'enfant d'un \fBvfork\fP() modifie la mémoire, ces modifications peuvent aboutir à une inconsistance de l'état du processus du point de vue du processus parent (par exemple, les modifications de la mémoire pourraient être visibles dans le parent, mais pas les modifications de l'état des descripteurs de fichiers ouverts). .PP .\" Lorsque \fBvfork\fP() est appelé dans un processus multithreadé, seul le thread appelant est suspendu jusqu'à ce que l'enfant s'achève ou exécute un nouveau programme. Cela signifie que l'enfant partage un espace d'adresses avec un autre code en cours d'exécution. Cela peut être dangereux si un autre thread dans le processus parent modifie son identifiant (avec \fBsetuid\fP(2) ou une autre commande similaire), dans la mesure où il y a alors deux processus avec différents niveaux de privilèges exécutés dans le même espace d'adresses. Comme exemple de risque, imaginez qu'un programme multithreadé exécuté en tant que superutilisateur crée un enfant avec \fBvfork\fP(). Après le \fBvfork\fP(), un thread dans le processus parent transfère le processus à un utilisateur non privilégié afin d'exécuter du code non sûr (par exemple, peut\-être au moyen d'un greffon ouvert avec \fBdlopen\fP(3)). Dans ce cas, des attaques sont possibles où le processus parent utilise \fBmmap\fP(2) pour projeter en mémoire du code qui sera exécuté par le processus enfant privilégié. .SS "Notes pour Linux" Les gestionnaires enregistrés avec \fBpthread_atfork\fP(3) ne sont pas appelés lorsqu'un programme multithreadé utilisant la bibliothèque de threads NPTL appelle \fBvfork\fP(). En revanche ces gestionnaires sont appelés si le programme utilise la bibliothèque LinuxThreads. (Consultez \fBpthreads\fP(7) pour une description des bibliothèques de threads pour Linux.) .PP Un appel à \fBvfork\fP() est équivalent à appeler \fBclone\fP(2) avec \fIflags\fP valant\ : .PP .in +4n .EX CLONE_VM | CLONE_VFORK | SIGCHLD .EE .in .SS Historique .\" In the release notes for 4.2BSD Sam Leffler wrote: `vfork: Is still .\" present, but definitely on its way out'. L'appel système \fBvfork\fP() est apparu dans 3.0BSD. Dans 4.4BSD, il est devenu synonyme de \fBfork\fP(2), mais NetBSD l'a réintroduit à nouveau (consultez .UR http://www.netbsd.org\:/Documentation\:/kernel\:/vfork.html .UE ). Sous Linux, il a été l'équivalent de \fBfork\fP(2) jusqu'à Linux\ 2.2.0\-pre\-6. Depuis Linux\ 2.2.0\-pre\-9 (sur i386, un peu plus tard sur d'autres architectures), il s'agit d'un appel système indépendant. La prise en charge a été introduite dans la glibc\ 2.0.112. .SH BOGUES .\" .\" As far as I can tell, the following is not true in Linux 2.6.19: .\" Currently (Linux 2.3.25), .\" .BR strace (1) .\" cannot follow .\" .BR vfork () .\" and requires a kernel patch. 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 enfants au milieu d'un \fBvfork\fP() ne reçoivent jamais le signal \fBSIGTTOU\fP ou \fBSIGTTIN\fP\ ; des sorties et des \fIioctl\fP sont autorisés, mais des tentatives de lecture donneront une indication de fin de fichier.\ » .SH "VOIR AUSSI" \fBclone\fP(2), \fBexecve\fP(2), \fB_exit\fP(2), \fBfork\fP(2), \fBunshare\fP(2), \fBwait\fP(2) .PP .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot et Jean-Pierre Giraud . .PP Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. .PP Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à .MT debian-l10n-french@lists.debian.org .ME .