CONTROLUL PROCESELOR

Ultimul capitol a definit contextul unui proces si a explicat algoritmii care il manipuleaza; acest capitol va descrie utilizarea si implementarea apelurilor sistem care controleaza contextul unui proces. Apelul sistem fork creaza un nou proces, apelul exit termina executia unui proces si apelul wait permite unui proces parinte sa-si sincronizeze executia cu terminarea unui proces fiu.

Semnalele informeaza procesele despre aparitia evenimentelor asincrone. Deoarece nucleul sincronizeaza executia apelurilor sistem wait si exit prin intermediul semnalelor, sunt prezentate semnalele inaintea apelurilor sistem wait si exit.

Apelul sistem exec permite unui proces sa lanseze in executie un 'nou' program, suprapunand peste spatiul propriu de adrese imaginea unui fisier executabil. Apelul sistem brk permite unui proces sa aloce mai multa memorie in mod dinamic; similar, sistemul permite stivei utilizator sa creasca in mod dinamic prin alocarea unui spatiu suplimentar cand este necesar, folosind aceleasi mecanisme ca si pentru apelul sistem brk.In sfarsit, este prezentata pe scurt constructia principalelor bucle ale shell-lui si ale procesului init.

Figura 1 prezinta relatiile existente intre apelurile sistem decrise in acest capitol si algoritmii de gestiune a memoriei descrisi in capitol anterior. Desi aproape toate apelurile sistem utilizeaza algoritmii sleep si wakeup, acest lucru nu este aratat in figura. In plus, apelul exec interactioneaza cu algoritmii sistemului de fisiere descrisi in capitolele 4 si 5.

Fig. 1. Apelurile sistem ale proceselor si relatiile cu alti algoritmi

1 Crearea proceselor

Singurul mod prin care un utilizator poate crea un nou proces in UNIX este folosirea apelului sistem fork. Procesul care apeleaza fork este numit proces parinte, iar noul proces creat este numit proces fiu. Sintaxa pentru apelul sistem fork este:

pid=fork();

La revenirea din apelul sistem fork, doua procese au copii identice ale contextului de nivel utilizator, exceptie facand valoarea de retur pid. In procesul parinte, pid are valoarea identificatorului procesului fiu; in procesul fiu, pid are valoarea zero. Procesul 0, creat intern de catre nucleu cand sistemul este initializat este singurul proces care nu este creat prin intermediul apelului sitem fork.

Nucleul executa urmatoarea secventa de operatii la apelul sistem fork:

Aloca o intrare in tabela de procese penrtru noul proces.

Atribuie un identificator unic procesului fiu.

Face o copie logica a contextului procesului parinte. Deoarece in mod sigur portiuni ale procesului, cum ar fi zona de cod, pot fi partajate intre procese, nucleu poate uneori incrementa numarul de referiri al unei regiuni in schimul copierii regiunii la o noua locatie fizica in memorie.

Incrementeza contorii tabelei de inoduri si tabelei de fisiere asociate procesului.

Intoarce in procesul parinte numarul identificatorului atribuit procesului fiu si valoarea zero in procesul fiu.

Implementarea apelului sistem fork nu este triviala deoarece procesul fiu pare a-si incepe secventa de executie dintr-un punct aflat in "aer". Algoritmul pentru apelul fork difera putin de la sistemul cu paginare la cerere la sistemul cu swapping; discutia care urmeaza se bazeaza pe sistemul traditional cu swapping dar va sublinia locurile in care apar schimbari pentru sistemul cu paginare la cerere. De asemenea se presupune ca sistemul are suficienta memorie pentru a pastra procesul fiu.

Capitolul 12 va considera cazul in care nu exista suficienta memorie pentru procesul fiu si descrie implementarea apelului sistem fork intr-un sistem bazat pe paginare la cerere.

Figura 2. Algoritmul pentru fork

Figura 2 prezinta algoritmul pentru apelul sistem fork. Nucleul se asigura mai intai daca are resurse disponibile pentru a termina cu succes apelul sistem fork.

Intr-un sistem bazat pe swapping, acesta are nevoie de spatiu in memorie sau pe disk pentru a pastra procesul fiu; intr-un sistem bazat pe paginare la cerere, acesta trebuie sa aloce memorie pentru tabelele auxiliare cum ar fi tabelele de pagini. Daca nu sunt resurse disponibile, apelul sistem fork esueaza. Nucleul gaseste o intrare in tabela de procese pentru a incepe constructia contextului procesului fiu si se asigura ca utilizatorul care a apelat fork nu are deja prea multe procese in curs de executie. De asemenea selecteaza un identificator unic pentru noul proces, acesta trebuind sa fie mai mare decat cel mai recent atribuit. Daca un alt proces detine deja acel numar identificator, nucleul incearca sa atribuie urmatorul numar identificator mai mare. Cand numerele identificator ajung la valoarea maxima, atribuirea acestora incepe din nou de la zero. Deoarece cele mai multe procese se executa pentru scurt timp, cele mai multe numere identificator nu sunt utilizate atunci cand atribuirea identificatorilor se reia.

Sistemul limiteaza numarul proceselor care se pot executa simultan de catre un utilizator astfel ca acesta nu poate ocupa multe intrari din tabela de procese, lucru care ar duce la impiedicarea altor utilizatori de a crea procese noi. De asemenea utilizatorii obisnuiti nu pot crea un proces care ar duce la ocuparea ultimei intrari din tabela de procese, altfel sistemul s-ar putea bloca. Deci, daca nici un proces nu se va termina in mod natural, nu se va putea crea un nou proces deoarece nu exista nici o intrare libera in tabela de procese. Pe de alta parte, un administrator de retea poate executa un numar nelimitat de procese, numarul acestora fiind limitat doar de marimea tabelei de procese si, trebuie mentionat faptul ca acesta poate ocupa ultima intrare libera din tabela de procese. Administratorul de retea are, astfel, posibilitatea de a lansa un proces care sa forteze celelalte procese sa se termine (vezi Sectiunea 2.3 pentru apelul sistem kill).

Mai departe nucleul initializeaza intrarea din tabela de procese pentru procesul fiul creat prin copierea diferitelor campuri din intrarea procesului parinte. De exemplu, procesul fiu mosteneste numerele identificatorilor utilizator efectiv si real ai procesului parinte si valoarea nice a acestuia, utilizata pentru calcularea prioritatii de planificare. Nucleul depune identificatorul procesului parinte in intrarea procesului fiu, pune procesul fiu in structura arborescenta a proceselor si initializeaza diferiti parametri de planificare, cum ar fi valoarea prioritatii initiale, folosirea initiala a U.C.P. si alte campuri de timp. Starea initiala a procesului este 'in curs de creare') Figura 7.1).

Nucleul ajusteaza acum contoarele de referinta pentru fisierele cu care procesul fiu este automat asociat.

