Ubuntu Manpage: clone - utworzenie procesu potomnego

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

Uwaga! To tłumaczenie może być nieaktualne!

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)

INFORMACJE O TŁUMACZENIU

       Powyższe tłumaczenie pochodzi z nieistniejącego już Projektu Tłumaczenia Manuali i może nie być aktualne.
       W  razie  zauważenia  różnic  między powyższym opisem a rzeczywistym zachowaniem opisywanego programu lub
       funkcji, prosimy o zapoznanie się z oryginalną (angielską) wersją strony podręcznika za pomocą polecenia:

              man --locale=C 2 clone

       Prosimy  o  pomoc  w  aktualizacji  stron  man  -   więcej   informacji   można   znaleźć   pod   adresem
       http://sourceforge.net/projects/manpages-pl/.

Linux 2.4                                          2001-12-31                                           CLONE(2)