Provided by:
manpages-pl-dev_20051117-1_all 
NAZWA
clone - utworzenie procesu potomnego
SKŁADNIA
#include <sched.h>
int clone(int (*fn)(void *), void *child_stack, int flags, void *arg);
_syscall2(int, clone, int, flags, void *, child_stack)
OPIS
clone tworzy nowy proces, podobnie jak fork(2). clone jest funkcją
biblioteczną posadowioną na wierzchu niższego wywołania funkcji
systemowej clone, do której w dalszym ciągu będziemy się odnosić jako
do sys_clone. Opis sys_clone jest podany pod koniec niniejszej strony.
W odróżnieniu od fork(2), funkcje te pozwalają procesom potomnym
współdzielić części ich kontekstu wykonania, takie jak obszar pamięci,
tablica deskryptorów plików czy tablica programów obsługi sygnałów, z
procesem wywołującym. (Należy zauważyć, że na tej stronie podręcznika
"proces wywołujący" normalnie odnosi się do "procesu macierzystego".
Zobacz opis CLONE_PARENT poniżej.)
clone służy głównie do implementacji wątków: zarządzanie wieloma
wątkami programu, które działają równolegle we współdzielonym obszarze
pamięci.
Gdy za pomocą clone tworzony jest proces potomny, uruchamia on
aplikację funkcyjną fn(arg). (Różni się to od fork(2), gdzie proces
potomny kontynuuje wykonanie od miejsca wywołania fork(2).) Argument
fn jest wskaźnikiem do funkcji, która jest wywoływana przez proces
potomny na początku jego działania. Argument arg jest przekazywany do
funkcji fn.
Gdy aplikacja funkcyjna fn(arg) powróci, proces potomny kończy
działanie. Liczba całkowita zwrócona przez fn jest kodem zakończenia
procesu potomnego. Proces potomny może również zakończyć się jawnie
wołając exit(2) lub po otrzymaniu krytycznego sygnału.
Argument child_stack określa położenie stosu używanego przez proces
potomny. Ponieważ potomek i proces wywołujący mogą współdzielić
pamięć, nie jest możliwe, aby proces potomny korzystał z tego samego
stosu, co proces wywołujący. Proces wywołujący musi więc przydzielić
obszar pamięci przeznaczony na stos potomka i przekazać wskaźnik do
tego obszaru w clone. Stosy rosną w dół na wszystkich procesorach, na
których działa Linux (z wyjątkiem procesorów HP PA), więc child_stack
zazwyczaj wskazuje na najwyższy adres obszaru pamięci zarezerwowanego
na stos potomka.
Niższy bajt flags zawiera numer sygnału wysyłanego do rodzica, gdy
proces potomny ginie. Jeśli określono inny sygnał niż SIGCHLD, to
proces macierzysty musi podać opcję __WALL lub __WCLONE czekając na
potmka w wait(2). Gdy sygnał nie zostanie określony, to proces
macierzysty nie zostanie zawiadomiony o zakończeniu pracy potomka.
flags może również być bitowym OR jednej lub kilku następujących
stałych określających, co będzie współdzielone pomiędzy procesem
wywołującym a procesem potomnym:
CLONE_PARENT
(od Linuksa 2.4 w górę) Jeśli CLONE_PARENT będzie ustawione, to
rodzic nowego procesu potomnego (zwrócony przez getppid(2))
będzie ten sam, co dla procesu wywołującego.
Jeśli CLONE_PARENT nie zostanie ustawione, to (jak dla fork(2))
rodzicem potomka będzie proces wywołujący.
Należy zauważyć, że to proces macierzysty, zwracany przez
getppid(2), zostanie powiadomiony o zakończeniu pracy przez
potomka, więc jeśli CLONE_PARENT będzie ustawione, to
zawiadomiony zostanie rodzic procesu wywołującego, a nie sam
proces wywołujący
CLONE_FS
Jeśli ustawione będzie CLONE_FS, to wywołujący i proces potomny
będą współdzielić informacje o systemie plików. Informacje te
obejmują katalog główny systemu plików, bieżący katalog roboczy
i umaskę. Dowolne z wywołań chroot(2), chdir(2) lub umask(2)
wykonane przez proces wywołujący lub proces potomny będzie
obowiązywać również w drugim procesie.
Jeśli CLONE_FS nie zostanie ustawione, to proces potomny będzie
pracować na kopii informacji o systemie plików procesu
wywołującego z chwili wywołania clone. Wywołania chroot(2),
chdir(2), umask(2) wykonane później przez jeden z procesów nie
będą mieć wpływu na drugi proces.
CLONE_FILES
Jeśli CLONE_FILES będzie ustawione, to proces wywołujący i
procesy potomne będą współdzielić tablicę deskryptorów plików.
Deskryptory plików zawsze będą dotyczyć tych samych plików w
procesie wywołującym i w procesach potomnych. Dowolny deskryptor
pliku utworzony przez proces wywołujący, jak też przez proces
potomny będzie obowiązywać również w drugim procesie. Podobnie,
jeśli jeden z procesów zamknie deskryptor pliku lub zmieni
stowarzyszone z nim znaczniki, będzie to obowiązywać również w
drugim procesie.
If CLONE_FILES nie zostanie ustawione, to proces potomny
odziedziczy kopię wszystkich deskryptorów plików otwartych w
procesie macierzystym w chwili wywołania clone. Operacje na
deskryptorach plików przeprowadzone później przez proces
wywołujący lub przez proces potomny nie będą miały wpływu na
drugi proces.
CLONE_NEWNS
(począwszy od Linuksa 2.4.19) Uruchamianie procesu potomnego w
nowej przestrzeni nazw.
Każdy proces istnieje w jakiejś przestrzeni nazw. przestrze
nazw procesu są to dane (zbiór montowań) opisujące hierarchię
plików widzianą przez proces. Po fork(2) lub clone(2), gdy nie
ustawiono znacznika CLONE_NEWNS, potomek żyje w tej samej
przestrzeni nazw, co rodzic. Funkcje systemowe mount(2) i
umount(2) zmieniają przestrzeń nazw procesu wywołującego, a
zatem także innych procesów żyjących w tej samej przestrzeni
nazw, lecz nie mają wpływu na procesy w innej przestrzeni nazw.
Po clone(2), gdy ustawiono znacznik CLONE_NEWNS, sklonowany
potomek jest uruchamiany w nowej przestrzeni nazw, inicjowanej
jako kopia przestrzeni nazw rodzica.
Znacznik CLONE_NEWNS może zostać podany jedynie przez proces
uprzywilejowany. Zabronione jest podanie w tym samym wywołaniu
clone zarówno CLONE_NEWNS, jak i CLONE_FS.
CLONE_SIGHAND
Jeśli CLONE_SIGHAND będzie ustawione, to proces wywołujący i
procesy potomne będą współdzielić tablicę programów obsługi
sygnałów. Jeśli proces wywołujący lub proces potomny wywoła
sigaction(2), aby zmienić zachowanie towarzyszące sygnałowi,
zachowanie to zostanie zmienione również w drugim procesie.
Jednakże, proces wywołujący i proces potomny wciąż będą posiadać
osobne maski sygnałów i zestawy sygnałów oczekujących. Zatem
jeden z nich może zablokować lub odblokować niektóre sygnały za
pomocą sigprocmask(2) nie wpływajac na drugi proces.
Jeśli CLONE_SIGHAND nie zostanie ustawione, to proces potomny
odziedziczy kopię programów obsługi sygnałów od procesu
wywołującego z chwili uruchomienia clone. Wywołania
sigaction(2) przeprowadzone później przez jeden z procesów nie
będą mieć wpływu na drugi proces.
CLONE_PTRACE
Jeśli zostanie podane CLONE_PTRACE, a proces wywołujący będzie
śledzony, to śledzenie obejmie również potomka (zobacz
ptrace(2)).
CLONE_VFORK
Jeśli CLONE_VFORK będzie ustawione, wykonywanie procesu
wywołującego zostanie wstrzymane do chwili, gdy potomek zwolni
swoją pamięć wirtualną za pomocą execve(2) lub _exit(2) (jak
przy vfork(2)).
Jeśli CLONE_VFORK nie zostanie ustawione, wtedy zarówno proces
wywołujący, jak i potomny podlegają po wywołaniu clone
szeregowaniu zadań i aplikacja nie może zakładać, że ich
wykonywanie będzie się odbywać w określonej kolejności.
CLONE_VM
Jeśli CLONE_VM będzie ustawione, to proces wywołujący i potomny
będą działać w tym samym obszarze pamięci. W szczególności,
zapisy do pamięci wykonywane przez proces wywołujący lub przez
proces potomny będą widoczne dla drugiego z procesów. Ponadto,
dowolne mapowania pamięci i usunięcia mapowań wykonane przez
jeden z tych procesów za pomocą mmap(2) lub munmap(2) będą
dotyczyć również drugiego procesu.
Jeśli CLONE_VM nie zostanie ustawione, to proces potomny będzie
działać w kopii obszaru pamięci procesu wywołującego, wykonanej
w chwili wywołania clone. Zapisy do pamięci oraz mapowania i
usunięcia mapowań wykonane przez jeden z tych procesów nie będą
dotyczyć drugiego z nich, tak jak w przypadku fork(2).
CLONE_PID
Jeśli CLONE_PID będzie ustawione, to proces potomny będzie
tworzony z tym samym ID procesu, jaki ma proces wywołujący.
Jeśli CLONE_PID nie zostanie ustawione, to proces potomny będzie
mieć unikalny ID procesu, inny niż ID procesu wywołującego.
Ten znacznik może być podany tylko przez proces uruchamiający
system (PID 0).
CLONE_THREAD
(Począwszy od Linuksa 2.4) Jeśli CLONE_THREAD będzie ustawione,
to potomek będzie umieszczony w tej samej grupie wątków, do
której należy proces wywołujący.
Jeśli CLONE_THREAD nie zostanie ustawione, to potomek będzie
umieszczony w swojej własnej (nowej) grupie wątków, której ID
jest taki sam, jak ID procesu.
(Grupy wątków zostały dodane w Linuksie 2.4 dla obsługiwać wątki
POSIX-owe dla zbioru procesów współdzielących ten sam PID. W
Linuksie 2.4 wywołania funkcji getpid(2) zwracają ID grupy
wątków procesu wywołującego.)
Funkcja systemowa sys_clone odpowiada w sposób bardziej zbliżony
funkcji fork(2), w której wykonanie procesu potomnego jest kontynuowane
od miejsca wywołania. Zatem, sys_clone wymaga jedynie argumentów flags
i child_stack, które mają znaczenie takie samo, jak dla clone. (Należy
zauważyć, że kolejność tych argumentów jest inna aniżeli dla clone.)
Inna różnicą w przypadku sys_clone jest to, że argument child_stack
może być zerem. W tym przypadku, semantyka "kopiowania podczas zapisu"
gwarantuje, że proces potomny otrzyma osobną kopię stosu, gdy
którykolwiek z procesów zmodyfikuje stos. W tym przypadku aby funkcja
działała prawidłowo, nie należy podawać opcji CLONE_VM.
WARTOŚĆ ZWRACANA
Po pomyślnym zakończeniu, w wątku rodzica zwracany jest PID potomka. W
wypadku błędu, w kontekście procesu wywołującego zwracane jest -1, a
proces potomny nie jest tworzony i odpowiednio ustawiane jest errno .
BŁĘDY
EAGAIN Działa już zbyt wiele procesów.
ENOMEM Za mało pamięci aby przydzielić struktuę zadania dla procesu
potomnego, lub aby skopiować niezbędne fragmenty kontekstu
procesu wywołującego.
EINVAL Zwracane przez clone, gdy podano dla child_stack wartość zerową.
EINVAL W flags podano jednocześnie CLONE_FS i CLONE_NEWNS.
EINVAL Podano CLONE_THREAD a nie podano CLONE_SIGHAND. (Począwszy od
Linuksa 2.5.35.)
EPERM CLONE_PID zostało podane przez proces o niezerowym PID.
USTERKI
Dla wersji jądra 2.1.97 nie należy używać znacznika CLONE_PID, gdyż
inne części jądra i większość oprogramowania systemowego wcąż zakłada,
że identyfikatory procesów są unikalne.
Brak wpisu dla clone w wersji 5 biblioteki libc. libc 6 (inaczej, glibc
2) udostępnia clone zgodnie z opisem na niniejszej stronie podręcznika.
UWAGI
Dla wersji jądra 2.4.7-2.4.18 znacznik CLONE_THREAD wymuszał znacznik
CLONE_PARENT.
ZGODNE Z
Funkcje clone i sys_clone są specyficzne dla Linuksa i nie powinny być
używane w programach przenośnych. Pisząc programy aplikacji
wielowątkowych (wiele wątków zarządzających tym samym obszarem
pamięci), lepiej używać biblioteki wspomagającej wielowątkowe API
zgodne z POSIX 1003.1c, takiej jak biblioteka LinuxThreads (zawarta w
glibc2). Zobacz pthread_create(3).
Ta strona podręcznika dotyczy jąder 2.0.x, 2.1.x, 2.2.x, 2.4.x, oraz
glibc 2.0.x i 2.1.x.
ZOBACZ TAKŻE
fork(2) wait(2), pthread_create(3)