Procesul fiu se afla in directorul curent al procesului parinte. Numarul proceselor care au acces la director va fi incrementat cu 1 si, in consecinta, nucleul incrementeaza contorul de referinta al inodului. Apoi, daca procesul parinte sau unul din stramosi executase apelul sistem chroot pentru a schimba radacina, procesul fiu mosteneste radacina schimbata si incrementeaza contorul de referinta al inodului respectiv. In final, nucleul cauta in tabela descriptorilor de fisiere utilizator specifica procesului parinte, gaseste intrarile pentru fisierele deschise, cunoscute de catre proces si incrementeaza contoarele de referinte din intrarile in tabela globala de fisire asociate fisierelor deschise. Procesul fiu nu numai ca mosteneste drepturile de acces la fisierele deschise, dar si partajeaza accesul la fisiere cu procesul parinte deoarece ambele procese manipuleaza aceleasi intrari din tabela de fisiere. Efectul apelului sistem fork este identic cu cel al apelului dup raportat la fisierele deschise: o noua intrare in tabela descriptorilor de fisiere utilizator va adresa o intrare din tabela de fisiere pentru un fisier deschis. Totusi, pentru apelul sistem dup, intrarile din tabela descriptorilor de fisiere utilizator sunt asociate unui singur proces, pe cand pentru apelul sistem fork, ele sunt in procese diferite.

Nucleul este acum gata pentru a crea contextul de nivel utilizator al procesului fiu. Nucleul aloca memorie pentru zona u area, regiunile si tabelele de pagini (PT) auxiliare ale procesului fiu, duplica fiecare regiune din procesul parinte folosind algoritmul dupreg si ataseaza fiecare regiune la procesul fiu folosind algoritmul attachreg. In sistemul bazat pe swapping, acesta copiaza continutul regiunilor care nu sunt folosite in comun intr-o noua zona a memoriei principale. In sectiunea 7.2.4 s-a aratat ca zona u area contine un pointer catre intrarea asociata din tabela de procese. Exceptand acest camp, continutul zonei u area a fiului este initial identic cu cel al zonei u area a parintelui, dar ele pot sa difere dupa terminarea apelului sistem fork. De exemplu procesul parinte poate deschide un nou fisier dupa terminarea apelului sistem fork, dar procesul fiu nu poate avea automat acces la el.

Pana in prezent, nucleul a creat portiunea statica a contextului procesului fiu; acum acesta creaza portiunea dinamica a acestuia. Nucleul copiaza cadrul 1 al contextului procesului parinte, continand contextul registru salvat si cadrul stivei nucleu pentru apelul sistem fork. Daca implementarea este una in care stiva nucleu este parte a zonei u area, nucleul creaza automat stiva nucleu a procesului fiu cand acesta creaza zona u. area a acestuia. Altfel, procesul parinte trebui sa copieze propria stiva nucleu intr-o zona privata de memoriei asociata cu procesul fiu. In ambele cazuri, stivele nucleu pentru procesele fiu si parinte sunt identice.

Nucleul creaza apoi un cadru context identic (2) pentru procesul fiu, continand contextul registru salvat pentru cadrul context (1). Acesta seteaza numaratorul de program si alti registri in contextul registru salvat astfel incat sa poata reface contextul procesului fiu, desi acesta nu a fost executat niciodata inainte, si astfel incat procesul fiu sa se poata recunoaste singur ca fiind un proces fiu cand acesta se va executa.De exemplu, daca codul nucleu testeaza valoarea registrului 0 pentru a decide daca procesul este parinte sau fiu, acesta scrie valoarea corespunzatoare in contextul registru salvat corespunzator fiului in cadrul context 1. Mecanismul este similar cu cel discutat pentru o comutare de context.

Cand contextul procesului fiu este gata, procesul parinte termina partea sa de apel fork prin schimbarea starii fiului in 'gata de executie)' si prin returnarea catre utilizator a identificatorului de proces al fiului. Nucleul planifica mai tarziu procesul fiu pentru executie cu ajutorul algoritmului normal de planificare si procesul fiu isi termina astfel partea sa de apel fork. Contextul procesului fiu a fost completat de catre procesul tata; in nucleu, procesul fiu pare a fi trezit dupa asteptarea eliberarii unei resurse. Procesul fiu executa portiunea de cod din apelului sistem fork, in acord cu numaratorul de program, pe care nucleul l-a refacut din contextul registru salvat aflat in cadrul context 2 si intoarce zero la revenirea din apelul sistem.

Figura 3 da o imagine logica a proceselor parinte si fiu si a relatiilor lor cu alte structuri de date ale nucleului, imediat dupa terminarea apelului sistem fork. Concluzionand, ambele procese partajeaza fisierele pe care procesul parinte le-a deschis in timpul apelului sistem fork si contorul de referinta din intrarile tabelei de fisiere pentru aceste fisiere creste cu 1. Similar, procesul fiu are acelasi director curent si aceeasi radacina ca a parintelui si contoarele de referinta ale inodurilor apartinand acestor directoare cresc cu valoarea 1. Procesele au copii identice ale regiunilor de text, date si stiva utilizator; tipul regiunii si implementarea sistemului stabilesc daca procesele pot partaja o copie fizica a regiunii de text.

Consideram programul din figura 4, un exemplu de partajare a accesului la fisiere pe timpul executarii apelului sistem fork. Un utilizator poate apela programul cu doi parametri, numele unui fisier existent si numele unui fisier nou care va fi creat. Procesul deshide fisierul existent, creaza noul fisier si presupunand ca nu apar erori, executa apelul sistem fork si creaza un proces fiu.

Intern, nucleul face o copie a contextului procesului parinte pentru procesul fiu iar procesul parinte si procesul fiu se executa in spatii de adrese diferite.

Fiecare proces poate accesa copiile private ale variabilelor globale fdrd, fdwt si c si copiile private ale variabilelor de stiva argc si argv, dar nici un proces nu poate accesa variabilele celuilalt proces. Cu toate acestea, nucleul copiaza zona u area a procesului parinte in procesul fiu in timpul apelului sistem fork si fiul astfel mosteneste dreptul de acces la fisierele parintelui (acestea sunt fisierele pe care parintele le-a deschis si creat) folosind aceiasi descriptori de fisiere.

Figura 3. Relatii intre procesul parinte si procesul fiu dupa

executarea apelului sistem fork

Procesele parinte si fiu apeleaza functia rdwrt independent, apoi executa un ciclu, citind cate un octet din fisierul sursa si scriindu-l apoi in fisierul destinatie. Functia rdwrt termina atunci cand apelul sistem read intalneste sfarsitul fisierului. Nucleul incrementase contoarele fisierelor sursa si destinatie din tabela de fisiere si descriptorii fisierelor din ambele procese refera aceeasi intrare din tabela de fisiere. Asa ca, descriptorii de fisier fdrd pentru ambele procese refera aceeasi intrare din tabela de fisiere pentru fisierul destinatie si descriptorii de fisier fdwr pentru ambele procese refera aceeasi intrare din tabela de fisiere pentru fisierul sursa.

