Les MANs Linux en français...
CLONE
Section: Manuel du programmeur Linux (2)Updated: 15 janvier 2002
Index Retour au Menu Principal
NOM
clone - Créer un processus fils (child).SYNOPSIS
#include <linux/sched.h>int clone(int (*fn) (void *arg), void *pile_fils, int flags, void *arg)
_syscall2(int, clone, int, flags, void *, pile_fils);
DESCRIPTION
clone crée un nouveau processus, exactement comme le fait fork(2). clone est une fonction de bibliothèque s'appuyant sur l'appel-système sys_clone sous-jacent. Une description de sys_clone se trouve plus bas sur cette page.Contrairement à fork(2), cette routine permet le partage d'une partie du contexte d'exécution entre le processus fils et le processus appelant. Le partage peut s'appliquer sur l'espace mémoire, sur la table des descripteurs de fichiers, la table des gestionnaires de signaux... (Notez que sur cette page de manuel, le "processus appelant" correspond normalement au "processus père", mais voyez quand même la description de CLONE_PARENT plus bas).
L'appel système clone est principalement utilisé pour permettre l'implémentation des threads : un programme est scindé en plusieurs lignes de contrôle, s'exécutant simultanément dans un espace mémoire partagé.
Quand le processus fils est créé, avec clone, il exécute la fonction fn(arg) de l'application. (Ceci est différent de fork(2) avec lequel l'exécution continue dans le fils au point de l'appel fork)
L'argument fn est un pointeur sur la fonction appelée par le processus fils lors de son démarrage. L'argument arg est transmis à la fonction fn lors de son invocation.
Quand la fonction fn(arg) revient, le processus fils se termine. La valeur entière renvoyée par fn est utilisée comme code de retour du processus fils. Ce dernier peut également se terminer de manière explicite en invoquant la fonction exit(2) ou après la réception d'un signal fatal.
L'argument pile_fils indique l'emplacement de la pile utilisée par le processus fils. Comme les processus fils et appelant peuvent partager de la mémoire, il n'est généralement pas possible pour le fils d'utiliser la même pile que son père. Le processus appelant doit donc préparer un espace mémoire pour stocker la pile de son fils, et transmettre à clone un pointeur sur cet emplacement.
Les piles croissent vers le bas sur tous les processeurs implémentant Linux (sauf le HP PA), donc pile_fils doit pointer sur la plus haute adresse de l'espace mémoire prévu pour la pile du processus fils.
L'octet de poids faible de flags contient le numéro du signal qui sera envoyé au père lorsque le processus fils se terminera. Si ce signal est différent de SIGCHLD, le processus parent doit également spécifier les options __WALL ou __WCLONE lorsqu'il attend la fin du fils avec wait(2). Si aucun signal n'est indiqué, le processus parent ne sera pas notifié de la terminaison du fils.
flags permet également de préciser ce qui sera partagé entre le père et le fils, en effectuant un OU binaire entre une ou plusieurs des constantes suivantes :
- CLONE_PARENT
-
(nouveauté Linux 2.4) Si
CLONE_PARENT
est présent, le père du nouveau fils (comme il est indiqué par
getppid(2))
sera le même que celui du processus appelant.
Si CLONE_PARENT n'est pas fourni, alors (comme pour fork(2)) le père du processus fils sera le processus appelant.
Remarquez que c'est le processus père, tel qu'indiqué par getppid(2), qui est notifié lors de la fin du fils. Ainsi si CLONE_PARENT est présent, alors c'est le père du processus appelant, et non ce dernier, qui sera notifié. - CLONE_FS
-
Si l'attribut
CLONE_FS
est positionné, les processus appelant et fils partagent les mêmes informations
concernant le système de fichiers. Ceci inclue la racine du système de
fichiers, le répertoire de travail, et l'umask. Tout appel à
chroot(2),
chdir(2),
ou
umask(2)
effectué par un processus aura également influence sur l'autre processus.
Si CLONE_FS n'est pas choisi, le processus travaille sur une copie des informations de l'appelant concernant le système de fichiers. Cette copie est effectuée lors de l'invocation de clone. Les appels à chroot(2),chdir(2),umask(2) effectués par un processus n'affectent pas l'autre processus.
- CLONE_FILES
-
Si l'attribut
CLONE_FILES
est positionné, les processus appelant et fils partagent la même table des
descripteurs de fichiers. Les descripteurs feront alors toujours référence
aux mêmes fichiers pour les deux processus. Tout descripteur créé par
un processus est également valide pour l'autre processus. De même si
un processus ferme un descripteur, ou modifie ses attributs, l'autre
processus en est aussi affecté.
Si CLONE_FILES n'est pas positionné, le processus fils hérite d'une copie des descripteurs de fichiers ouverts par l'appelant au moment de l'appel clone. Les opérations effectuées ensuite sur un descripteur par un des processus n'affectent pas l'autre processus.
- CLONE_SIGHAND
-
Si l'attribut
CLONE_SIGHAND
est positionné, les processus appelant et fils partagent la même table des
gestionnaires de signaux. Si l'appelant, ou le fils, appelle
sigaction(2)
pour modifier le comportement associé à un signal, ce comportement est
également changé pour l'autre processus. Néanmoins, l'appelant et le
fils ont toujours des masques de signaux distincts, et leurs ensembles
de signaux bloqués sont indépendants.
L'un des processus peut donc bloquer un signal en utilisant
sigprocmask(2)
sans affecter l'autre processus.
Si CLONE_SIGHAND n'est pas utilisé, le processus fils hérite d'une copie des gestionnaires de signaux de l'appelant lors de l'invocation de clone. Les appels à sigaction(2) effectués ensuite depuis un processus n'ont pas d'effets sur l'autre processus.
- CLONE_PTRACE
-
Si l'attribut
CLONE_PTRACE
est positionné et si l'appelant est suivi par un débogueur, alors le
fils sera également suivi (voir
ptrace(2)).
- CLONE_VFORK
-
Si le bit
CLONE_VFORK
est actif, l'exécution du processus appelant est suspendue jusqu'à ce
que le fils libère ses ressources de mémoire virtuelle par un appel
execve(2)
ou
_exit(2)
(comme avec
vfork(2)).
Si CLONE_VFORK n'est pas indiqué, alors les deux processus sont ordonnancés à partir de la fin de l'appel, et l'application ne doit pas considéré que l'ordre d'exécution soit déterminé.
- CLONE_VM
-
Si le bit
CLONE_VM
est actif, les processus père et fils s'exécutent dans le même espace mémoire.
En particulier, les écritures en mémoire effectuées par l'un des processus sont
visibles par l'autre.
De même toute projection en mémoire, ou toute suppression de projection,
effectuées avec
mmap(2)
ou
munmap(2)
par l'un des processus affectera également l'autre processus.
Si CLONE_VM n'est pas actif, le processus fils utilisera une copie distincte de l'espace mémoire de l'appelant. Le cliché étant réalisé lors de l'invocation de clone. Les écritures ou les projections de fichiers en mémoire effectuées par un processus n'affectent pas l'autre processus, comme cela se passe avec fork(2).
- CLONE_PID
-
Si l'attribut
CLONE_PID
est positionné, les processus appelant et fils ont le même numéro de processus.
Si CLONE_PID n'est pas sélectionné, le processus fils possède un identificateur unique, distinct de celui de l'appelant.
Cet attribut ne peut être utilisé que par le processus de démarrage du système (PID 0).
- CLONE_THREAD
-
(Nouveauté Linux 2.4)
Si
CLONE_THREAD
est présent, le fils est placé dans le même groupe de threads que le processus
appelant.
Si CLONE_THREAD n'est pas indiqué, alors le fils est placé dans son propre (nouveau) groupe de threads, dont l'identificateur est identique au PID.
(Les groupes de threads sont une fonctionnalité ajoutées dans Linux 2.4 pour supporter la notion POSIX d'ensemble de threads partageant un même PID. Sous Linux 2.4, l'appel getpid(2) renvoie l'identificateur du groupe de thread de l'appelant).
L'appel-système sys_clone ressemble plus à fork(2), en ceci que l'exécution dans le processus fils continue à partir du point d'appel. Ainsi sys_clone ne nécessite que les arguments flags et pile_fils qui ont la même signification que pour clone. (Notez que l'ordre de ces arguments est différent de celui dans clone).
Une autre différence : pour sys_clone, l'argument pile_fils peut être nul, puisque la sémantique de copie-en-écriture assure que le fils recevra une copie indépendante des pages de la pile dès qu'un des deux processus la modifiera. Pour que cela fonctionne, il faut naturellement que CLONE_VM ne soit PAS présent.
VALEUR RENVOYÉE
En cas de réussite, le PID du processus fils est renvoyé dans le fil d'exécution de l'appelant. En cas d'échec, -1 est renvoyé dans le contexte de l'appelant, aucun fils n'est créé, et errno contiendra le code d'erreur.ERREURS
- EAGAIN
- Trop de processus en cours d'exécution.
- ENOMEM
- Pas assez de mémoire pour copier les parties du contexte du processus appelant qui doivent être dupliquée, ou pour allouer une structure de tâche pour le processus fils.
- EINVAL
- Renvoyée par clone quand une valeur nulle a été indiquée pour le paramètre pile_fils.
- EPERM
- CLONE_PID a été réclamé par un processus au PID non-nul.
BOGUES
Il n'y a pas de définition pour clone dans la libc version 5. La version 6 (GlibC 2) fournit une définition de clone comme décrit ici.
CONFORMITÉ
Les appels-système clone et sys_clone sont spécifiques à Linux et ne doivent pas être employés dans des programmes portables. Pour programmer des applications multithreads, il vaut mieux employer une bibliothèque qui implémente l'API des Threads Posix 1003.1c comme la bibliothèque LinuxThreads (incluse dans la GlibC 2). Voir pthread_create(3thr).Cette page de manuel correspond aux noyaux 2.0.x, 2.1.x, 2.2.x, 2.4.x et aux GlibC 2.0.x et 2.1.x.
VOIR AUSSI
fork(2), wait(3), pthread_create(3).TRADUCTION
Christophe Blaess, 1997.
Index
Time: 21:38:06 GMT, December 19, 2004
