This shows you the differences between two versions of the page.
sde:laboratoare:05_ro [2019/03/19 20:15] alexandru.radovici [Link-uri către secțiuni utile] |
— (current) | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Laborator 5 - Semnale ====== | ||
- | ===== Materiale ajutătoare ===== | ||
- | |||
- | * [[http://elf.cs.pub.ro/so/res/laboratoare/lab04-refcard.pdf| lab05-refcard.pdf]] | ||
- | |||
- | ===== Link-uri către secțiuni utile ===== | ||
- | * [[#Pipe-uri anonime în Linux|Pipe-uri anonime în Linux]] | ||
- | * [[#Pipe-uri cu nume în Linux|Pipe-uri cu nume în Linux]] | ||
- | * [[#Generarea semnalelor|Generarea semnalelor]] | ||
- | * [[#Transmiterea și primirea semnalelor| Transmiterea și primirea semnalelor]] | ||
- | * [[#Tipuri standard de semnale | Tipuri standard de semnale]] | ||
- | * [[#Mesaje pentru descrierea semnalelor | Mesaje pentru descrierea semnalelor]] | ||
- | * [[#Măști de semnale. Blocarea semnalelor | Măști de semnale. Blocarea semnalelor]] | ||
- | * [[#Tratarea semnalelor | Tratarea semnalelor]] | ||
- | * [[#Semnalarea proceselor | Semnalarea proceselor]] | ||
- | * [[#Așteptarea unui semnal | Așteptarea unui semnal]] | ||
- | * [[#Timere în Linux| Timere în Linux]] | ||
- | |||
- | ===== Pipe-uri in Linux ===== | ||
- | ==== Pipe-uri anonime în Linux ==== | ||
- | |||
- | Pipe-ul este un mecanism de comunicare unidirecțională între două procese. În majoritatea implementărilor de UNIX, un pipe apare ca o zonă de memorie de o anumită dimensiune în spațiul nucleului. Procesele care comunică printr-un pipe anonim trebuie să aibă un grad de rudenie; de obicei, un proces care creează un pipe va apela după aceea ''fork'', iar pipe-ul se va folosi pentru comunicarea între părinte și fiu. În orice caz, procesele care comunică prin pipe-uri anonime nu pot fi create de utilizatori diferiți ai sistemului. | ||
- | |||
- | |||
- | Apelul de sistem pentru creare este [[http://linux.die.net/man/2/pipe|pipe]]: | ||
- | |||
- | {{ so:laboratoare:pipe.png?370| Exemplu de utilizare - procesul părinte transmite date procesului copil prin pipe}} | ||
- | <code c> | ||
- | int pipe(int filedes[2]); | ||
- | </code> | ||
- | |||
- | Vectorul ''filedes'' conține după execuția funcției 2 descriptori de fișier: | ||
- | *''filedes[0]'', deschis pentru citire; | ||
- | *''filedes[1]'', deschis pentru scriere; | ||
- | |||
- | /* Se consideră că ieșirea lui ''filedes[1]'' este intrare pentru ''filedes[0]''. */ | ||
- | |||
- | //Mnemotehnică//: ''STDIN_FILENO'' este 0 (citire), ''STDOUT_FILENO'' este 1 (scriere). | ||
- | |||
- | **Observații**: | ||
- | *citirea/scrierea din/în pipe-uri este atomică dacă nu se citesc/scriu mai mult de ''PIPE_BUF''((limită globală setată implicit pe Linux la 4096 bytes)) octeți. | ||
- | *citirea/scrierea din/în pipe-uri se realizează cu ajutorul funcțiilor ''read''/''write''. | ||
- | |||
- | Majoritatea aplicațiilor care folosesc pipe-uri închid în fiecare dintre procese capătul de pipe **neutilizat** în comunicarea unidirecțională. Dacă unul dintre descriptori este închis se aplică regulile: | ||
- | *o citire dintr-un pipe pentru care descriptorul de **scriere** a fost închis, după ce toate datele au fost citite, va returna ''0'', ceea ce indică sfârșitul fișierului. Descriptorul de scriere poate fi duplicat astfel încât mai multe procese să poată scrie în pipe. De regulă, în cazul pipe-urilor anonime există doar două procese, unul care scrie și altul care citește, pe când în cazul fișierelor pipe cu nume (FIFO) pot exista mai multe procese care scriu date. | ||
- | *o scriere într-un pipe pentru care descriptorul de **citire** a fost închis cauzează generarea semnalului ''SIGPIPE''. Dacă semnalul este captat și se revine din rutina de tratare, funcția de sistem ''write'' returnează eroare și variabila ''errno'' are valoarea ''EPIPE''. | ||
- | |||
- | <note important> Cea mai frecventă **greșeală**, relativ la lucrul cu pipe-urile, provine din neglijarea faptului că nu se trimite ''EOF'' prin pipe (citirea din pipe nu se termină) decât dacă sunt închise **TOATE** capetele de scriere din **TOATE** procesele care au deschis descriptorul de scriere în pipe (în cazul unui ''fork'', nu uitați să închideți capetele pipe-ului în procesul părinte). </note> | ||
- | |||
- | Alte funcții utile: [[http://linux.die.net/man/3/popen|popen]], [[http://linux.die.net/man/3/pclose|pclose]]. | ||
- | |||
- | ==== Pipe-uri cu nume în Linux ==== | ||
- | |||
- | Elimină necesitatea ca procesele care comunică să fie înrudite. Astfel, fiecare proces își poate deschide pentru citire sau scriere fișierul pipe cu nume (FIFO), un tip de fișier special, care păstrează în spate caracteristicile unui pipe. Comunicația se face într-un sens sau în ambele sensuri. Fișierele de tip FIFO pot fi identificate prin litera ''p'' în primul câmp al drepturilor de acces (''ls -l''). | ||
- | |||
- | Apelul de bibliotecă pentru crearea pipe-urilor de tip FIFO este [[http://linux.die.net/man/3/mkfifo|mkfifo]]: | ||
- | |||
- | <code c> | ||
- | int mkfifo(const char *pathname, mode_t mode); | ||
- | </code> | ||
- | |||
- | După ce pipe-ul FIFO a fost creat, acestuia i se pot aplica toate funcțiile pentru operații obișnuite pentru lucrul cu fișiere: ''open'', ''close'', ''read'', ''write''. | ||
- | |||
- | Modul de comportare al unui pipe FIFO după deschidere este afectat de flagul ''O_NONBLOCK'': | ||
- | <spoiler Detalii despre flagul O_NONBLOCK> | ||
- | *dacă ''O_NONBLOCK'' nu este specificat (cazul normal), atunci un ''open'' pentru citire se va bloca până când un alt proces deschide același FIFO pentru scriere. Analog, dacă deschiderea este pentru scriere, se poate produce blocare până când un alt proces efectuează deschiderea pentru citire. | ||
- | *dacă se specifică ''O_NONBLOCK'', atunci deschiderea pentru citire revine imediat, dar o deschidere pentru scriere poate returna eroare cu ''errno'' având valoarea ''ENXIO'', dacă nu există un alt proces care a deschis același FIFO pentru citire. | ||
- | </spoiler> | ||
- | |||
- | |||
- | Atunci când se închide ultimul descriptor de fișier al capătului de scriere pentru un FIFO, se generează un „sfârșit de fișier” – ''EOF'' – pentru procesul care citește din FIFO. | ||
- | |||
- | |||
- | ===== Semnale în Linux===== | ||
- | În lumea reală, un proces poate cunoaște o multitudine de situații neprevăzute, care-i afectează cursul normal de execuție. Dacă procesul nu le poate trata, ele sunt pasate, mai departe, sistemului de operare. Cum sistemul de operare nu poate ști dacă procesul își poate continua execuția în mod normal, fără efecte secundare nedorite, este obligat să termine procesul în mod forțat. O rezolvare a acestei probleme o reprezintă semnalele. | ||
- | <note> Un semnal este o întrerupere software, în fluxul normal de execuție a unui proces. </note> | ||
- | Semnalele sunt un concept specific sistemelor de operare UNIX. Sistemul de operare le folosește pentru a semnala procesului apariția unor situații excepționale oferindu-i procesului posibilitatea de a reacționa. Fiecare semnal este asociat cu o clasă de evenimente care pot apărea și care respectă anumite criterii. | ||
- | Procesele pot trata, bloca, ignora sau lăsa sistemul de operare să efectueze acțiunea implicită la primirea unui semnal: | ||
- | * De obicei acțiunea implicită este ''terminarea'' procesului. | ||
- | |||
- | * Dacă un proces dorește să ''ignore'' un semnal, sistemul de operare nu va mai trimite acel semnal procesului. | ||
- | |||
- | * Dacă un proces specifică faptul că dorește să ''blocheze'' un semnal, sistemul de operare nu va mai trimite semnalele de acel tip spre procesul în cauză, dar va salva numai primul semnal de acel tip, restul pierzându-se. Când procesul hotărăște că vrea să primească, din nou, semnale de acel tip, dacă există vreun semnal în așteptare, acesta va fi trimis. | ||
- | Mulțimea tipurilor de semnale este finită; sistemul de operare ține, pentru fiecare proces, o ''tabelă cu acțiunile'' alese de acesta, pentru fiecare tip de semnal. La fiecare moment de timp aceste acțiuni sunt bine determinate. La pornirea procesului tabela de acțiuni este inițializată cu valorile implicite. Modul de tratare a semnalului nu este decis la primirea semnalului de către proces, ci se alege, în mod automat, din tabelă. | ||
- | Semnalele sunt sincrone/asincrone cu fluxul de execuție al procesului care primește semnalul dacă evenimentul care cauzează trimiterea semnalului este sincron/asincron cu fluxul de execuție al procesului. | ||
- | * Un eveniment este sincron cu fluxul de execuție al procesului dacă apare de fiecare dată la rularea programului, în același punct al fluxului de execuție. Exemple în acest sens sunt încercarea de accesare a unei locații de memorie nevalide sau nepermise, împărțire la zero etc. | ||
- | |||
- | * Un eveniment este ''asincron'' dacă nu este sincron. Exemple de evenimente asincrone: un semnal trimis de un alt proces (semnalul de terminare unui proces copil), sau o cerere de terminare externă (utilizatorul dorește să reseteze calculatorul). | ||
- | |||
- | Un semnal primit de un proces poate fi generat: | ||
- | |||
- | * fie direct de ''sistemul de operare'' - în cazul în care acesta raportează diferite erori; | ||
- | |||
- | * fie de un ''proces'' - care-și poate trimite și singur semnale (semnalul va trece tot prin sistemul de operare). | ||
- | |||
- | <note important> Dacă două semnale sunt prea apropiate în timp ele se pot confunda într-unul singur. Astfel, în mod normal, nu există niciun mecanism care să garanteze celui care trimite semnalul că acesta a ajuns la destinație. </note> | ||
- | |||
- | În anumite cazuri, există nevoia de a ști, în mod sigur, că un semnal trimis a ajuns la destinație și, implicit, că procesul va răspunde la el (efectuând una din acțiunile posibile). Sistemul de operare oferă un alt mod de a trimite un semnal, prin care se ''garantează'' fie că semnalul a ajuns la destinație, fie că această acțiune a eșuat. Acest lucru este realizat prin crearea unei stive de semnale, de o anumită capacitate (ea trebuie să fie finită, pentru a nu produce situații de overflow). La trimiterea unui semnal, sistemul de operare verifică dacă stiva este plină. În acest caz, cererea eșuează, altfel semnalul este pus în stivă și operația se termină cu succes. Modul clasic de a trimite semnale este analog cu acesta (stiva are dimensiunea 1) cu excepția faptului că nu se oferă informații despre ajungerea la destinație a unui semnal. | ||
- | |||
- | Noțiunea de semnal este folosită pentru a indica alternativ fie un anumit tip de semnal, fie efectiv obiectele de acest tip. | ||
- | |||
- | ===== Generarea semnalelor===== | ||
- | În general, evenimentele care generează semnale se încadrează în trei categorii majore: | ||
- | |||
- | * O ''eroare'' indică faptul că un program a făcut o operație nepermisă și nu-și poate continua execuția. Însă, nu toate tipurile de erori generează semnale (de fapt, cele mai multe nu o fac). De exemplu, deschiderea unui fișier inexistent este o eroare, dar nu generează un semnal; în schimb, apelul de sistem open returnează -1, indicând că apelul s-a terminat cu eroare. În general, erorile asociate cu anumite biblioteci sunt raportate prin întoarcerea unei valori speciale. Erorile care generează semnale sunt cele care pot apărea oriunde în program, nu doar în apelurile din biblioteci. Ele includ împărțirea cu zero și accesarea nevalidă a memoriei. | ||
- | |||
- | * Un ''eveniment extern'' este, în general, legat de I/O și de alte procese. Exemple: apariția de noi date de intrare, expirarea unui timer, terminarea execuției unui proces copil. | ||
- | |||
- | * O ''cerere explicită'' indică utilizarea unui apel de sistem, cum ar fi kill, pentru a genera un semnal. | ||
- | |||
- | Semnalele pot fi generate sincron sau asincron: | ||
- | |||
- | * Un semnal ''sincron'' se raportează la o acțiune specifică din program, și este trimis (dacă nu este blocat) în timpul acelei acțiuni. Cele mai multe erori generează semnale în mod sincron. De asemenea, semnalele pot fi generate în mod sincron și prin anumite cereri explicite trimise de un proces lui însuși. Pe anumite mașini, anumite tipuri de erori hardware (de obicei, excepțiile în virgulă mobilă) nu sunt raportate complet sincron, și pot ajunge câteva instrucțiuni mai târziu. | ||
- | |||
- | * Semnalele ''asincrone'' sunt generate de evenimente necontrolabile de către procesul care le primește. Aceste semnale ajung la momente de timp impredictibile. Evenimentele externe generează semnale în mod asincron, la fel ca și cererile explicite trimise de alte procese. | ||
- | |||
- | Un tip de semnal dat este fie sincron, fie asincron. De exemplu, semnalele pentru erori sunt, în general, sincrone deoarece erorile generează semnale în mod sincron. Însă, orice tip de semnal poate fi generat sincron sau asincron cu o cerere explicită. | ||
- | |||
- | ===== Transmiterea și primirea semnalelor===== | ||
- | Când un semnal este generat, el intră într-o stare de așteptare (pending). În mod normal, el rămâne în această stare pentru o perioadă de timp foarte mică și apoi este trimis procesului destinație. Însă, dacă acel tip de semnal este, în momentul de față, blocat, el ar putea rămâne în starea de așteptare nedefinit, până când semnalele de acel tip sunt deblocate. O dată deblocat acel tip de semnal, el va fi trimis imediat. | ||
- | Când semnalul a fost primit, fie imediat, fie cu întârziere, acțiunea specificată pentru acel semnal este executată. Pentru anumite semnale, cum ar fi ''SIGKILL'' și ''SIGSTOP'', acțiunea este **fixată** (procesul este terminat), dar, pentru majoritatea semnalelor, programul poate alege să: | ||
- | * **ignore** semnalul | ||
- | * specifice o funcție de tip **handler** | ||
- | * accepte **acțiunea implicită** pentru acel tip de semnal. | ||
- | Programul își specifică alegerea utilizând funcții precum [[https://linux.die.net/man/2/signal|signal]] sau [[https://linux.die.net/man/2/sigaction|sigaction]]. În timp ce handler-ul rulează, acel tip de semnal este în mod normal **blocat** (deblocarea se va face printr-o cerere explicită în handler-ul care tratează semnalul). | ||
- | <spoiler Exemplu de folosire ''signal''> | ||
- | În codul de mai jos ne propunem să capturăm semnalele ''SIGINT'' și ''SIGUSR1'' și să facem o acțiune în cazul în care le recepționăm. ''SIGINT'' e recepționat atât folosind comanda ''kill -SIGINT <program>'', cât și prin trimiterea combinației de taste ''CTRL+c'' programului. | ||
- | <code c> | ||
- | #include <stdio.h> | ||
- | #include <stdlib.h> | ||
- | #include <signal.h> | ||
- | #include <unistd.h> | ||
- | |||
- | pid_t child1, child2; | ||
- | int child1_pid; | ||
- | |||
- | |||
- | void signal_handler(int signum) | ||
- | { | ||
- | |||
- | switch(signum) { | ||
- | case SIGINT: | ||
- | printf("CTRL+C received in %d Exiting\n", getpid()); | ||
- | exit(EXIT_SUCCESS); | ||
- | case SIGUSR1: | ||
- | printf("SIGUSR1 received. Continuing execution\n"); | ||
- | } | ||
- | } | ||
- | |||
- | int main(void) | ||
- | { | ||
- | |||
- | printf("Process %d started\n", getpid()); | ||
- | |||
- | /* Semnale ca SIGKILL sau SIGSTOP nu pot fi prinse */ | ||
- | if (signal(SIGKILL, signal_handler) == SIG_ERR) | ||
- | printf("\nYou shall not catch SIGKILL\n"); | ||
- | |||
- | if(signal(SIGINT, signal_handler) == SIG_ERR) { | ||
- | printf("Unable to catch SIGINT"); | ||
- | exit(EXIT_FAILURE); | ||
- | } | ||
- | |||
- | if(signal(SIGUSR1, signal_handler) == SIG_ERR) { | ||
- | printf("Unable to catch SIGUSR1"); | ||
- | exit(EXIT_FAILURE); | ||
- | } | ||
- | |||
- | |||
- | printf("Press CTRL+C to stop us\n"); | ||
- | |||
- | while(1) { | ||
- | sleep(1); | ||
- | } | ||
- | |||
- | return 0; | ||
- | } | ||
- | </code> | ||
- | <note tip> Observați că semnalul ''SIGKILL'' nu poate fi handle-uit (''kill -9 <program>'' sau ''kill -SIGKILL <program>''). | ||
- | </note> | ||
- | </spoiler> | ||
- | Dacă acțiunea specificată pentru un tip de semnal este să îl **ignore**, atunci orice semnal de acest tip, care este generat pentru procesul în cauză, este ignorat. Același lucru se întâmplă dacă semnalul este blocat în acel moment. Un semnal neglijat în acest mod nu va fi primit niciodată, nici dacă programul specifică ulterior o acțiune diferită pentru acel tip de semnal și apoi îl deblochează. | ||
- | Dacă este primit un semnal pentru care nu s-a specificat niciun tip de acțiune, se execută **acțiunea implicită**. Fiecare tip de semnal are propria lui acțiune implicită. Pentru majoritatea semnalelor acțiunea implicită este **terminarea** procesului. Pentru anumite tipuri de semnale, care reprezintă evenimente fără consecințe majore, acțiunea implicită este să nu se facă nimic. | ||
- | |||
- | Când un semnal forțează terminarea unui proces, părintele procesului poate determina cauza terminării examinând codul de terminare raportat de funcțiile ''wait'' și ''waitpid''. Informațiile pe care le poate obține includ faptul că terminarea procesului a fost cauzată de un semnal, precum și tipul semnalului. Dacă un program pe care îl rulați din linia de comandă este terminat de un semnal, shell-ul afișează, de obicei, niște mesaje de eroare. | ||
- | Semnalele care în mod normal reprezintă erori de program au o proprietate specială: când unul din aceste semnale termină procesul, el scrie și un fișier **core dump** care înregistrează starea procesului în momentul terminării. Puteți examina fișierul cu un debugger, pentru a afla ce anume a cauzat eroarea. | ||
- | Dacă generați un semnal, care reprezintă o eroare de program, printr-o cerere explicită, și acesta termină procesul, fișierul este generat ca și cum semnalul ar fi fost generat de o eroare. | ||
- | <note important>În cazul în care un semnal este trimis procesului, în timp ce acesta execută un apel de sistem **blocant**, procesul va suspenda apelul, va executa handler-ul de tratare a semnalului definit folosind ''signal'' și apoi fie operația va eșua (cu ''errno'' setat pe ''EINTR''), fie se va reporni operația. Sistemele System V se comportă ca în primul caz, cele BSD ca în cel de-al doilea. De la glibc v2 încoace, comportamentul este același ca și pe BSD, totul depinzând de definiția macrou-ului _BSD_SOURCE. Comportamentul poate fi controlat de către programator folosind ''sigaction'' cu flag-ul ''SA_RESTART''. </note> | ||
- | ===== Tipuri standard de semnale===== | ||
- | Această secțiune prezintă numele pentru diferite tipuri standard de semnale și descrie ce fel de evenimente indică. | ||
- | <note> Fiecare nume de semnal este o **macrodefiniție** care reprezintă, de fapt, un număr întreg pozitiv (numărul pentru acel tip de semnal). </note> | ||
- | Un program nu ar trebui să facă niciodată presupuneri despre codul numeric al unui tip particular de semnal, ci, mai degrabă, să le refere, întotdeauna, prin nume. Acest lucru este din cauza faptului că un număr pentru un tip de semnal poate **varia** de la un sistem la altul, dar numele lor sunt standard. Pentru lista completă de semnale suportate de un sistem se poate rula în linia de comandă: | ||
- | <code bash> | ||
- | $ kill -l | ||
- | |||
- | 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL | ||
- | 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE | ||
- | 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 | ||
- | 13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD | ||
- | 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN | ||
- | 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ | ||
- | 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO | ||
- | 30) SIGPWR 31) SIGSYS 33) SIGRTMIN 34) SIGRTMIN+1 | ||
- | 35) SIGRTMIN+2 36) SIGRTMIN+3 37) SIGRTMIN+4 38) SIGRTMIN+5 | ||
- | 39) SIGRTMIN+6 40) SIGRTMIN+7 41) SIGRTMIN+8 42) SIGRTMIN+9 | ||
- | 43) SIGRTMIN+10 44) SIGRTMIN+11 45) SIGRTMIN+12 46) SIGRTMIN+13 | ||
- | 47) SIGRTMIN+14 48) SIGRTMIN+15 49) SIGRTMAX-15 50) SIGRTMAX-14 | ||
- | 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 | ||
- | 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 | ||
- | 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 | ||
- | 63) SIGRTMAX-1 64) SIGRTMAX | ||
- | </code> | ||
- | Numele de semnale sunt definite în header-ul ''signal.h''. În general, semnalele au roluri predefinite, dar acestea pot fi suprascrise de programator. | ||
- | Cele mai cunoscute sunt următoarele semnale: | ||
- | * ''SIGINT'' - transmis la apăsarea combinației ''CTRL+C''; | ||
- | * ''SIGQUIT ''- transmis la apăsarea combinației de taste ''CTRL+\''; | ||
- | * ''SIGSEGV'' - transmis în momentul accesării unei locații nevalide de memorie, etc; | ||
- | * ''SIGKILL'' - **nu** poate fi ignorat sau suprascris. Transmiterea acestui semnal are ca efect terminarea procesului, indiferent de context. | ||
- | ===== Mesaje pentru descrierea semnalelor===== | ||
- | Cel mai bun mod de a afișa un mesaj de descriere a unui semnal este utilizarea funcțiilor [[http://man7.org/linux/man-pages/man3/strsignal.3.html|strsignal]] și [[http://man7.org/linux/man-pages/man3/psignal.3.html|psignal]]. Aceste funcții folosesc un număr de semnal pentru a specifica tipul de semnal care trebuie descris. Mai jos este prezentat un exemplu de folosire a acestor funcții: | ||
- | <code c msg_signal.c> | ||
- | #include <stdio.h> | ||
- | #include <stdlib.h> | ||
- | |||
- | #define __USE_GNU | ||
- | #include <string.h> | ||
- | |||
- | #include <signal.h> | ||
- | |||
- | int main(void) { | ||
- | char *sig_p = strsignal(SIGKILL); | ||
- | |||
- | printf("signal %d is %s\n", SIGKILL, sig_p); | ||
- | |||
- | psignal(SIGKILL, "death and decay"); | ||
- | |||
- | return 0; | ||
- | } | ||
- | </code> | ||
- | Pentru compilare și rulare secvența este: | ||
- | <code bash> | ||
- | so@spook$ gcc -Wall -g -o msg_signal msg_signal.c | ||
- | so@spook$ ./msg_signal | ||
- | signal 9 is Killed | ||
- | death and decay: Killed | ||
- | |||
- | </code> | ||
- | ===== Măști de semnale. Blocarea semnalelor===== | ||
- | Pentru a putea efectua operații de blocare/deblocare semnale avem nevoie să știm, la fiecare pas din fluxul de execuție, starea fiecărui semnal. Sistemul de operare are, de asemenea, nevoie de același lucru pentru a putea lua o decizie asupra unui semnal care trebuie trimis unui proces (el are nevoie de acest gen de informație pentru fiecare proces în parte). În acest scop se folosește o mască de semnale proprie fiecărui proces. | ||
- | <note> O **mască de semnale** are fiecare bit asociat unui tip de semnal. </note> | ||
- | Masca de biți este folosită de mai multe funcții, printre care și funcția [[http://man7.org/linux/man-pages/man2/sigprocmask.2.html|sigprocmask]], folosită pentru schimbarea măștii de semnale a procesului curent. | ||
- | <code c> | ||
- | int sigprocmask(int how, const sigset_t *set, sigset_t *oldset); | ||
- | |||
- | </code> | ||
- | Tipul de date folosit de sistemele UNIX pentru a reprezenta măștile de semnale este ''sigset_t''. Variabilele de acest tip sunt //''neinițializate''//. Operațiile pe acest tip de date sunt: | ||
- | * de inițializare cu biți de 0; | ||
- | * de inițializare cu biți de 1; | ||
- | * de blocare a unui semnal; | ||
- | * de deblocare a unui semnal; | ||
- | * de detectare a blocării unui semnal. | ||
- | Funcțiile următoare sunt folosite pentru a manipula masca de biți. Ele nu decid acțiunea de blocare sau deblocare a unui semnal, ci doar setează semnalul respectiv în masca de biți (pentru adăugare se pune bitul corespunzător semnalului pe 1, iar pentru ștergere pe 0), pentru ca apoi să se folosească ''sigprocmask'' pentru a seta acțiunea de blocare/deblocare efectivă. Mai multe detalii despre aceste funcții găsiți [[https://linux.die.net/man/3/sigemptyset|aici]]. | ||
- | <code c> int sigemptyset(sigset_t *set); | ||
- | int sigfillset(sigset_t *set); | ||
- | int sigaddset(sigset_t *set, int signo); | ||
- | int sigdelset(sigset_t *set, int signo); | ||
- | int sigismember(sigset_t *set, int signo); | ||
- | </code> | ||
- | <note warning>Înainte de a folosi funcțiile ''sigaddset'', ''sigdelset'' și ''sigismember'' asupra unui ''sigset_t'', acest tip trebuie inițializat folosind si''gemptyset'' sau ''sigfillset''. Comportamentul este nedefinit în caz contrar. </note> | ||
- | ecvența de mai jos constituie un caz de utilizare a funcțiilor de lucru cu masca de semnale, în care, la fiecare 5 secunde, se blochează/deblochează semnalul ''SIGINT'': | ||
- | <code c> | ||
- | sigset_t set; | ||
- | |||
- | sigemptyset(&set); | ||
- | sigaddset(&set, SIGINT); | ||
- | |||
- | while (1) { | ||
- | sleep(5); | ||
- | sigprocmask(SIG_BLOCK, &set, NULL); | ||
- | sleep(5); | ||
- | sigprocmask(SIG_UNBLOCK, &set, NULL); | ||
- | } | ||
- | </code> | ||
- | O altă valoare pe care o poate lua primul parametru al funcției [[http://man7.org/linux/man-pages/man2/sigprocmask.2.html|sigprocmask]] este ''SIG_SETMASK'', care specifică pur și simplu că vechea mască (al treilea parametru) e înlocuită cu cel de-al doilea parametru (noua mască). Un exemplu de folosire a acesteia puteți găsi la [[https://support.sas.com/documentation/onlinedoc/sasc/doc750/html/lr1/zlocking.htm|această adresă]]. | ||
- | ===== Tratarea semnalelor ===== | ||
- | Tratarea semnalelor se realizează prin asocierea unei funcții (**handler**) unui semnal. Funcția va fi apelată în momentul în care procesul recepționează semnalul respectiv. | ||
- | În mod tradițional, funcția folosită pentru asocierea de handler-e pentru tratarea unui semnal era[[http://man7.org/linux/man-pages/man2/signal.2.html|signal]]. Pentru a preîntâmpina deficiențele acestei funcții, standardul POSIX a definit funcția [[https://linux.die.net/man/2/sigaction|sigaction]] pentru asocierea unui handler cu un semnal. ''sigaction'' oferă mai mult control, cu prețul unui grad de complexitate mai mare. | ||
- | <code c> int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact); | ||
- | </code> | ||
- | Componenta importantă a funcției ''sigaction'' este structura cu același nume, descrisă în pagina de manual a funcției: | ||
- | <code c> | ||
- | struct sigaction { | ||
- | void (*sa_handler)(int); | ||
- | void (*sa_sigaction)(int, siginfo_t *, void *); | ||
- | sigset_t sa_mask; | ||
- | int sa_flags; | ||
- | }; | ||
- | </code> | ||
- | Dacă în câmpul ''sa_flags'' se precizează flag-ul ''SA_SIGINFO'', handler-ul folosit este cel specificat de ''sa_sigaction''. Altfel, handler-ul folosit este ''sa_handler''. Masca de semnale care ar trebui blocate în timpul execuției handler-ului este reprezentată de ''sa_mask''. | ||
- | |||
- | Un exemplu de asociere a unui handler de tratare a unui semnal este prezentat mai jos: | ||
- | <code c> | ||
- | #include <signal.h> | ||
- | ... | ||
- | |||
- | /* SIGUSR2 handler */ | ||
- | static void usr2_handler(int signum) { | ||
- | /* actions that should be taken when the signal signum is received */ | ||
- | ... | ||
- | } | ||
- | |||
- | int main(void) { | ||
- | struct sigaction sa; | ||
- | |||
- | memset(&sa, 0, sizeof(sa)); | ||
- | |||
- | sa.sa_flags = SA_RESETHAND; /* restore handler to previous state */ | ||
- | sa.sa_handler = usr2_handler; | ||
- | sigaction(SIGUSR2, &sa, NULL); | ||
- | |||
- | return 0; | ||
- | } | ||
- | </code> | ||
- | <note warning> Se poate opta pentru configurarea unui handler propriu sau se poate folosi unul predefinit. Se poate folosi ''SIG_IGN'' pentru ignorarea semnalului sau ''SIG_DFL'' pentru rularea acțiunii implicite (terminarea procesului, ignorarea semnalului etc). </note> | ||
- | <spoiler Detalii despre structura ''siginfo_t''> | ||
- | Dacă flag-ul ''SA_SIGINFO'' este setat, se folosește câmpul ''sa_sigaction'' al structurii ''sigaction'' pentru a specifica handler-ul asociat semnalului. Handler-ul folosit primește în acest caz trei parametri și poate fi folosit pentru a transmite o informație utilă, o dată cu procesul. Al treilea argument (de tipul ''void*'') este rar utilizat. Al doilea argument, de tipul siginfo_t definește o structură ce conține informații utile despre contextul apariției semnalului și alte informații pe care le poate furniza programatorul. Definiția structurii se găsește în pagina de manual a funcției [[http://man7.org/linux/man-pages/man2/sigaction.2.html|sigaction]]. | ||
- | <code c> | ||
- | siginfo_t { | ||
- | int si_signo; /* Signal number */ | ||
- | int si_errno; /* An errno value */ | ||
- | int si_code; /* Signal code */ | ||
- | int si_trapno; /* Trap number that caused | ||
- | hardware-generated signal | ||
- | (unused on most architectures) */ | ||
- | pid_t si_pid; /* Sending process ID */ | ||
- | uid_t si_uid; /* Real user ID of sending process */ | ||
- | int si_status; /* Exit value or signal */ | ||
- | clock_t si_utime; /* User time consumed */ | ||
- | clock_t si_stime; /* System time consumed */ | ||
- | sigval_t si_value; /* Signal value */ | ||
- | int si_int; /* POSIX.1b signal */ | ||
- | void *si_ptr; /* POSIX.1b signal */ | ||
- | int si_overrun; /* Timer overrun count; POSIX.1b timers */ | ||
- | int si_timerid; /* Timer ID; POSIX.1b timers */ | ||
- | void *si_addr; /* Memory location which caused fault */ | ||
- | long si_band; /* Band event (was int in | ||
- | glibc 2.3.2 and earlier) */ | ||
- | int si_fd; /* File descriptor */ | ||
- | short si_addr_lsb; /* Least significant bit of address | ||
- | (since kernel 2.6.32) */ | ||
- | } | ||
- | </code> | ||
- | Membrii structurii sunt inițializați numai atunci când valorile lor sunt utile. Membrii ''si_signo'', ''si_errno'' și ''si_code'' sunt întotdeauna definiți pentru toate semnalele. Restul structurii poate fi o uniune, așa că ar trebui citite numai câmpurile care au sens pentru semnalul primit. Spre exemplu, apelul de sistem ''kill'', semnalele POSIX.1b și ''SIGCHLD'' completează ''si_pid'' și ''si_uid'', iar ''SIGILL, SIGFPE, SIGSEGV'' și ''SIGBUS'' completează ''si_addr'' cu adresa care a provocat eroarea. | ||
- | </spoiler> | ||
- | ===== Semnalarea proceselor===== | ||
- | Pentru transmiterea unui semnal, se poate folosi funcția [[http://man7.org/linux/man-pages/man2/kill.2.html|kill]] sau funcția [[http://man7.org/linux/man-pages/man2/sigqueue.2.html|sigqueue]]. Funcția [[http://man7.org/linux/man-pages/man2/kill.2.html|kill]] are dezavantajul că nu garantează recepționarea semnalului de procesul destinație. Dacă este nevoie să se trimită un semnal unui proces și să se știe sigur că a ajuns se recomandă folosirea funcției [[http://man7.org/linux/man-pages/man2/sigqueue.2.html|sigqueue]]: | ||
- | <code c>int sigqueue(pid_t pid, int signo, const union sigval value); | ||
- | </code> | ||
- | Funcția trimite semnalul ''signo'', cu parametrii specificați de ''value'', procesului cu identificatorul ''pid''. Dacă semnalul este zero, se fac verificări pentru cazurile de eroare posibile, dar nu se trimite niciun semnal. Semnalul nul poate fi folosit pentru a verifica faptul că pid-ul este valid. | ||
- | Valoarea ce poate fi trimisă odată cu semnalul este un union: | ||
- | <code c> | ||
- | union sigval { | ||
- | int sival_int; | ||
- | void *sival_ptr; | ||
- | }; | ||
- | </code> | ||
- | Un parametru trimis astfel apare în câmpul ''si_value'' al structurii ''siginfo_t'', primite de handler-ul de semnal. În mod evident, **nu** are sens transmiterea de pointeri dintr-un proces în altul. | ||
- | |||
- | Condițiile cerute pentru ca un proces să aibă permisiunea de a trimite un semnal altui proces sunt aceleași ca și în cazul lui ''kill''. Dacă semnalul specificat este blocat în acel moment, funcția va ieși imediat și dacă flagul ''SA_SIGINFO'' este setat și există resurse necesare, semnalul va fi pus în coadă în starea pending (un proces poate avea în coadă maxim ''SIGQUEUE_MAX'' semnale). De asemenea, când semnalul este primit, câmpul ''si_code'', pasat structurii ''siginfo'', va fi setat la ''SI_QUEUE'', și ''si_value'' va fi setat la ''value''. | ||
- | |||
- | Dacă flagul ''SA_SIGINFO'' nu este setat, atunci ''signo'', dar nu în mod necesar și ''value'', vor fi trimise, cel puțin o dată, procesului care trebuie să primească semnalul. | ||
- | ===== Așteptarea unui semnal===== | ||
- | <spoiler Abordări pentru așteptarea unui semnal > | ||
- | În cazul în care se utilizează semnalele pentru comunicare și/sau sincronizare, există, deseori, nevoie să se aștepte ca un anumit tip de semnal să-i sosească procesului în cauză. Un mod simplu de a realiza acest lucru este o buclă, a cărei condiție de ieșire ar fi setarea corespunzătoare a unei variabile (variabila trebuie să fie de tipul ''sig_atomic_t''). De exemplu: | ||
- | <code c>while (!signal_has_arrived); | ||
- | </code> | ||
- | Principalul dezavantaj al abordării de mai sus (de tip //''busy-waiting''//) este timpul de procesor pe care procesul considerat îl pierde în mod inutil. O variantă ar fi folosirea funcției [[http://man7.org/linux/man-pages/man3/sleep.3.html|sleep]]: | ||
- | <code c> | ||
- | while (!signal_has_arrived) { | ||
- | sleep(1); | ||
- | } | ||
- | </code> | ||
- | O astfel de abordare nu ar mai ocupa timp inutil de procesor, dar timpul de răspuns în cazul sosirii unui semnal este destul de mare. O altă soluție a problemei este funcția [[http://man7.org/linux/man-pages/man2/pause.2.html|pause]] (care blochează fluxul de execuție până când procesul curent este întrerupt de un semnal). Deși această abordare pare foarte simplă, ea introduce, adeseori, deadlock-uri, care blochează programul nedefinit. Un exemplu în acest sens este pseudosoluția de mai jos, la problema așteptării unui semnal: | ||
- | <code c> | ||
- | while (!signal_has_arrived) { | ||
- | pause(); | ||
- | } | ||
- | </code> | ||
- | Bucla este necesară pentru prevenirea situației în care procesul este întrerupt de alte semnale decât cel așteptat. Se poate întâmpla ca semnalul să ajungă **după** testarea variabilei și **înainte** de apelul funcției pause. În acest caz, procesul se blochează și, dacă nu apare un alt semnal care să cauzeze ieșirea din [[http://man7.org/linux/man-pages/man2/pause.2.html|pause]], el va rămâne blocat nedefinit. | ||
- | </spoiler> | ||
- | Soluția cea mai bună pentru a aștepta un semnal se poate realiza prin utilizarea funcției [[http://man7.org/linux/man-pages/man2/sigsuspend.2.html|sigsuspend]]: | ||
- | <code c> | ||
- | int sigsuspend(const sigset_t *set); | ||
- | </code> | ||
- | Funcția înlocuiește masca de semnale blocate a procesului, cu set, și suspendă procesul până când este primit un semnal care nu este blocat de noua mască. La ieșire, funcția restaurează vechea mască de semnale. | ||
- | În secvența de mai jos, funcția [[http://www.kernel.org/doc/man-pages/online/pages/man2/sigsuspend.2.html|sigsuspend]] este folosită pentru a întrerupe procesul curent până la recepționarea semnalului ''SIGINT''. Semnalele ''SIGKILL și SIGSTOP'', deși prezente în masca de semnale, nu vor fi blocate: | ||
- | <code c> | ||
- | sigset_t set; | ||
- | |||
- | /* block all signals except SIGINT */ | ||
- | sigfillset(&set); | ||
- | sigdelset(&set, SIGINT); | ||
- | |||
- | /* wait for SIGINT */ | ||
- | sigsuspend(&set); | ||
- | </code> | ||
- | ===== Timere în Linux===== | ||
- | |||
- | În Linux, folosirea timer-elor este legată de folosirea semnalelor. Acest lucru se întâmplă întrucât cea mai mare parte a funcțiilor de tip timer folosesc semnale. | ||
- | |||
- | Un **timer** este, de obicei, un întreg a cărui valoare este decrementată în timp. În momentul în care întregul ajunge la 0, timer-ul expiră. În Linux, expirarea timer-ului are drept rezultat, în general, transmiterea unui semnal. Definirea unui “timer handler” (rutină apelată în momentul expirării timer-ului) este, astfel, echivalentă cu definirea unui handler pentru semnalul asociat. | ||
- | |||
- | Înregistrarea unui timer, în Linux, înseamnă specificarea unui interval după care un timer expiră și configurarea handler-ului care va rula. Configurarea handler-ului se poate realiza atât prin intermediul funcției ''sigaction'' (în momentul în care timer-ul expiră se generază un semnal, care la rândul lui generează rularea handler-ului asociat), sau direct prin intermediul parametrilor funcției [[http://www.kernel.org/doc/man-pages/online/pages/man2/timer_create.2.html|timer_create]]. | ||
- | Utilizarea unui timer presupune mai mulți pași: | ||
- | * **crearea unui timer -** folosind funcția [[http://www.kernel.org/doc/man-pages/online/pages/man2/timer_create.2.html|timer_create]]: | ||
- | <code c> | ||
- | int timer_create(clockid_t clockid, struct sigevent *evp, timer_t *timerid) | ||
- | </code> | ||
- | Timer-ul creat se identifică prin ''timerid''. Prin intermediul structurii ''sigevent'' se setează modul în care va interacționa timer-ul cu procesul/thread-ul care l-a lansat. Exemplu de folosire: | ||
- | <code c> | ||
- | timer_t timerid; | ||
- | struct sigevent sev; | ||
- | |||
- | sev.sigev_notify = SIGEV_SIGNAL; /* notification method */ | ||
- | sev.sigev_signo = SIGRTMIN; /* Timer expiration signal */ | ||
- | sev.sigev_value.sival_ptr = &timerid; | ||
- | timer_create(CLOCK_REALTIME, &sev, &timerid); | ||
- | </code> | ||
- | Prin intermediul primului argument se poate măsura timpul real al sistemului, timpul de rulare al procesului sau timpul de rulare al procesului în user-space și kernel-space. La timeout timer-ul va livra semnalul salvat în ''sev.sigev_signo''. | ||
- | |||
- | * **armarea unui timer -** folosind funcția [[http://www.kernel.org/doc/man-pages/online/pages/man2/timer_settime.2.html|timer_settime]]: | ||
- | <code c> | ||
- | int timer_settime(timer_t timerid, int flags, | ||
- | const struct itimerspec *new_value, | ||
- | struct itimerspec * old_value); | ||
- | </code> | ||
- | Armarea timer-ului presupune completarea structurii ''itimerspec'' în care specifică timpul de pornire al timer-ului, cât și intervalul de expirare al timeout-ului (intervalele sunt măsurate în secunde și nanosecunde). Exemplu de folosire: | ||
- | <code c> | ||
- | its.it_value.tv_sec = freq_nanosecs / 1000000000; /* Initial expiration in secs*/ | ||
- | its.it_value.tv_nsec = freq_nanosecs % 1000000000;/* Initial expiration in nsecs*/ | ||
- | its.it_interval.tv_sec = its.it_value.tv_sec; /* Timer interval in secs */ | ||
- | its.it_interval.tv_nsec = its.it_value.tv_nsec; /* Timer interval in nanosecs */ | ||
- | |||
- | timer_settime(timerid, 0, &its, NULL); | ||
- | </code> | ||
- | * **ștergerea unui timer -** folosind funcția [[http://man7.org/linux/man-pages/man2/timer_delete.2.html|timer_delete]] | ||
- | <code c> | ||
- | int timer_delete(timer_t timerid); | ||
- | </code> | ||
- | <note warning> Pentru a folosi funcțiile de mai sus programul trebuie compilat cu ''-lrt''</note> | ||
- | Una dintre formele de utilizare a timer-elor este implementarea funcțiilor de așteptare de tipul [[http://www.kernel.org/doc/man-pages/online/pages/man3/sleep.3.html|sleep]] sau [[http://www.kernel.org/doc/man-pages/online/pages/man2/nanosleep.2.html|nanosleep]]. Avantajul folosirii funcției [[http://www.kernel.org/doc/man-pages/online/pages/man3/sleep.3.html|sleep]] este simplitatea. Dezavantajele sunt rezoluția scăzută (secunde) și posibila interacțiune cu semnale (în special ''SIGALRM''). [[http://www.kernel.org/doc/man-pages/online/pages/man2/nanosleep.2.html|nanosleep]] are un apel mai complex, dar oferă rezoluție până la ordinul nanosecundelor și este //''signal-safe''// (nu interacționează cu semnale). | ||
- | |||
- | |||