Figura 4. Program in care procesele parinte si fiu partajeaza

accesul la fisiere

De aceea, cele doua procese nu vor citi sau scrie niciodata de la (la) aceleasi adrese, deoarece nucleul incrementeaza deplasamentul in fisier dupa fiecare apel de citire sau scriere. Desi procesele par sa copieze fisierul sursa de doua ori mai repede, continutul fisierului sursa depinde de ordinea in care nucleul a planificat procesele.Daca acesta planifica procesele astfel incat ele sa alterneze in executarea propriilor apeluri sistem, sau chiar daca alterneaza executia perechii de apeluri read-write dintr-un proces, continutul fisierului destinatie va fi identic cu continutul fisierului sursa. Dar sa consideram urmatorul scenariu, in care procesele sunt gata sa citeasca o scecventa de doua caractere 'ab' din fisierul sursa. Presupunem ca procesul parintre citeste caracterul 'a', dupa care nucleul face o comutare de context pentru a executa procesul fiu inainte ca parintele sa scrie. Daca procesul fiu citeste caracterul b si il scrie in fisierul destinatie inainte ca procesul parinte sa fie reprogramat, fisierul destinatie nu va contine sirul 'ab', ci 'ba'. Nucleul nu garanteaza rata relativa de executie a proceselor.

Acum sa consideram programul din figura 5, care mosteneste descriptorii de fisiere 0 si 1 (intrarea si iesirea standard) de la procesul parinte. Executia fiecarui apel sistem pipe aloca in plus doi descriptori de fisiere in sirurile toIpar si toIchild. Procesul executa apelul sistem fork si face o copie a contextului sau: fiecare proces poate accesa datele proprii, ca in exemplul anterior. Procesul parinte inchide fisierul sau standard de iesire (descriptorul de fisier 1) si duplica (dup) descriptorul de scriere intors de apelul sistem pipe in sirul toIchild. Deoarece primul slot liber din tabela descriptorilor de fisiere utilizator a procesului parinte este chiar acela eliberat prin apelul sistem close, nucleul copiaza descriptorul de scriere rezultat in urma executarii apelului sistem pipe in slotul 1 al acesteia si astfel descriptorul fisierului standard de iesire devine descriptorul de scriere al pipe-lui pentru toIchild. Procesul parinte face operatii similare astfel incat descriptorul intrarii standard sa devina descriptorul de citire al pipe-lui pentru toIpar. Analog, procesul fiu isi inchide fisierul standard de iesire (descriptor 0) si duplica descriptorul de citire al pipe-lui pentru toIchild. Intrucat primul slot liber in tabela descriptorilor de fisiere utilizator este slotul intrarii standard anterioare, intrarea standard a fiului devine descriptorul de citire al pipe-lui pentru toIchild. Fiul face operatii similare astfel incat descriptorul iesirii standard sa devina descriptorul de scriere al pipe-lui pentru toIpar. Ambele procese inchid descriptorii de fisiere intorsi de apelul pipe )o buna metoda de programare). Ca rezultat, cand procesul parinte scrie la iesirea standard, acesta scrie in pipe-ul toIchild si trimite date procesului fiu, care citeste pipe-ul ca pe propria intrare standard. Cand procesul fiu scrie la iesirea standard, acesta scrie in pipe-ul toIpar si trimite datele procesului parinte care citeste pipe-ul ca pe propria intrare standard. Procesele schimba astfel mesaje prin intermediul pipe-urilor.

Rezulatele acestui exemplu sunt aceleasi, indiferent de ordinea in care procesele isi executa apelurile sistem respective. Adica nu este nici o diferenta, daca procesul parinte revine din apelul sistem fork inaintea fiului sau dupa el. Similar, nu este nici o diferenta data de ordinea relativa in care procesele isi executa apelurile sistem pana cand acestea intra in propriul ciclu: structurile nucleului sunt identice. Daca procesul fiu executa apelul sistem read inainte ca procesul parinte sa execute apelul sistem write, procesul fiu va intra in asteptare pana cand procesul parinte scrie in pipe si il trezeste. Daca procesul parinte scrie pipe-ul inainte ca procesul fiu sa citeasca din pipe, procesul parinte nu va termina de citit de la intrarea sa standard pana cand fiul nu citeste de la intrarea sa standard si nu scrie la iesirea sa standard. Din acest motiv, ordinea de executie este fixata: fiecare proces termina un apel sistem read si un apel sistem write si nu poate executa urmatorul apel sistem read pana cand celalalt proces nu termina un apel sistem read si un apel sistem write.

Figura 5. Utilizarea pipe-urilor, a apelurilor sistem dup si fork

Procesul parinte face exit dupa cele 15 iteratii din ciclu; apoi procesul fiu citeste 'sfarsit de fisier' (EOF), deoarece pipe-ul nu are procese care sa scrie, si se termina. Daca procesul fiu ar fi scris in pipe dupa ce procesul parinte s-a terminat, primul ar fi receptionat un semnal care indica scrierea intr-un pipe fara procese cititoare. Am mentionat mai devreme ca o metoda buna de programare este aceea de a inchide descriptorii de fisiere inutili. Acest lucru este adevarat din trei motive. Primul, se conserva descriptorii de fisiere in limitele impuse de sistem. Al doilea, daca un proces fiu apeleaza execs, descriptorii fisierelor raman asignati in noul context, asa cum se va vedea. Inchiderea fisierelor neesentiale inainte unui apel exec permite programelor sa ruleze intr-un mediu curat, numai cu descriptorii fisierelor standard de intrare, iesire si eroare deschisi. Al treilea, citirea dintr-un pipe intoarce 'sfarsit de fisier' doar daca nici un proces nu are pipe-ul deschis pentru scriere.

Daca procesul cititor pastreaza descriptorul de scriere al pipe-lui deschis, acesta nu va sti niciodata cand inchid pipe-ul procesele care scriu. Exemplul de mai sus nu ar lucra corect daca procesul fiu nu si-ar inchide descriptorii de scriere ai pipe-lui inaintea intrarii in ciclu.

2 Semnale

Semnalele informeaza procesele despre aparitia evenimentelor asincrone. Procesele isi pot trimite semnale prin intermediul apelului sistem kill, sau nucleul poate trimite intern semnale. Exista 19 semnale in versiunea de UNIX System V care pot fi clasificate dupa cum urmeaza :

Semnale pentru terminarea proceselor, transmise atunci cind un proces executa apelul sistem exit sau cand un proces executa apelul sistem signal cu parametrul 'terminare fiu';

Semnale de atentionare in cazul exceptiilor produse de procese, de exemplu cand un proces acceseaza o adresa in afara spatiului lor virtual de adrese, cand un proces incearca sa scrie in zonele de memorie protejate la scriere (cum ar fi codul programului), cand executa o instructiune privilegiata, sau pentru diferite erori hardware;

