Nadřazený proces - Parent process

Ve výpočtech je nadřazený proces proces, který vytvořil jeden nebo více podřízených procesů .

Unixové systémy

V operačních systémech podobných systému Unix je každý proces kromě procesu 0 (swapper) vytvořen, když jiný proces provede systémové volání fork () . Proces, který vyvolal fork, je nadřazený proces a nově vytvořený proces je podřízený proces . Každý proces (kromě procesu 0) má jeden nadřazený proces, ale může mít mnoho podřízených procesů.

Jádro operačního systému identifikuje každý proces podle identifikátoru procesu. Proces 0 je speciální proces, který se vytvoří při spuštění systému; po rozvětvení podřízeného procesu (proces 1) se z procesu 0 stane swapovací proces (někdy také známý jako „ nečinná úloha “). Proces 1 , známý jako init , je předkem všech ostatních procesů v systému.

Linux

V linuxovém jádře , ve kterém je velmi malý rozdíl mezi procesy a vlákny POSIX , existují dva druhy nadřazených procesů, jmenovitě skutečný rodič a rodič. Nadřazený je proces, který přijímá signál SIGCHLD při ukončení dítěte, zatímco skutečný rodič je vlákno, které ve skutečnosti vytvořilo tento podřízený proces v prostředí s více vlákny. U normálního procesu jsou obě tyto dvě hodnoty stejné, ale u vlákna POSIX, které funguje jako proces, se mohou tyto dvě hodnoty lišit.

Zombie procesy

Operační systém udržuje tabulku, která spojuje každý proces pomocí identifikátoru procesu (obvykle označovaného jako „ pid “) s daty nezbytnými pro jeho fungování. Během životnosti procesu mohou taková data zahrnovat segmenty paměti určené pro tento proces, argumenty, na které byla vyvolána, proměnné prostředí , čítače o využití prostředků, ID uživatele, ID skupiny a skupina skupin a možná i další typy informací.

Když proces ukončí své provádění, buď voláním exit (i když implicitně, provedením příkazu návratu z hlavní funkce) nebo přijetím signálu, který způsobí jeho náhlé ukončení, operační systém uvolní většinu prostředků a informací souvisejících s tento proces, ale stále uchovává data o využití prostředků a stavovém kódu ukončení , protože nadřazený proces by mohl mít zájem vědět, zda bylo toto dítě úspěšně provedeno (pomocí standardních funkcí k dekódování kódu stavu ukončení) a množství systémových prostředků, které spotřebované během jeho provádění.

Ve výchozím nastavení systém předpokládá, že nadřazený proces se o takové informace v době ukončení dítěte skutečně zajímá, a tak vyšle nadřazenému zařízení signál SIGCHLD, aby upozornil, že je třeba shromáždit některá data o dítěti. Takové shromažďování se provádí voláním funkce rodiny čekání (buď počkejte sama, nebo některý z jejích příbuzných, například waitpid , waitid nebo wait4 ). Jakmile je tato kolekce vytvořena, systém uvolní ty poslední bity informací o podřízeném procesu a odebere jeho pid z tabulky procesu. Pokud však nadřazený proces setrvává ve shromažďování údajů o dítěti (nebo to vůbec neudělá), systém nemá jinou možnost, než ponechat data pid a ukončení dítěte v tabulce procesu na neurčito.

Takový ukončený proces, jehož data nebyla shromážděna , se v jazyce UNIX nazývá proces zombie nebo jednoduše zombie . Název je vtipnou analogií, protože se považuje ukončený proces za „již neživý“ nebo „mrtvý“ - protože již skutečně přestal fungovat - a přetrvávající mrtvý proces stále „ztělesněný“ ve „světě živých“ procesů - proces stůl - což je tedy ve skutečnosti „nemrtvý“ nebo „zombie“.

Procesy zombie mohou představovat problémy v systémech s omezenými zdroji nebo v procesních tabulkách s omezenou velikostí, protože vytváření nových aktivních procesů může zabránit nedostatek zdrojů, které stále využívají dlouhotrvající zombie.

Je proto dobrým programovacím postupem v jakémkoli programu, který by mohl plodit podřízené procesy, aby měly kód, aby se zabránilo tvorbě dlouhotrvajících zombie z jeho původních dětí. Nejviditelnějším přístupem je mít kód, který po vytvoření nového procesu volá někde čekat nebo jeden z jeho příbuzných. Pokud se od programu očekává, že vytvoří mnoho podřízených procesů, které se mohou asynchronně spouštět a ukončit v nepředvídatelném pořadí, je obecně dobré vytvořit obslužnou rutinu pro signál SIGCHLD , která volá jednu z funkcí čekání- rodina ve smyčce, dokud nebude žádné nevybrané dítě data zůstávají. Je možné, aby nadřazený proces zcela ignoroval ukončení svých podřízených a stále nevytvářel zombie, ale to vyžaduje explicitní definici obslužné rutiny pro SIGCHLD prostřednictvím volání sigaction s příznakem speciální volby SA_NOCLDWAIT .

Osiřelé procesy

Osiřelé procesy jsou opačnou situací než procesy zombie, odkazují na případ, kdy se nadřazený proces ukončí dříve, než se podřízené procesy, o nichž se říká, že jsou „osiřelé“. Na rozdíl od asynchronního oznámení dítě-rodič, které se stane, když se podřízený proces ukončí (prostřednictvím signálu SIGCHLD ), podřízené procesy nejsou upozorněny okamžitě, když jejich rodič dokončí. Místo toho systém jednoduše předefinuje pole „nadřazený PID“ v datech podřízeného procesu tak, aby byl procesem, který je „předkem“ všech ostatních procesů v systému, jejichž PID má obecně hodnotu 1 (jeden) a jejichž název je tradičně „init“. Bylo tedy řečeno, že init „adoptuje“ každý osiřelý proces v systému.

Poněkud běžným předpokladem programátorů nových pro UNIX bylo, že podřízené procesy ukončovacího procesu budou převzaty bezprostředním nadřazeným procesem tohoto procesu (tedy „prarodič“ těchto podřízených procesů). Takový předpoklad byl nesprávný - ledaže ten „prarodič“ byl samozřejmě sám o sobě.

Po linuxovém jádře 3.4 to již není pravda, ve skutečnosti mohou procesy vydávat systémové volání prctl () s možností PR_SET_CHILD_SUBREAPER, a v důsledku toho se, ne proces č. 1, stanou rodiči některého z jejich osiřelých potomků. Toto je způsob práce moderních správců služeb a obslužných programů pro kontrolu démonů, včetně systemd, upstart a správce služeb nosh.

Toto je souhrn manuálové stránky, který uvádí, že:

Subreaper plní roli init (1) pro své potomky. Když se proces stane osiřelým (tj. Jeho bezprostřední rodič se ukončí), bude tento proces přeřazen na nejbližšího stále žijícího předchůdce podreaperu. Následně volání getppid () v osiřelém procesu nyní vrátí PID procesu subreaperu a když sirota skončí, je to subreaper proces, který přijme signál SIGCHLD a bude moci čekat (2) na proces zjistit jeho stav ukončení.

Reference

Tento článek je založen na materiálu převzatém z Free On-line Dictionary of Computing před 1. listopadem 2008 a začleněného za podmínek „relicensing“ GFDL , verze 1.3 nebo novější.