pid_t fork(void);  

*

Le fils a son propre identifiant de processus (PID). Ce PID est unique et ne correspond à aucun autre identifiant de groupe de processus existant (setpgid(2)).

*

Le PPID (Parent Process ID) du fils est identique au PID du parent.

*

Le fils n'hérite pas des verrouillages mémoire de son parent (mlock(2), mlockall(2)).

*

Les statistiques d'utilisation des ressources de processus (getrusage(2)) et les compteurs de temps CPU (times(2)) sont réinitialisés dans le fils.

*

L'ensemble des signaux en attente pour le fils est initialement vide (sigpending(2)).

*

Le fils n'hérite pas des ajustements de sémaphore de son parent (semop(2)).

*

Le fils n'hérite pas des verrouillages d'enregistrement de son parent (fcntl(2)).

*

Le fils n'hérite pas des temporisateurs de son parent (setitimer(2), alarm(2), timer_create(3)).

*

Le fils n'hérite pas des opérations d'E/S asynchrones en cours de son parent (aio_read(3), aio_write(3)).

Les attributs de processus de la liste précédente sont tous spécifiés dans POSIX.1-2001. Le parent et le fils différent également par les attributs de processus suivant, spécifiques à Linux :

*

Le fils n'hérite pas des notifications de changement de répertoire (dnotify) de son parent (voir la description de F_NOTIFY dans fcntl(2)).

*

L'attribut PR_SET_PDEATHSIG de prctl(2) est réinitialisé de sorte que le fils ne reçoive pas de signal lorsque son parent se termine.

*

Les mappages de mémoire qui ont été marqués avec l'attribut MADV_DONTFORK de madvise(2) ne sont pas hérités à travers un fork().

*

Le signal de terminaison du fils est toujours SIGCHLD (voir clone(2)).

Veuillez également noter les points suivants :

*

Le processus fils est créé avec un simple thread --- celui qui a appelé fork(). L'espace entier d'adresses virtuelles du parent est répliqué dans le fils. Cela inclut les états des mutexes, les variables de condition et autres objects pthreads ; l'utilisation de pthread_atfork(3) peut être préférable afin de gérer les problèmes qui pourraient être provoqués.

*

Le fils hérite d'une copie de l'ensemble des descripteurs de fichiers ouverts du parent. Chaque descripteur de fichier du fils fait référence à la même description de fichier ouvert (voir open(2)) que le descripteur de fichier correspondant du parent. Cela signifie que les deux descripteurs partagent les attributs d'état de fichier ouvert, la position de la tête de lecture et les attributs d'E/S pilotées par signaux (voir la description de F_SETOWN et F_SETSIG dans fcntl(2)).

*

Le fils hérite d'une copie de l'ensemble des descripteurs de files de messages ouverts (voir mq_overview(7)). Chaque descripteur dans le fils fait référence à la même description de file de messages ouverte que le descripteur de file de message ouvert dans le parent. Cela signifie que les deux descripteurs partagent les même drapeaux (mq_flags).

*

Le fils hérite d'une copie de l'ensemble des descripteurs de flux vers répertoires ouverts (voir opendir(3)). POSIX.1-2001 indique que les flux vers les répertoires correspondants chez le parent et le fils peuvent partager le même positionneur de flux vers répertoire ; ce n'est pas le cas sous Linux/glibc.

EAGAIN

fork() ne peut pas allouer assez de mémoire pour copier la table des pages du père et une structure de tâche pour le fils.

EAGAIN

Il n'a pas été possible de créer un nouveau processus car la limite ressource RLIMIT_NPROC de l'appelant a été rencontrée. Pour franchir cette limite, le processus doit avoir au moins l'une des deux capacités CAP_SYS_ADMIN ou CAP_SYS_RESOURCE.

ENOMEM

fork() a échoué car le noyau n'a plus assez de mémoire.

Sous Linux, fork() est implementé en utilisant une méthode de copie à l'écriture. Ceci consiste à ne faire la véritable duplication d'une page mémoire que lorsqu'un processus en modifie une instance. Tant qu'aucun des deux processus n'écrit dans une page donnée, celle-ci n'est pas vraiment dupliquée. Ainsi les seules pénalisations induites par fork sont le temps et la mémoire nécessaires à la copie de la table des pages du parent ainsi que la création d'une structure de tâche pour le fils.

Depuis la version 2.3.3, plutôt que d'invoquer l'appel système fork() du noyau, l'enveloppe fork() de la glibc qui est fournie comme faisant partie de l'implémentation de threading NPTL invoque clone(2) avec des attributs qui fournissent le même effet que le traditionnel appel système. L'enveloppe de la glibc invoque tous les gestionnaires de bifurcation (Ndt : fork) établis avec pthread_atfork(3).  

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 6 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 fork ». N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute erreur dans cette page de manuel.

NOM

SYNOPSIS

DESCRIPTION

VALEUR RENVOYÉE

ERREURS

CONFORMITÉ

NOTES

EXEMPLE

VOIR AUSSI

TRADUCTION