Semnale pentru situatii fara iesire aparute in timpul apelurilor sistem, cum ar fi lipsa resurselor in timpul executiei apelului sistem exec dupa ce spatiul initial de adrese fusese eliberat (vezi Paragraful 5);

Semnale determinate de conditii de eroare neasteptate aparute in timpul unui apel sistem, cum ar fi executarea unui apel sistem inexistent (procesul a furnizat numarul unui apel sistem care nu corespunde unui apel sistem corect), scrierea unui pipe care nu are proces cititor, sau folosirea unei valori 'referinta' ilegale pentru apelul sistem lseek. Ar fi mult mai comod sa se intoarca o eroare in astfel de situatii in schimbul generarii unui semnal, dar folosirea semnalelor pentru a abandona procesele care nu se comporta corespunzator este mult mai practica (folosirea semnalelor in aceste cazuri suplineste lipsa verificarii erorilor de catre programator in cazul apelurilor sistem) ;

Semnale provenite de la procesele in modul utilizator, de exemplu cand un proces doreste sa receptioneze un semnal alarm dupa un anumit timp, sau cand procesele trimit unul altuia semnale in mod arbitrar, prin intermediul apelului sistem kill;

Semnale provenite de la interactiunea cu un terminal, atunci cand un utilizator intrerupe un terminal, sau cand un utilizator apasa tastele 'break' sau 'delete';

Semanale de urmarire a executiei unui proces.

Tratarea semnalelor difera in funcie de modul in care nucleul trimite un semnal unui proces, modul in care trateaza procesul un semnal si modul in care un proces isi controleaza reactia la aparitia unui semnal. Pentru a trimte un semnal unui proces, nucleul seteaza un bit in campul "semnal" din intrarea tabelei de procese, corespunzator tipului semnalului receptionat. Daca procesul este in asteptare la o prioritate intreruptibila, nucleul il trezeste. Sarcina celui care trimite semnalul (proces sau nucleu) este terminata. Un proces poate memora diferite tipuri de semnale receptionate, dar nu are memorie pentru a pastra numarul de semnale de acelasi tip pe care le-a receptionat. De exemplu, daca un proces receptioneaza un semnal hangup si un semnal kill, acesta seteaza bitii corespunzatori din campul semnal din tabela de procese, dar nu poate spune cate instante ale semnalelor au fost receptionate.

Figura 6. Verificarea si tratarea semnalelor in diagrama de stari ale

procesului

Nucleul verifica receptionarea unui semnal cand un proces este gata sa se intoarca din modul nucleu in modul utilizator si cand acesta intra sau paraseste starea de asteptare la o prioritate de planificare scazuta (vezi Figura 6). Nucleul trateaza semnalele doar cand un proces se intoarce din modul nucleu in modul utilizator. Astfel, un semnal nu are un efect imediat intr-un proces care ruleaza in modul nucleu. Daca un proces ruleaza in modul utilizator si nucleul trateaza o intrerupere care presupune trimiterea unui semnal catre proces, nucleul va recunoaste si trata semnalul cand se va intoarce din intrerupere. Astfel, un proces nu se va executa niciodata in modul utilizator inainte de tratarea semnalelor importante.Figura 7 prezinta algoritmul pe care nucleul il executa pentru a determina daca un proces a receptionat un semnal. Cazul semnalelor de tipul 'terminare fiu' va fi tratat mai tarziu. Asa cum se va vedea, un proces are posibilitatea de a ignora semnalele primite prin intermdiul apelului sistem signal. In algoritmul issig, nucleul sterge indicatorii care marcheaza aparitia semnalelor pe care procesul vrea sa le ignore dar noteaza existenta semnalelor pe care acesta nu le ignora.

Figura 7. Algoritm pentru recunoasterea semnalelor

2.1 Tratarea semnalelor

Nucleul trateaza semnalele in contextul procesului care le receptioneaza, deci un proces trebuie sa ruleze pentru a putea trata semnalele. Exista trei cazuri in tratarea semnalelor: procesul se termina la receptionarea semnalului, acesta ignora semnalul, sau executa o functie particulara (definita de utilizator). Actiunea implicita este de a apela exit in modul nucleu, dar un proces poate specifica o actiune speciala, pe care sa o execute la receptionarea unui anumit semnal cu ajutorul apelul sistem signal.

Sintaxa pentru apelul sistem signal este

oldfunction=signal (signum, function);

unde signum este numarul semnalului pentru care procesul specifica actiunea, function este adresa functiei (utilizator) pe care procesul doreste sa o apeleze la receptia semnalului si valoarea de revenire oldfunction valoarea parametrului function la ultimul apel al lui signal cu parametrul signum. Procesul poate apela signal cu valoarea 1 sau 0 in loc de adresa functiei: procesul va ignora viitoarele aparitii ale semnalului daca valoarea parametrului este 1 (Paragraful 4 trateaza cazul special pentru ignorarea semnalului 'terminare fiu') si se termina daca valoarea parametrului este 0 (valoarea implicita). U area contine un sir de campuri pentru tratarea semnalelor, un camp pentru fiecare semnal definit in sistem. Nucleul stocheaza adresa functiei definite de utilizator in campul care corespunde numarului semnalului. Modul de tratare a semnalelor de un anumit tip nu are efect in tratarea semnalelor de alte tipuri.

Figura Algoritm pentru tratarea semnalelor

Cand trateaza un semnal (figura 8) nucleul determina tipul semnalului si sterge bitul semnalului corespunzator din intrarea tabelei de procese, setat cand procesul a receptionat semnalul. Daca functia de tratare a semnalului are valoarea implicita, nucleul va scoate imaginea a procesului pentru anumite tipuri de semnale inainte de terminarea acestora.Aceasta este o facilitate pentru programatori, permitand acestora depaneze programele. Nucleul scoate imaginea procesului pentru semnalele care sugereaza ca ceva este gresit in proces, cum ar fi faptul ca procesul executa o instructiune ilegala sau cand acesta acceseaza o adresa in afara spatiului sau virtual de adrese. Dar nucleul nu scoate imaginea procesului pentru semnalele care nu implica o eroare la executarea programului. De exemplu, receptionarea unui semnal de intrerupere, trimis cand un utilizator apasa tastele 'delete' sau 'break' la terminal, sugereaza ca utilizatorul doreste sa termine prematur un proces iar receptionarea semnalului hangup sugereaza ca terminalul login nu va mai fi 'conectat' pentru mult timp. Aceste semnale nu implica faptul ca ceva este gresit in proces. Semnalul quit, totusi, provoaca scoaterea imaginii procesului chiar daca este initiat din afara. Uzual trimis prin apasarea tastei control + bara verticala, semnalul quit permite programatorului sa obtina o imagine a procesului care se executa, imagine care este folosita cand acesta intra intr-un ciclu infinit.

