Un proces părinte este, în informatică , un proces care a creat ("a generat") unul sau mai multe procese copil ("procese copil"). Prin urmare, procesul poate deveni copil sau părinte și invers. Astfel, cu ajutorul mecanismelor de legătură în sistemele de operare , se pot forma ierarhii întregi de procese înrudite [1] [2] [3] .
De asemenea, din caracteristicile creării unor astfel de ierarhii, se poate observa că, atunci când se creează procese copil, unele dintre proprietățile procesului părinte pot fi transferate, iar la transmiterea semnalelor de control către procesul părinte, semnalele pot fi transferate de la „părinte”. ” către „copii”. Un exemplu ar fi orice browser modern , în care fiecare filă individuală este creată într-un proces separat de browser copil și dacă trimiteți browserului un semnal de terminare, atunci toate filele sale nu vor mai funcționa.
Pe sistemele de operare asemănătoare Unix , fiecare proces, cu excepția procesului 0 (swapper), este creat atunci când un alt proces emite apelul de sistem fork . Procesul care a numit fork este procesul părinte, iar procesul nou creat este procesul copil. Fiecare proces (cu excepția procesului 0) are un proces părinte, dar poate avea multe procese copil.
Nucleul sistemului de operare identifică fiecare proces prin ID -ul său de proces . Procesul 0 este un proces special care este creat atunci când sistemul pornește, după bifurcarea unui proces copil (procesul 1), procesul 0 devine un „ proces de schimb ” (cunoscut și ca „proces de schimb” și „ sarcina inactivă ”). Procesul 1, cunoscut sub numele de init , este strămoșul principal al oricărui alt proces din sistem.
În nucleul Linux , unde există o diferență foarte subtilă între procesele POSIX și fire de execuție , există două tipuri de procese părinte, și anume „părinte real” și „părinte”. Părintele este procesul care primește semnalul SIGCHLD atunci când copilul se termină, în timp ce părintele real este firul care a creat de fapt acel proces copil într-un mediu cu mai multe fire . Pentru un proces normal, aceste două valori sunt aceleași, dar pentru un fir POSIX care acționează ca un proces, aceste două valori pot fi diferite.
Sistemul de operare menține un tabel care asociază fiecare proces, prin ID-ul său de proces (numit în mod obișnuit „PID” – „Process Identifier”) cu datele necesare funcționării acestuia. Pe durata de viață a unui proces, astfel de date pot include segmentele de memorie alocate procesului, argumentele cu care au fost invocate, variabilele de mediu , contoarele de utilizare a resurselor, ID-ul utilizatorului , ID -ul grupului, de grup și, eventual, alte tipuri de informații.
Atunci când un proces își încheie execuția, fie prin apelarea funcției de ieșire (chiar dacă implicit, prin executarea unei comenzi de returnare de la funcția principală), fie prin primirea unui semnal care face ca acesta să se termine brusc, sistemul de operare eliberează majoritatea resurselor și informațiilor. asociat cu acel proces. , dar păstrează în continuare codul de utilizare a resurselor și de stare de ieșire, deoarece procesul părinte ar putea fi interesat să știe dacă acel proces copil a reușit (folosind funcțiile standard pentru a decoda codul de stare de ieșire) și cantitatea de resurse de sistem, care a consumat în timpul executării sale.
În mod implicit, sistemul presupune că procesul părinte este de fapt interesat de astfel de informații în momentul în care copilul se încheie și, astfel, trimite procesului părinte un semnal SIGCHLD pentru a avertiza că există unele date despre copil care trebuie colectate. Această colectare se face apelând o funcție a familiei wait (fie wait în sine , fie waitpid , waitid sau wait4 ). Odată ce această colectare este finalizată, sistemul eliberează aceste ultime biți de informații despre procesul copil și elimină PID-ul acestuia din tabelul de procese. Cu toate acestea, dacă procesul părinte întârzie (sau nu reușește deloc să facă acest lucru) în colectarea datelor copilului, sistemul nu are de ales decât să stocheze PID-ul copilului și datele de terminare în tabelul de proces pe termen nelimitat.
Un astfel de proces încheiat, ale cărui date nu au fost colectate, se numește proces zombie sau pur și simplu zombi în limbajul UNIX . Numele este o analogie jucăușă datorită considerării unui proces încheiat ca „nu mai este în viață” sau „mort”, deoarece într-adevăr a încetat să mai funcționeze și nu poate „moară”.
Procesele zombie pot crea probleme pe sistemele cu resurse limitate sau pe tabele de procese de dimensiuni limitate, deoarece crearea de noi procese active poate fi prevenită prin lipsa resurselor care sunt încă rezervate de procesele zombie.
Un proces orfan este opusul unui proces zombie, referindu-se la cazul în care un proces părinte iese înainte ca procesele sale secundare să fie considerate „orfani”. Spre deosebire de notificarea asincronă de la copil la părinte care are loc atunci când procesul copil se termină (prin semnalul SIGCHLD), procesele copil nu sunt notificate la timp atunci când procesul lor părinte a fost supus încetării. În schimb, sistemul pur și simplu redefinește câmpul „PID părinte” din datele procesului copil la un proces care este „strămoșul” oricărui alt proces din sistem, al cărui PID este de obicei „1” și al cărui nume este în mod tradițional „init” ( cu excepţia nucleului Linux).versiunea 3.4 şi ulterioară). Aceasta înseamnă că init „adoptă” fiecare proces orfan din sistem dacă își pierde părintele.
După kernel-ul Linux 3.4, acesta nu mai este cazul, de fapt, procesele pot lansa apelul de sistem prctl cu opțiunea PR_SET_CHILD_SUBREAPER, și, ca urmare, ele, și nu procesul numărul 1, vor deveni părintele oricăruia dintre copiii lor orfani. proceselor. Acesta este modul în care funcționează managerii de servicii moderni și utilitarele de control demon , inclusiv managerul de servicii systemd , upstart și nosh.
Procesul copilului