Provided by:
manpages-fr-dev_3.27fr1.4-1_all 
NOM
clone, __clone2 - Creer un processus fils (child)
SYNOPSIS
#define _GNU_SOURCE /* Consultez feature_test_macros(7) */
#include <sched.h>
int clone(int (*fn)(void *), void *child_stack,
int flags, void *arg, ...
/* pid_t *ptid, struct user_desc *tls, pid_t *ctid */ );
DESCRIPTION
clone() cree un nouveau processus, exactement comme le fait fork(2).
clone() est en fait une fonction de bibliotheque s'appuyant sur l'appel
systeme clone() sous-jacent, mentionne comme sys_clone ci-dessous. Une
description de sys_clone se trouve plus bas sur cette page.
Contrairement a fork(2), cette routine permet le partage d'une partie
du contexte d'execution entre le processus fils et le processus
appelant. Le partage peut s'appliquer sur l'espace memoire, sur la
table des descripteurs de fichiers ou la table des gestionnaires de
signaux. (Notez que sur cette page de manuel, le << processus
appelant >> correspond normalement au << processus pere >>, mais voyez
quand meme la description de CLONE_PARENT plus bas).
L'appel systeme clone() est principalement utilise pour permettre
l'implementation des threads : un programme est scinde en plusieurs
lignes de controle, s'executant simultanement dans un espace memoire
partagee.
Quand le processus fils est cree, avec clone(), il execute la fonction
fn(arg) de l'application. Ceci est different de fork(2) avec lequel
l'execution continue dans le fils au point de l'appel fork(2).
L'argument fn est un pointeur sur la fonction appelee par le processus
fils lors de son demarrage. L'argument arg est transmis a la fonction
fn lors de son invocation.
Quand la fonction fn(arg) revient, le processus fils se termine. La
valeur entiere renvoyee par fn est utilisee comme code de retour du
processus fils. Ce dernier peut egalement se terminer de maniere
explicite en invoquant la fonction exit(2) ou apres la reception d'un
signal fatal.
L'argument child_stack indique l'emplacement de la pile utilisee par le
processus fils. Comme les processus fils et appelant peuvent partager
de la memoire, il n'est generalement pas possible pour le fils
d'utiliser la meme pile que son pere. Le processus appelant doit donc
preparer un espace memoire pour stocker la pile de son fils, et
transmettre a clone un pointeur sur cet emplacement. Les piles
croissent vers le bas sur tous les processeurs implementant Linux (sauf
le HP PA), donc child_stack doit pointer sur la plus haute adresse de
l'espace memoire prevu pour la pile du processus fils.
L'octet de poids faible de flags contient le numero du signal qui sera
envoye au pere lorsque le processus fils se terminera. Si ce signal est
different de SIGCHLD, le processus parent doit egalement specifier les
options __WALL ou __WCLONE lorsqu'il attend la fin du fils avec
wait(2). Si aucun signal n'est indique, le processus parent ne sera pas
notifie de la terminaison du fils.
flags permet egalement de preciser ce qui sera partage entre le pere et
le fils, en effectuant un OU binaire entre une ou plusieurs des
constantes suivantes :
CLONE_CHILD_CLEARTID (depuis Linux 2.5.49)
Effacer l'ID du thread enfant a ctid dans la memoire du fils
lorsqu'il se termine, et reveiller le futex a cette adresse.
L'adresse concernee peut etre modifiee par l'appel systeme
set_tid_address(2). Cela est utilise dans les bibliotheques de
gestion de threads.
CLONE_CHILD_SETTID (depuis Linux 2.5.49)
Enregistrer l'ID du thread enfant a ctid dans la memoire du
fils.
CLONE_FILES
Si l'attribut CLONE_FILES est positionne, le processus appelant
et le processus fils partagent la meme table des descripteurs de
fichier. Tout descripteur cree par un processus est egalement
valide pour l'autre processus. De meme si un processus ferme un
descripteur, ou modifie ses attributs (en utilisant l'operation
fcntl(2) F_SETFD), l'autre processus en est aussi affecte.
Si CLONE_FILES n'est pas positionne, le processus fils herite
d'une copie des descripteurs de fichier ouverts par l'appelant
au moment de l'appel clone(). (Les copies des descripteurs de
fichier dans le fils sont associees aux memes descriptions de
fichiers ouverts (consultez open(2)) que les descripteurs de
fichier correspondants dans le processus appelant.) Les
operations effectuees ensuite sur un descripteur par un des
processus n'affectent pas l'autre processus.
CLONE_FS
Si l'attribut CLONE_FS est positionne, le processus appelant et
le processus fils partagent les memes informations concernant le
systeme de fichiers. Ceci inclut la racine du systeme de
fichiers, le repertoire de travail, et l'umask. Tout appel a
chroot(2), chdir(2) ou umask(2) effectue par un processus aura
egalement 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 systeme de
fichiers. Cette copie est effectuee lors de l'invocation de
clone(). Les appels a chroot(2), chdir(2), umask(2) effectues
par un processus n'affectent pas l'autre processus.
CLONE_IO (depuis Linux 2.6.25)
Si CLONE_IO est defini, alors le nouveau processus partage un
contexte d'entrees-sorties avec le processus appelant. Si cet
attribut n'est pas defini, alors (comme pour fork(2)) le nouveau
processus a son propre contexte d'entrees-sorties.
Le contexte d'entrees-sorties correspond a la visibilite que
l'ordonnanceur de disques a des entrees-sorties (c'est-a-dire,
ce que l'ordonnanceur d'entree-sorties utilise pour modeliser
l'ordonnancement des entrees-sorties d'un processus). Si des
processus partagent le meme contexte d'entrees-sorties, ils sont
traites comme un seul par l'ordonnanceur d'entrees-sorties. Par
consequent, ils partagent le meme temps d'acces aux disques.
Pour certains ordonnanceurs d'entrees-sorties, si deux processus
partagent un contexte d'entrees-sorties, ils seront autorises a
intercaler leurs acces disque. Si plusieurs threads utilisent
des entrees-sorties pour le meme processus (aio_read(3), par
exemple), ils devraient utiliser CLONE_IO pour obtenir de
meilleurs performances d'entrees-sorties.
Si le noyau n'a pas ete configure avec l'option CONFIG_BLOCK,
cet attribut n'a aucun effet.
CLONE_NEWIPC (depuis Linux 2.6.19)
Si CLONE_NEWIPC est defini, alors creer le processus dans un
nouvel espace de noms IPC. Si cet attribut n'est pas defini,
alors (comme pour fork(2)) le processus est cree dans le meme
espace de noms IPC que le processus appelant. Cet attribut est
sense etre utilise pour l'implementation de conteneurs.
Un espace de noms IPC consiste en un jeu d'identifiants pour des
objets IPC System V (ces objets sont crees en utilisant
msgctl(2), semctl(2) et shmctl(2)). Les objets crees dans un
espace de noms IPC sont visibles de tous les autres membres de
cet espace de noms, mais ne sont pas visibles des processus des
autres espaces de noms.
Quand un espace de noms est detruit (c'est-a-dire, quand le
dernier processus membre de cet espace de noms se termine), tous
les objets IPC de cet espace de noms sont automatiquement
detruits.
Utiliser cet attribut necessite : un noyau configure avec les
options CONFIG_SYSVIPC et CONFIG_IPC_NS et que le processus soit
privilegie (CAP_SYS_ADMIN). Cet attribut ne peut pas etre
utilise en meme temps que CLONE_SYSVSEM.
CLONE_NEWNET (depuis Linux 2.6.24)
(L'implementation de cet attribut n'est toujours pas complete,
mais le sera surement aux environs de Linux 2.6.28.)
Si CLONE_NEWNET est defini, alors creer le processus dans un
nouvel espace de noms reseau. SI cet attribut n'est pas defini,
alors (comme pour fork(2)) le processus est cree dans le meme
espace de noms reseau que le processus appelant. Cet attribut
est sense etre utilise pour l'implementation de conteneurs.
Un espace de noms reseau fournit une vue isolee de la pile
reseau (interfaces des peripheriques reseau, piles des
protocoles IPv4 et IPv6, tables de routage, regles de pare-feu,
les arbres de repertoire /proc/net et /sys/class/net, les
sockets, etc.). Un peripherique reseau physique ne peut etre que
dans un seul espace de noms reseau. Une paire d'interface reseau
virtuelle (<< veth >>) fournit une abstraction similaire a pipe
qui peut etre utilise pour creer un pont vers une interface
reseau physique d'un autre espace de noms reseau.
Quand un espace de noms reseau est libere (c'est-a-dire, quand
le dernier processus de l'espace de noms se termine), ses
peripheriques reseau physiques sont remis dans l'espace de noms
reseau initial (pas celui du processus pere).
Utiliser cet attribut necessite : un noyau configure avec
l'option CONFIG_NET_NS et que le processus soit privilegie
(CAP_SYS_ADMIN).
CLONE_NEWNS (depuis Linux 2.4.19)
Demarrer le processus dans un nouvel espace de noms de montage.
Chaque processus se trouve dans un espace de noms de montage.
Cet espace de noms du processus regroupe les donnees decrivant
la hierarchie des fichiers vus par le processus (l'ensemble des
montages). Apres un fork(2) ou clone() sans l'attribut
CLONE_NEWNS le fils se deroule dans le meme espace de noms de
montage que son pere. Les appels systeme mount(2) et umount(2)
modifient l'espace de noms de montage du processus appelant, et
affectent ainsi tous les processus se deroulant dans le meme
espace de noms, sans affecter les processus se trouvant dans
d'autres espaces de noms de montage.
Apres un clone() avec l'attribut CLONE_NEWNS le fils clone
demarre dans un nouvel espace de noms de montage, initialise
avec une copie de l'espace de noms du pere.
Seul un processus privilegie (un processus ayant la capacite
CAP_SYS_ADMIN) peut specifier l'attribut CLONE_NEWNS. Il n'est
pas possible de specifier a la fois CLONE_NEWNS et CLONE_FS pour
le meme appel clone().
CLONE_NEWPID (depuis Linux 2.6.24)
Si CLONE_NEWPID est defini, alors creer le processus dans un
nouvel espace de noms de PID. Si cet attribut n'est pas defini,
alors (comme pour fork(2)) le processus est cree dans le meme
espace de noms de PID que le processus appelant. Cet attribut
est sense etre utilise pour l'implementation de conteneurs.
Un espace de noms de PID fournit un environnement isoles pour
les PID : les PID d'un nouvel espace de noms de PID commence a
1, comme pour un systeme seul, et les appels a fork(2), vfork(2)
et clone(2) produiront des processus avec des PID uniques dans
l'espace de noms.
Le premier processus cree dans un nouvel espace de noms
(c'est-a-dire, le processus cree en utilisant l'attribut
CLONE_NEWPID) a un PID de 1 et est le processus << init >> pour
l'espace de noms. Les fils qui deviennent orphelins dans cet
espace de noms seront adoptes par ce processus plutot que par
init(8). Contrairement a l'init traditionnel, le processus
<< init >> d'un espace de noms de PID peut se terminer et, s'il
le fait, tous les processus dans l'espace de noms sont alors
termines.
Les espaces de noms de PID forment une hierarchie. Quand un
espace de noms de PID est cree, les processus de cet espace de
noms sont visibles depuis l'espace de noms de PID du processus
qui a cree le nouvel espace de noms ; de la meme facon, si
l'espace de noms parent est lui-meme le fils d'un autre espace
de noms de PID, alors les processus du fils et du pere seront
tous visibles de l'espace de noms grand-pere. A l'inverse, les
processus de l'espace de noms de PID fils ne voient pas les
processus de l'espace de noms parent. L'existence d'une
hierarchie d'espaces de noms signifie que chaque processus peut
desormais avoir plusieurs PID : un par espace de noms dans
lequel il est visible ; chacun de ces PID est unique dans les
espaces de noms correspondants. (Un appel a getpid(2) renvoie
toujours le PID associe a l'espace de noms dans lequel le
processus se trouve.)
Apres avoir cree un nouvel espace de noms, il est utile pour le
fils de changer son repertoire racine et monter une nouvelle
instance de procfs dans /proc de telle sorte que des outils
comme ps(1) fonctionnent correctement. (Si CLONE_NEWNS est
egalement present dans flags, alors il n'est pas necessaire de
changer de repertorie racine : une nouvelle instance de procfs
peut etre monte directement dans /proc.)
L'utilisation de cet attribut necessite : un noyau configure
avec l'option CONFIG_PID_NS et que le processus soit privilegie
(CAP_SYS_ADMIN). Cet attribut ne peut pas etre utilise en meme
temps que CLONE_THREAD.
CLONE_NEWUTS (depuis Linux 2.6.19)
Si CLONE_NEWUTS est defini, alors creer le processus dans un
nouvel espace de noms de UTS, dont les identifiants sont
initialises en dupliquant les identifiants de l'espace de noms
UTS du processus appelant. Si cet attribut n'est pas defini,
alors (comme pour fork(2)) le processus est cree dans le meme
espace de noms UTS que le processus appelant. Cet attribut est
sense etre utilise pour l'implementation de conteneurs.
Un espace de noms UTS est l'ensemble des identifiants renvoyes
par uname(2) ; parmi lesquels le nom de domaine et le nom d'hote
peuvent etre modifies respectivement a l'aide de
setdomainname(2) et sethostname(2). Les modifications apportes a
ces identifiants dans un espace de noms UTS sont visibles par
tous les processus du meme espace de noms, mais ne sont pas
visibles des processus des autres espaces de noms UTS.
L'utilisation de cet attribut necessite : un noyau configure
avec l'option CONFIG_UTS_NS et que le processus soit privilegie
(CAP_SYS_ADMIN).
CLONE_PARENT (depuis Linux 2.3.12)
Si CLONE_PARENT est present, le pere du nouveau fils (comme il
est indique par getppid(2)) sera le meme que celui du processus
appelant.
Si CLONE_PARENT n'est pas fourni, alors (comme pour fork(2)) le
pere du processus fils sera le processus appelant.
Remarquez que c'est le processus pere, tel qu'indique par
getppid(2), qui est notifie lors de la fin du fils. Ainsi, si
CLONE_PARENT est present, alors c'est le pere du processus
appelant, et non ce dernier, qui sera notifie.
CLONE_PARENT_SETTID (depuis Linux 2.5.49)
Enregistrer l'ID du thread enfant a ptid dans la memoire du pere
et du fils. (Dans Linux 2.5.32-2.5.48 il y a un attribut
CLONE_SETTID qui fait cela.)
CLONE_PID (obsolete)
Si l'attribut CLONE_PID est positionne, les processus appelant
et fils ont le meme numero de processus. C'est bien pour hacker
le systeme, mais autrement il n'est plus utilise. Depuis 2.3.21,
cet attribut ne peut etre utilise que par le processus de
demarrage du systeme (PID 0). Il a disparu dans Linux 2.5.16.
CLONE_PTRACE
Si l'attribut CLONE_PTRACE est positionne et si l'appelant est
suivi par un debogueur, alors le fils sera egalement suivi
(consultez ptrace(2)).
CLONE_SETTLS (depuis Linux 2.5.32)
Le parametre newtls est le nouveau descripteur TLS (Thread Local
Storage). (Consultez set_thread_area(2).)
CLONE_SIGHAND
Si l'attribut CLONE_SIGHAND est positionne, le processus
appelant et le processus fils partagent la meme table des
gestionnaires de signaux. Si l'appelant, ou le fils, appelle
sigaction(2) pour modifier le comportement associe a un signal,
ce comportement est egalement change pour l'autre processus.
Neanmoins, l'appelant et le fils ont toujours des masques de
signaux distincts, et leurs ensembles de signaux bloques sont
independants. L'un des processus peut donc bloquer un signal en
utilisant sigprocmask(2) sans affecter l'autre processus.
Si CLONE_SIGHAND n'est pas utilise, le processus fils herite
d'une copie des gestionnaires de signaux de l'appelant lors de
l'invocation de clone(). Les appels a sigaction(2) effectues
ensuite depuis un processus n'ont pas d'effets sur l'autre
processus.
Depuis Linux 2.6.0-test6, l'attribut CLONE_VM doit egalement
etre specifie dans flags si CLONE_SIGHAND l'est.
CLONE_STOPPED (depuis Linux 2.6.0-test2)
Si l'attribut CLONE_STOPPED est positionne, le fils est
initialement stoppe (comme s'il avait recu le signal SIGSTOP),
et doit etre relance en lui envoyant le signal SIGCONT.
Depuis Linux 2.6.25 cet attribut est d'econseill'e. Vous n'avez
probablement jamais voulu l'utiliser ; vous ne devriez
certainement pas l'utiliser ; et il sera bientot supprime.
CLONE_SYSVSEM (depuis Linux 2.5.10)
Si CLONE_SYSVSEM est positionne, le fils et le processus
appelant partagent la meme liste de compteurs << undo >> pour
les semaphores System V (consultez semop(2)). Si cet attribut
n'est pas utilise, le fils a une liste << undo >> separee,
initialement vide.
CLONE_THREAD (depuis Linux 2.4.0-test8)
Si CLONE_THREAD est present, le fils est place dans le meme
groupe de threads que le processus appelant. Afin de rendre
l'explication de CLONE_THREAD plus lisible, le terme
<< thread >> est utilise pour parler des processus dans un meme
groupe de threads.
Les groupes de threads sont une fonctionnalite ajoutees dans
Linux 2.4 pour supporter la notion POSIX d'ensemble de threads
partageant un meme PID. En interne, ce PID partage est appele
identifiant de groupe de threads (TGID).Depuis Linux 2.4,
l'appel getpid(2) renvoie l'identifiant du groupe de thread de
l'appelant.
Les threads dans un groupe peuvent etre distingues par leur
identifiant de thread (TID, unique sur le systeme). Le TID d'un
nouveau thread est renvoye par clone() au processus appelant, et
un thread peut obtenir son propre TID en utilisant gettid(2).
Quand clone() est appele sans positionner CLONE_THREAD, le
nouveau thread est place dans un nouveau groupe de thread dont
le TGID est identique au TID du nouveau thread. Ce thread est le
leader du nouveau groupe.
Un nouveau thread cree en utilisant CLONE_THREAD a le meme
processus pere que l'appelant de clone() (de meme qu'avec
CLONE_PARENT), ainsi les appels a getppid(2) renvoient la meme
valeur a tous les threads dans un meme groupe. Lorsqu'un thread
cree avec CLONE_THREAD termine, le thread qui a appele clone()
pour le creer ne recoit pas le signal SIGCHLD (ou autre
notification de terminaison) ; de meme, l'etat d'un tel thread
ne peut etre obtenu par wait(2). Le thread est dit d'etach'e.
Lorsque tous les threads d'un groupe de threads terminent, le
processus parent du groupe recoit un signal SIGCHLD (ou autre
indicateur de terminaison).
Si l'un des threads dans un groupe de threads appelle execve(2),
tous les threads sauf le leader sont tues, et le nouveau
programme est execute dans le leader du groupe de threads.
Si l'un des threads dans un groupe cree un fils avec fork(2),
n'importe lequel des threads du groupe peut utiliser wait(2) sur
ce fils.
Depuis Linux 2.5.35, l'attribut CLONE_SIGHAND de flags doit etre
positionne si CLONE_THREAD l'est.
Un signal peut etre envoye a un groupe de threads dans son
ensemble (c'est-a-dire a un TGID) avec kill(2), ou bien a un
thread en particulier (a un TID) avec tgkill(2).
Les gestions de signaux sont definies au niveau des processus :
si un signal sans gestionnaire est recu par un thread, il
affectera (tuera, stoppera, relancera, ou sera ignore par) tous
les membres du groupe de threads.
Chaque thread a son propre masque de signaux, defini par
sigprocmask(2), mais les signaux peuvent etre en attente soit
pour le processus dans son ensemble (donc peut etre recu par
n'importe lequel des threads du groupe), quand ils sont envoyes
avec kill(2), soit pour un thread particulier, lorsqu'ils sont
envoyes par tgkill(2). Un appel a sigpending(2) renvoie un
ensemble de signaux qui est l'union des processus en attente
pour le processus et ceux en attente pour le thread appelant.
Si kill(2) est utilise pour envoyer un signal a un groupe de
threads, et si le groupe a installe un gestionnaire pour ce
signal, alors le gestionnaire sera execute dans exactement un
des membres du groupe de threads, choisi de facon arbitraire
parmi ceux qui n'ont pas bloque ce signal. Si plusieurs threads
dans un groupe attendent le meme signal en utilisant
sigwaitinfo(2), le noyau choisira arbitrairement l'un d'entre
eux pour delivrer le signal envoye par kill(2).
CLONE_UNTRACED (depuis Linux 2.5.46)
Si l'attribut CLONE_UNTRACED est positionne, alors un processus
tracant le pere ne peut pas forcer CLONE_PTRACE pour ce fils.
CLONE_VFORK
Si le bit CLONE_VFORK est actif, l'execution du processus
appelant est suspendue jusqu'a ce que le fils libere ses
ressources de memoire virtuelle par un appel execve(2) ou
_exit(2) (comme avec vfork(2)).
Si CLONE_VFORK n'est pas indique, alors les deux processus sont
ordonnances a partir de la fin de l'appel, et l'application ne
doit pas considerer que l'ordre d'execution soit determine.
CLONE_VM
Si le bit CLONE_VM est actif, le processus appelant et le
processus fils s'executent dans le meme espace memoire. En
particulier, les ecritures en memoire effectuees par l'un des
processus sont visibles par l'autre. De meme toute projection en
memoire, ou toute suppression de projection, effectuees avec
mmap(2) ou munmap(2) par l'un des processus affectera egalement
l'autre processus.
Si CLONE_VM n'est pas actif, le processus fils utilisera une
copie distincte de l'espace memoire de l'appelant. Le cliche est
realise lors de l'invocation de clone(). Les ecritures ou les
projections de fichiers en memoire effectuees par un processus
n'affectent pas l'autre processus, comme cela se passe avec
fork(2).
sys_clone
L'appel systeme sys_clone ressemble plus a fork(2), en ceci que
l'execution dans le processus fils continue a partir du point d'appel.
Ainsi sys_clone ne necessite que les arguments flags et child_stack qui
ont la meme signification que pour clone(). (Notez que l'ordre de ces
arguments est different de celui dans clone().)
Une autre difference : pour sys_clone, l'argument child_stack peut etre
nul, puisque la semantique de copie-en-ecriture assure que le fils
recevra une copie independante des pages de la pile des qu'un des deux
processus la modifiera. Pour que cela fonctionne, il faut naturellement
que CLONE_VM ne soit pas present.
Sous Linux 2.4 et plus anciens, clone() ne prend pas les arguments
ptid, tls et ctid.
VALEUR RENVOY'EE
En cas de reussite, le TID du processus fils est renvoye dans le thread
d'execution de l'appelant. En cas d'echec, -1 est renvoye dans le
contexte de l'appelant, aucun fils n'est cree, et errno contiendra le
code d'erreur.
ERREURS
EAGAIN Trop de processus en cours d'execution.
EINVAL CLONE_SIGHAND a ete specifie mais pas CLONE_VM (depuis Linux
2.6.0-test6).
EINVAL CLONE_THREAD a ete specifie mais pas CLONE_SIGHAND (depuis
Linux 2.5.35).
EINVAL Les attributs CLONE_NEWNS et CLONE_FS ont ete indiques
simultanement dans flags.
EINVAL Les attributs CLONE_NEWIPC et CLONE_SYSVSEM ont ete indiques
simultanement dans flags.
EINVAL Les attributs CLONE_NEWPID et CLONE_THREAD ont ete indiques
simultanement dans flags.
EINVAL Renvoyee par clone() quand une valeur nulle a ete indiquee pour
le parametre child_stack.
EINVAL CLONE_NEWIPC a ete indique dans flags, mais le noyau n'a pas ete
configure avec les options CONFIG_SYSVIPC et CONFIG_IPC_NS.
EINVAL CLONE_NEWNET a ete indique dans flags, mais le noyau n'a pas ete
configure avec l'option CONFIG_NET_NS.
EINVAL CLONE_NEWPID a ete indique dans flags, mais le noyau n'a pas ete
configure avec l'option CONFIG_PID_NS.
EINVAL CLONE_NEWUTS a ete indique dans flags, mais le noyau n'a pas ete
configure avec l'option CONFIG_UTS.
ENOMEM Pas assez de memoire pour copier les parties du contexte du
processus appelant qui doivent etre dupliquees, ou pour allouer
une structure de tache pour le processus fils.
EPERM CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID ou
CLONE_NEWUTS a ete specifie par un processus non privilegie
(processus sans CAP_SYS_ADMIN).
EPERM CLONE_PID a ete reclame par un processus autre que le processus
0.
VERSIONS
Il n'y a pas de definition pour clone() dans la libc5. glibc2 fournit
une definition de clone() comme decrit ici.
CONFORMIT'E
Les appels systeme clone() et sys_clone sont specifiques a Linux et ne
doivent pas etre employes dans des programmes portables.
NOTES
Dans les noyaux 2.4.x, CLONE_THREAD ne rend pas en general le processus
pere de l'appelant pere du nouveau thread. Cependant, pour les versions
2.4.7 a 2.4.18 du noyau, l'attribut CLONE_THREAD impliquait
CLONE_PARENT (de meme qu'avec les noyaux 2.6).
CLONE_DETACHED a existe pendant un moment (introduit dans 2.5.32): le
pere ne veut pas de signal a la mort du fils. Dans 2.6.2, la necessite
d'utiliser ce parametre avec CLONE_THREAD a ete supprimee. Cet attribut
est toujours defini, mais n'a plus aucun effet.
Sur i386, clone() ne devrait pas etre appele via vsyscall, mais
directement en utilisant int $0x80.
Sur IA-64, un appel systeme different est utilise :
int __clone2(int (*fn)(void *),
void *child_stack_base, size_t stack_size,
int flags, void *arg, ...
/* pid_t *ptid, struct user_desc *tls, pid_t *ctid */ );
L'appel systeme __clone2() fonctionne comme clone(), sauf que
child_stack_base pointe sur la plus petite adresse de la pile du fils,
et stack_size indique la taille de la pile sur laquelle pointe
child_stack_base.
BOGUES
Les versions de la bibliotheque C GNU qui gerent la bibliotheque de
gestion des threads NPTL contiennent une fonction enveloppe pour
getpid(2) qui effectue un cache des PID. Ce cache necessite une prise
en charge par l'enveloppe de clone() de la glibc, mais telle qu'il est
actuellement implemente, le cache peut ne pas etre a jour sous
certaines circonstances. En particulier, si un signal est distribue a
un fils juste apres l'appel a clone(), alors un appel a getpid() dans
le gestionnaire de signaux du signal peut renvoyer le PID du processus
appelant (le pere), si l'enveloppe de clone n'a toujours pas eu le
temps de mettre le cache de PID a jour pour le fils. (Cette discussion
ignore le cas ou le fils a ete cree en utilisant CLONE_THREAD, quand
getpid() doit renvoyer la meme valeur pour le fils et pour le processus
qui a appele clone(), puisque l'appelant et le fils se trouvent dans le
meme groupe de threads. Ce probleme de cache n'apparait pas non plus si
le parametre flags contient CLONE_VM.) Pour obtenir la veritable
valeur, il peut etre necessaire d'utiliser quelque chose comme ceci :
#include <syscall.h>
pid_t mypid;
mypid = syscall(SYS_getpid);
VOIR AUSSI
fork(2), futex(2), getpid(2), gettid(2), set_thread_area(2),
set_tid_address(2), tkill(2), unshare(2), wait(2), capabilities(7),
pthreads(7)
COLOPHON
Cette page fait partie de la publication 3.27 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent etre trouvees a l'adresse
<URL:http://www.kernel.org/doc/man-pages/>.
TRADUCTION
Depuis 2010, cette traduction est maintenue a l'aide de l'outil po4a
<URL:http://po4a.alioth.debian.org/> par l'equipe de traduction
francophone au sein du projet perkamon
<URL:http://perkamon.alioth.debian.org/>.
Christophe Blaess <URL:http://www.blaess.fr/christophe/> (1996-2003),
Alain Portal <URL:http://manpagesfr.free.fr/> (2003-2006). Julien
Cristau et l'equipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en ecrivant a
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir acces a la version anglaise de ce document
en utilisant la commande << man -L C <section> <page_de_man> >>.