Cand un proces receptioneaza un semnal pe care anterior a decis sa-l ignore, acesta continua ca si cand semnalul nu ar fi aparut. Deoarece nucleul nu reseteaza campul din u area care arata ca semnalul este ignorat, procesul va ignora semnalul si la aparitia ulterioara a acestuia. Daca un proces receptioneaza un semnal pe care acesta anterior a decis sa-l intercepteze, acesta executa functia de tratare a semnalului specificata de utilizator imediat dupa revenirea in modul utilizator, dupa ce nucleul parcurge urmatorii pasi:

Nucleul acceseaza contextul registru salvat, gasind numaratorul de program si indicatorul de stiva pe care acesta ii salvase pentru revenirea in procesul utilizator.

Acesta sterge campul rutinei de tratare a semnalului din u area, setandu-l la valoarea implicita.

Nucleul creaza un cadru stiva nou in stiva utilizator, scriind aici valorile numaratorului de program si indicatorului de stiva restabilite din contextul registru salvat si aloca spatiu nou, daca este necesar. Stiva utilizator arata ca si cum procesul a apelat o functie de nivel utilizator (interceptorul de semnale) in punctul in care acesta a facut apelul sistem sau in punctul in care nucleul il intrerupsese (inainte de recunoasterea semnalului).

Nucleul schimba contextul registru salvat: acesta seteaza valoarea numaratorului de programe la adresa functiei de interceptare a semnalului si seteaza valoarea indicatorului de stiva pentru a tine evidenta cresterii stivei utilizatorului.

Dupa intoarcerea din modul nucleu in modul utilizator, procesul va executa functia de tratare a semnalului; cand acesta termina functia de tratare a semnalului, se intoarce in punctul din codul utilizator unde a aparut apelul sistem sau s-a produs intreruperea, imitand o intoarcere din apelul sistem sau intrerupere.

De exemplu, figura 9 contine un program care intercepteaza semnale de intrerupere (SIGINT) si isi trimite un semnal de intrerupere (rezultatul apelului kill); figura 10 contine partile relevante ale programului dezasamblat pe un VAX 11/780. Cand sistemul executa procesul, apelul la rutina de biblioteca kill se va face la adresa ee (in hexazecimal) si rutina executa instructiunea chmk (schimbarea modului in modul nucleu) la adresa 10a pentru a face apelul sistem kill. Adresa de retur din apelul sistem este 10c.

In timpul executarii apelului sistem, nucleul trimite un semnal de intrerupere catre proces. Nucleul ia in considerare semnalul de intrerupere cand se intoarce in modul utilizator, scoate adresa 10c din cotextul registru salvat si o plaseaza in stiva utilizator.

Nucleul ia adresa functiei de interceptare a semnalului (catcher), 104, si o pune in contextul registru salvat. Figura 11 ilustreaza starile stivei utilizator si contextul registru salvat.

Exista cateva anomalii in algoritmul descris aici pentru tratarea semnalelor. Prima si cea mai importanta este ca inainte ca un proces sa se intoarca in modul utilizator dupa ce acesta trateaza un semnal, nucleul sterge campul din u area care contine adresa functiei utilizator de tratare a semnalului. Daca procesul doreste sa trateze semnalul din nou, acesta trebuie sa apeleze din nou apelul sistem signal.

Aceasta are din nefericire si alte consecinte: o conditie de concurenta rezulta deoarece a doua instanta a semnalului poate sosi inainte ca procesul sa aiba ocazia sa invoce apelul sistem. Pentru ca procesul este executat in modul utilizator, nucleul ar putea face o comutare de context, crescand sansa ca acesta sa receptioneze semnalul inaintea resetarii interceptorului de semnal.

Figura 9. Codul sursa al programului care intercepteaza semnale

**** DEZASAMBLORUL VAX ****

Imain()

e4:

e6: pushab 0x18(pc)

ec: pushl $0x2

a urmatoarea linie apeleaza signal

ee: calls $0x2,0x23(pc)

f5: pushl $0x2

f7: clrl -(sp)

a urmatoarea linie apeleaza rutina de biblioteca kill

f9: calls $0x2,0x8(pc)

100: ret

101: halt

102: halt

103: halt

Icatcher()

104:

106: ret

107: halt

Ikill()

a urmatoarea linie executa o 'instrucTiune trap'

(schimba modul in modul nucleu)

10a: chmk $0x25

10c: bgequ 0x6 <0x114>

10e: jmp 0x14(pc)

114: clrl r0

116: ret

Figura 10. Dezasamblarea programului care intercepteaza semnale

Figura 11. Stiva utilizator inainte si dupa receptionarea semnalului

Programul din figura 12 ilustreaza conditia de concurenta. Procesul apeleaza signal pentru a aranja interceptarea semnalului de intrerupere si executa functia sigcatcher. Apoi creaza un proces fiu, invoca apelul sistem nice pentru a-si micsora prioritatea de planificare relativa la procesul fiu (vezi capitolul 9) si intra intr-un ciclu infinit.

Procesul fiu isi suspenda executia pentru 5 secunde pentru a da procesului parinte posibilitatea sa execute apelul sistem nice si sa-si scada prioritatea. Apoi procesul fiu intra intr-un ciclu, trimitand un semnal de intrerupere (prin apelul sistem kill) procesului parinte in timpul fiecarei iteratii.

Daca apelul sistem kill se termina datorita unei erori, probabil pentru ca procesul parinte nu mai exista, procesul fiu se termina. Ideea este ca procesul parinte ar trebui sa invoce interceptorul de semnale de fiecare data cand acesta receptioneaza un semnal de intrerupere. Interceptorul de semnale tipareste un mesaj si apeleaza din nou signal pentru a intercepta urmatoarea aparitie a unui semnal de intrerupere, si procesul parinte continua sa execute ciclul infinit.

Figura 12. Program ce demonstreaza conditiile de concurenta in

interceptarea semnalelor

Este posibil sa apara, totusi, urmatoarea secventa de evenimente:

1. Procesul fiu trimite un semnal de intrerupere procesului

parinte.

2. Procesul parinte intercepteaza semnalul si apeleaza interceptorul de semnale, dar nucleul intrerupe procesul si comuta contextul inaintea executarii apelului sistem signal.

3. Procesul fiu se executa din nou si trimite un alt semnal de intrerupere catre procesul parinte.

4. Procesul parinte receptioneaza al doilea semnal de intrerupere, dar acesta nu a facut setarile pentru a intercepta semnalul. Cand acesta reia executia, se termina.

Programul a fost scris pentru a permite o astfel de comportare, deoarece invocarea apelului sistem nice de catre procesul parinte determina nucleul sa planifice procesul fiu mai des. Totusi este nedeterminat cand va aparea acest efect.

Dupa cum afirma Ritchie, semnalele au fost proiectate ca evenimente care sunt fatale sau se pot ignora, nu in mod necesar ca evenimente care trebuiesc tratate si din acest motiv conditiile de concurenta nu au fost fixate in versiunile anterioare. Cu toate acestea, ele pun serioase probleme programelor care doresc sa intercepteze semnale. Problema ar putea fi rezolvata daca campul semnal nu ar fi sters la receptionarea semnalului. Dar o astfel de solutie ar putea da nastere unei noi probleme: daca semnalele sosesc continuu si sunt preluate, stiva utilizator ar putea creste peste limita admisa datorita numarului mare de apeluri. Ca alternativa, nucleul ar putea reseta valoarea functiei de tratare a semnalului astfel incat acestea sa ignore semnalele de tipul respectiv pana cand utilizatorul precizeaza din nou ce va face cu acestea. O astfel de solutie implica o pierdere de informatie, deoarece procesul nu are cum sa stie cate semnale receptioneaza. Totusi, pierderea de informatie nu este mai severa decat ar fi in cazul in care procesul receptioneaza mai multe semnale de un anumit tip inainte sa le poata trata. In sfarsit, sistemul BSD permite unui proces sa blocheze si sa deblocheze receptionarea unor semnale printr-un apel sistem nou; cand un proces deblocheaza semnalele, nucleul trimite semnalele netratate care au fost blocate catre proces. Cand un proces receptioneaza un semnal, nucleul blocheaza in mod automat receptionarea altor semnale pana la tratarea completa a acestuia. Aceasta metoda este similara modului in care nucleul reactioneaza la intreruperile hardware: acesta blocheaza transmiterea de noi intreruperi in timp ce sunt tratate cele anterioare.

O a doua anomalie in tratarea semnalelor se refera la interceptarea semnalelor care apar in timp ce procesul se afla intr-un apel sistem, asteptand la un nivel de prioritate intreruptibila. Semnalul determina procesul sa execute un apel longjmp din starea de asteptare, sa revina in modul utilizator si sa apeleze functia de tratare a semnalului. Cand aceasta functie se termina, procesul apare ca si cum ar reveni din apelul sistem cu o eroare care indica faptul ca acesta a fost intrerupt.

Utilizatorul poate verifica eroarea intoarsa si relua apelul sistem, dar uneori este mai convenabil daca nucleul face automat acest lucru, asa cum se face in sistemul BSD.

O a treia anomalie apare in cazul in care un proces ignora un semnal. Daca semnalul soseste in timp ce procesul se afla in asteptare pe un nivel de prioritate intreruptibila, procesul se va trezi dar nu va executa un apel longjmp. Aceasta inseamna ca nucleul isi da seama ca procesul ignora semnalul doar dupa ce il trezeste si il executa. O politica mai buna ar fi ca procesul sa fie lasat in asteptare. Cu toate acestea, nucleul memoreaza adresa functiei de tratare a semnalului in u area, si u area nu poate fi accesata atunci cand semnalul este trimis procesului. O solutie la aceasta problema ar fi inscrierea adresei functiei de tratare a semnalului in intrarea din tabela de procese, unde nucleul ar putea verifica daca procesul trebuie trezit la receptionarea unui semnal. Ca o alternativa, procesul ar putea imediat sa se intoarca in starea " asteptare" utilizand algoritmul sleep, daca isi da seama ca nu ar fi trebuit trezit. Cu toate acestea, procesele utilizator nu realizeaza daca procesul a fost trezit, deoarece nucleul mentine intrarea in algoritmul sleep intr-o bucla while (vezi Capitolul 2), punand procesul inapoi in asteptare daca evenimentul pentru care astepta nu a aparut intr-devar.

In sfarsit, nucleul nu trateaza semnalele 'terminare fiu' la fel ca pe celelalte semnale. In particular, cand procesul isi da seama ca a primit un semnal 'terminare fiu', pune pe zero campul semnal din intrarea in tabela de procese si in acest caz actioneaza ca si cum nici un semnal nu ar fi fost transmis. Efectul unui semnal 'terminare fiu' este trezirea unui proces care asteapta pe un nivel de prioritate intreruptibila. Daca procesul intercepteaza un semnal 'terminare fiu', el apeleaza functia de tratare utilizator ca si pentru alte semnale. Operatiile pe care le face nucleul daca procesul ignora semnalele 'terminare fiu', vor fi discutate in paragraful 4. In sfarsit, daca un proces invoca apelului sistem signal cu parametrul 'terminare fiu', nucleul trimite procesului apelant un semnal 'terminare fiu' daca acesta are procese in starea zombie. In paragraful 4. se vor prezenta conventiile pentru apelul signal cu parametrul 'terminare fiu'.

2.2. Grupe de procese

Desi procesele intr-un sistem UNIX sunt identificate printr-un numar unic (PID), sistemul trebuie sa identifice uneori procesele dupa 'grup'. De exemplu, procesele cu un stramos comun care este un shell de logare in sistem sunt in general inrudite si de aceea toate aceste procese primesc semnale cand un utilizator apasa tastele 'Delete' sau 'Break' sau cand linia catre terminal este intrerupta. Nucleul utilizeaza identificatorul grupului de procese pentru a identifica grupurile de procese inrudite care trebuie sa primesaca un semnal comun la aparitia anumitor evenimente. Acesta salveaza identificatorul grupului de procese in tabela de procese; procesele aflate in acelasi grup au acelasi identificator de grup.

Apelul sistem setpgrp initialiazeaza numarul de grup pentru un proces si-l seteaza ca fiind egal cu valoarea identificatorului de proces propriu. Sintaxa apelului sistem este:

grp=setpgrp();

unde grp este noul numar al grupului de procese. Un proces fiu retine numarul de grup de procese al procesului parinte in timpul apelului sistem fork. Setpgrp are, de asemenea, importanta in setarea terminalului de control al unui proces (vezi Paragraful 6.3.5.).

2.3. Trimiterea semnalelor de catre procese

Procesele trimit semnale folosind apelului sistem kill. Sintaxa pentru acest apel este:

kill (pid, signum)

unde pid identifica setul de procese care primesc semnalul si signum este numarul semnalului trimis. In lista care urmeaza se arata corespondenta dintre valorile parametrului pid si seturile de procese.

Daca pid este un intreg pozitiv, nucleul trimite un semnal procesului care are identificatorul de proces pid.

Daca pid este 0, nucleul trimite semnal tuturor proceselor din grupul procesului care a trimis semnalul.

Daca pid este -1, nucleul trimite semnalul tuturor proceselor al caror identificator al utilizatorului real este egal cu identificatorul utilizatorului efectiv al procesului care a trimis semnalul (Paragraful 6. va defini identificatorul utilizatorului real si efectiv). Daca procesul care trimite semnalul are identificatorul utilizator efectiv al superutilizatorului, nucleul trimite semnalul tuturor proceselor cu exceptia proceselor 0 si 1.

Daca pid este un intreg negativ diferit de -1, nucleul trimite semnalul tuturor proceselor din grupul de procese care au valoarea absoluta egala cu valoarea parametrului pid.

In toate cazurile, daca procesul care trimite semnalul nu are identificatorul utilizatorului efectiv egal cu al superutilizatorului, sau daca identificatorul sau utilizator efectiv sau real este diferit de identificatorul utilizator efectiv sau real al procesului care receptioneaza, kill esueaza.

ainclude <signal.h>

main()

}

kill(0,SIGINT);

}

Figura 13. Exemplu de utilizare a lui Setpgrp

In programul din figura 13, procesul schimba numarul sau de grup si creaza 10 procese fiu. La creare, fiecare proces fiu are acelasi numar de grup cu al procesului parinte, dar procesele create in timpul iteratiilor impare din ciclu isi modifica numarul de grup. Apelurile sistem getpid si getpgrp intorc identificatorul procesului si identificatorul grupului pentru procesul care se executa, iar apelului sistem pause suspenda executia procesului pana cand acesta receptioneaza un semnal. La sfarsit, procesul parinte executa apelul sistem kill si trimite un semnal de intrerupere tuturor proceselor din grupul sau. Nucleul trimite semnalul catre cele 5 procese 'pare' care nu si-au schimbat propriul numar de grup de procese,dar cele 5 procese 'impare' continua ciclul.

3. Terminarea proceselor

Intr-un sistem UNIX procesele se termina prin executia apelului sistem exit. Un proces care intra in starea zombie (vezi Figura 7.1), isi abandoneaza resursele si isi distruge contextul mai putin intrarea din tabela de procese. Sintaxa pentru apel este:

exit (status)

unde valoarea status este intoarsa procesului parinte pentru examinare.

Figura 14. Algoritmul pentru terminarea proceselor

Procesele pot apela exit explicit sau implicit la sfarsitul programului: rutina de initializare existenta in toate programele C apeleaza exit cand programul revine din functia main care este punctul de intrare al tuturor programelor. Ca o alternativa, nucleul poate apela exit intern pentru un proces la primirea unor semnale pe care nu doreste sa le intercepteze, dupa cum s-a discutat anterior. In acest caz, valoarea parametrului status este numarul semnalului.

Sistemul nu impune limite de timp pentru executia unui proces si astfel procesele pot exista pentru o perioada indelungata. De exemplu, procesele 0 si 1 exista de-a lungul intregii functionari a sistemului. Alte exemple sunt procesele getty, cate urmaresc o linie de terminal, asteptand logarea unui utilizator, si procesele administrative dedicate.

Figura 14. prezinta algoritmul exit. Nucleul mai intai dezactiveaza tratarea semnalelor de catre proces deoarece aceasta nu mai are nici un sens. Daca procesul care se termina este un lider de grup de procese asociat cu un terminal de control (vezi Paragraful 6.3.5), nucleul presupune ca utlizatorul nu mai face nimic util si trimite un semnal de intrerupere catre toate procesele aflate in grupul de procese. Astfel, daca un utilizator tasteaza 'sfarsit de fisier' (CTRL+D) in timp ce mai exista procese in executie asociate terminalului, procesul care se termina le va trimite un semnal de intrerupere. Nucleul initializeaza, de asemenea, numarul de grup cu 0 pentru procesele din grup, deoarece este posibil ca mai tarziu un alt proces sa obtina identificatorul procesului care tocmai s-a terminat si sa fie de asemenea lider de grup. Procesele care au apartinut vechiului grup nu vor apartine si noului grup. Nucleul parcurge descriptorii fisierelor deschise, inchizandu-le pe fiecare prin algoritmul intern close, si elibereraza inodurile care au fost folosite pentru directorul curent si radacina schimbata (daca exista) prin algoritmul iput.

Nucleul elibereaza apoi toata memoria utilizatorului prin eliberarea regiunilor corespunzatoare cu algoritmul detachreg si schimba starea procesului in zombie. El salveaza codul de stare al apelului exit si timpii de executie in modurile utilizator si nucleu acumulati de proces si descendentii lui in tabela de procese. Descrierea apelului wait in paragraful 4 arata cum un proces obtine datele de timp pentru procesele descendente. Nucleul mai scrie, de asemenea, o inregistrare cu informatii de contabilitate intr-un fisier global care contine diferite statistici cum ar fi identificatorul utilizatorului, utilizarea U.C.P. si a memoriei, precum si cantitatea de operatii de intrare/iesire. Programele de nivel utilizator pot citi mai tarziu fisierul de contabilitate pentru a obtine diferite date statistice utile pentru urmarirea performantelor si pentru taxarea clientului in functie de serviciile oferite.

La sfarsit, nucleul deconecteaza procesul de la arborele de procese facand ca procesul 1 (init) sa adopte toate procesele sale fiu. Aceasta presupune ca procesul 1 sa devina parintele legal al tuturor proceselor fiu in executie pe care procesul care se termina le-a creat. Daca vreunul din procesele fiu este in starea zombie, procesul care se termina trimite catre procesul init semnalul 'terminare fiu' pentru ca acesta sa-l stearga din tabela de procese (vezi Paragraful 9.); procesul care se termina trimite si parintelui sau un semnal 'terminare fiu'. Intr-un scenariu tipic, procesul parinte executa un apel sistem wait pentru a se putea sincroniza cu procesul fiu care se termina. Procesul aflat in starea zombie face o comutare de context astfel ca nucleul poate sa planifice un alt proces pentru executie; nucleul nu va planifica pentru executie un proces aflat in starea zombie.

In programul din figura 15 un proces creaza un fiu care isi tipareste propriul identificator si executa apelul sistem pause suspendandu-si executia pana cand primeste un semnal. Procesul parinte tipareste identificatorul procesului fiu si se termina intorcand identificatorul procesului fiu drept cod de stare. Daca apelul exit nu ar fi prezent, rutina de initializare ar apela exit la intoarcerea programului din functia main. Procesul fiu creat de parinte continua sa existe pana cand primeste un semnal, chiar daca procesul parinte s-a terminat.

Figura 15. Exemplu de utilizare a apelului sistem exit

4. Asteptarea (wait)

Un proces isi poate sincroniza executia cu terminarea unui proces fiu prin executia apelului sistem wait. Sintaxa pentru acest apel sistem este:

pid=wait (statIaddr);

unde pid este identificatorul de proces al fiului in starea zombie, iar statIaddr este adresa unui intreg din spatiul utilizator care va contine codul de terminare al procesului fiu.

Figura 16 prezinta algoritmul wait. Nucleul cauta un fiu al procesului in starea zombie si daca nu gaseste nici unul intoarce o eroare. Daca gaseste un fiu in starea zombie, extrage identificatorul procesului si parametrul furnizat de apelul sistem exit procesului fiu si intoarce aceste valori la terminarea apelului sistem. Un proces care se termina poate astfel specifica diferite coduri de retur pentru a preciza motivul terminarii sale, dar multe programe nu fac acest lucru in practica. Nucleul adauga timpul acumulat de executia procesului fiu in modurile utilizator si nucleu la campurile corespunzatoare din u area a procesului parinte si in final elibereaza intrarea din tabela de procese ocupata formal de procesul in starea zombie. Aceasta intrare devine disponibila pentru noi procese.

Daca procesul care executa apelulwait are procese fiu, dar niciunul dintre acestea nu se afla in starea zombie, el trece in asteptare la un nivel de prioritate intreruptibila pana la sosirea unui semnal. Nucleul nu contine un apel explicit de trezire a unui proces care asteapta in apelul wait: astfel de procese sunt trezite numai la primirea unor semnale. Pentru orice semnal, cu exceptia semnalului 'terminare fiu' procesul va reactiona dupa cum s-a descris anterior. Cu toate acestea, daca semnalul este 'terminare fiu', procesul ar putea raspunde in mod diferit.

In cazul implicit el va fi trezit din starea de asteptare in apelul wait si va invoca algoritmul issig pentru a verifica daca a receptionat semnale. Algoritmul issig (Figura 7) recunoaste cazul special al semnalului 'terminare fiu' si intoarce "fals". Ca urmare nucleul nu executa un apel longjmp din starea de asteptare ci se intoarce in apelul wait. Nucleul va relua bucla din apelul wait, gaseste un fiu in starea zombie -cel putin unul exista- elibereaza intrarea fiului din tabela de procese si iese din apelul sistem wait.

Daca procesul intercepteaza semnalul 'terminare fiu', nucleul apelezeaza rutina utilizator de tratare a semnalului, asa cum face pentru alte semnale.

Daca procesul ignora semnalele 'terminare fiu', nucleul reia bucla din apelul wait, elibereaza sloturile din tabela de procese corespunzatoare proceselor fiu aflate in starea zombie si cauta alti fii.

Figura 16. Algoritmul pentru wait

De exemplu, un utilizator obtine diferite rezultate cand apeleaza programul din figura 17 cu sau fara parametri. Sa consideram mai intai cazul in care utilizatorul apeleaza programul cu un parametru (argc este 1, numele programului). Procesul parinte creaza 15 procese fiu, care eventual se termina cu codul de retur i, valoarea variabilei din ciclu in momentul crearii procesului. Nucleul executa apelul sistem wait pentru procesul parinte, gaseste un proces fiu in starea zombie si intoarce identificatorul sau de proces si codul lui de terminare. Nu este determinat care din procesele fiu este gasit.

In biblioteca C, procedura pentru apelul sistem exit pastreaza codul de terminare in bitii 8 la 15 ai variabilei retIcode si intoarce identificatorul procesului fiu pentru apelul wait. Astfel variabila retIcode este egala cu 256*i, depinzand de valoarea lui i pentru procesul fiu si variabila retIval este egala cu valoarea identificatorului procesului fiu.Daca utilizatorul apeleaza programul de mai sus cu un parametru (argc>1), procesul parinte apeleaza signal pentru a ignora semnalele " terminare fiu". Sa presupunem ca procesul parinte asteapta in apelul wait inainte ca vreun proces sa se termine: cand un proces fiu se termina, el trimite un semnal "terminare fiu" catre procesul parinte: procesul parinte este trezit, pentru ca asteptarea sa in apelul wait este la un nivel de prioritate intreruptibila. Cand procesul parinte ruleaza, acesta gaseste ca semnalul a fost 'terminare fiu'; dar pentru ca el ignora aceste semnale, nucleul sterge intrarea procesului aflat in starea zombie din tabela de procese si continua executia apelului wait ca si cum nu ar fi existat nici un semnal.

Figura 1 Exemplu de asteptare si ignorare a semnalelor " terminare fiu"

Nucleul executa procedura anterioara de fiecare data cand procesul parinte receptioneaza un semnal 'terminare fiu' pana cand in final ajunge in bucla apelului wait si constata ca procesul parinte nu mai are fii. Apelul sistem wait intoarce atunci -1. Diferenta intre cele doua apelari ale programului este ca procesul parinte asteapta terminarea unui proces fiu in primul caz si a tuturor proceselor fiu in al doilea caz.

Versiunile mai vechi ale sistemului UNIX implementau apelurile exit si wait fara semnalul 'terminare fiu'. In loc sa trimita semnalul 'terminare fiu', apelul exit trezea procesul parinte. Daca procesul parinte era in asteptare in apelul sistem wait,acesta se putea trezi, gasea un proces fiu in starea zombie si apoi se termina. Daca acesta nu era in asteptare in apelul wait, trezirea nu ar fi avut nici un efect; ar fi gasit un fiu in starea zombie in urmatorul apel wait. In mod similar, procesul init ar fi asteptat in apelul wait si procesele care s-ar fi executat l-ar fi trezit pentru a adopta noi procese aflate in starea zombie.

Problema acestei implementari este imposibilitatea inlaturarii proceselor in starea zombie daca procesul parinte nu executa un apel wait. Daca un proces creaza mai multe procese fiu dar nu executa niciodata apelul wait, tabela de procese se va umple cu procesele fiu aflate in starea zombie dupa terminarea acestora. De exemplu, sa luam programul din figura 1 Procesul citeste din fisierul sau standard de intrare pana cand acesta intalneste sfarsitul de fisier, creand un proces fiu la fiecare citire.

Figura 1 Exemplu care prezinta motivul implementarii semnalului

'terminare fiu'

Cu toate acestea, procesul parinte nu asteapta terminarea vreunui proces fiu deoarece doreste terminarea cat mai rapida a proceselor fiu iar un proces fiu poate se poate termina dupa un timp indelungat.

Daca procesul parinte executa apelul signal pentru a ignora semnalele 'terminare fiu' , nucleul va elibera intrarile proceselor aflate in starea zombie in mod automat. Altfel, procesele aflate in starea zombie ar putea umple, eventual la maxim, locurile permise in tabela de procese.

5. Apelul altor programe

Apelul sistem exec apeleaza un alt program suprapunand peste spatiul de memorie al unui proces o copie a unui fisier executabil. Continutul contextului de nivel utilizator care a existat inaintea apelului exec nu mai este accesibil pentru mult timp cu exceptia parametrilor apelului exec pe care nucleul ii copiaza din vechiul spatiu de adresa in cel nou. Sintaxa apelului sistem este:

execve(numeIfisier, argv, envp)

unde numeIfisier este numele fisierului executabil apelat, argv este un sir de pointeri catre caractere care sunt parametrii programului executabil iar envp este un sir de pointeri catre caractere care reprezinta mediul programului executat. Exista mai multe functii de biblioteca care apeleaza exec cum ar fi execl, execv, execle, etc. Cand un program foloseste parametrii in linia de comanda, cum ar fi

main(argc,argv)

parametrul argv este o copie a parametrului argv pentru apelul exec.

copiaza parametrii apelului exec in noua regiune de stiva a

utilizatorului;

procesare speciala pentru programele de tip setuid, si pentru

execuTia pas cu pas;

elibereaza inodul fisierului (algoritmul iput);

}