1 \chapter{La gestione dei processi}
2 \label{cha:process_handling}
4 Come accennato nell'introduzione in un sistema Unix ogni attività del sistema
5 viene svolta tramite i processi. In sostanza i processi costituiscono l'unità
6 base per l'allocazione e l'uso delle risorse del sistema.
8 Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come
9 unità a se stante, in questo esamineremo il funzionamento dei processi
10 all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
11 della distruzione dei processi, della gestione dei loro attributi e privilegi,
12 e di tutte le funzioni a questo connesse. Infine nella sezione finale
13 affronteremo alcune problematiche generiche della programmazione in ambiente
18 \section{Introduzione}
21 Inizieremo con una introduzione generale ai concetti che stanno alla base
22 della gestione dei processi in un sistema unix-like. Introdurremo in questa
23 sezione l'architettura della gestione dei processi e le sue principali
24 caratteristiche, dando una panoramica sull'uso delle principali funzioni di
28 \subsection{L'architettura della gestione dei processi}
29 \label{sec:proc_hierarchy}
31 A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
32 generazione di nuovi processi è un'operazione privilegiata) una delle
33 caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
34 qualunque processo può a sua volta generarne altri, detti processi figli
35 (\textit{child process}). Ogni processo è identificato presso il sistema da un
36 numero unico, il cosiddetto \textit{process identifier} o, più brevemente,
39 Una seconda caratteristica di un sistema Unix è che la generazione di un
40 processo è una operazione separata rispetto al lancio di un programma. In
41 genere la sequenza è sempre quella di creare un nuovo processo, il quale
42 eseguirà, in un passo successivo, il programma voluto: questo è ad esempio
43 quello che fa la shell quando mette in esecuzione il programma che gli
44 indichiamo nella linea di comando.
46 Una terza caratteristica è che ogni processo è sempre stato generato da un
47 altro, che viene chiamato processo padre (\textit{parent process}). Questo
48 vale per tutti i processi, con una sola eccezione: dato che ci deve essere un
49 punto di partenza esiste un processo speciale (che normalmente è
50 \cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
51 di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
52 \acr{pid} uguale a 1 e non è figlio di nessun altro processo.
54 Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
55 partire tutti gli altri processi necessari al funzionamento del sistema,
56 inoltre \cmd{init} è essenziale per svolgere una serie di compiti
57 amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
58 essi in \secref{sec:proc_termination}) e non può mai essere terminato. La
59 struttura del sistema comunque consente di lanciare al posto di \cmd{init}
60 qualunque altro programma, e in casi di emergenza (ad esempio se il file di
61 \cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
62 posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
67 [piccardi@gont piccardi]$ pstree -n
84 |-bash---startx---xinit-+-XFree86
85 | `-WindowMaker-+-ssh-agent
93 | |-wterm---bash---pstree
94 | `-wterm---bash-+-emacs
100 \caption{L'albero dei processi, così come riportato dal comando
102 \label{fig:proc_tree}
105 Dato che tutti i processi attivi nel sistema sono comunque generati da
106 \cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
107 vero, in Linux ci sono alcuni processi che pur comparendo come figli di
108 init, o con \acr{pid} successivi, sono in realtà generati direttamente dal
109 kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.)} si possono classificare i
110 processi con la relazione padre/figlio in una organizzazione gerarchica ad
111 albero, in maniera analoga a come i file sono organizzati in un albero di
112 directory (si veda \secref{sec:file_organization}); in \curfig\ si è mostrato
113 il risultato del comando \cmd{pstree} che permette di mostrare questa
114 struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
118 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
119 \textit{process table}; per ciascun processo viene mantenuta una voce nella
120 tabella dei processi costituita da una struttura \type{task\_struct}, che
121 contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
122 usate a questo scopo sono dichiarate nell'header file \file{linux/sched.h}, ed
123 uno schema semplificato che riporta la struttura delle principali informazioni
124 contenute nella \type{task\_struct} (che in seguito incontreremo a più
125 riprese), è mostrato in \nfig.
129 \includegraphics[width=13cm]{img/task_struct}
130 \caption{Schema semplificato dell'architettura delle strutture usate dal
131 kernel nella gestione dei processi.}
132 \label{fig:proc_task_struct}
136 Come accennato in \secref{sec:intro_unix_struct} è lo \textit{scheduler} che
137 decide quale processo mettere in esecuzione; esso viene eseguito ad ogni
138 system call ed ad ogni interrupt, (ma può essere anche attivato
139 esplicitamente). Il timer di sistema provvede comunque a che esso sia invocato
140 periodicamente, generando un interrupt periodico secondo la frequenza
141 specificata dalla costante \macro{HZ}, definita in \file{asm/param.h} Il
142 valore usuale è 100 (è espresso in Hertz), si ha cioè un interrupt dal timer
143 ogni centesimo di secondo.
145 Ogni volta che viene eseguito, lo \textit{scheduler} effettua il calcolo delle
146 priorità dei vari processi attivi (torneremo su questo in
147 \secref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
148 esecuzione fino alla successiva invocazione.
151 \subsection{Una panoramica sulle funzioni fondamentali}
152 \label{sec:proc_handling_intro}
154 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
155 una system call, Linux però usa un'altra nomenclatura, e la funzione
156 \func{fork} è basata a sua volta sulla system call \func{\_\_clone}, che viene
157 usata anche per generare i \textit{thread}. Il processo figlio creato dalla
158 \func{fork} è una copia identica del processo processo padre, ma ha nuovo
159 \acr{pid} e viene eseguito in maniera indipendente (le differenze fra padre e
160 figlio sono affrontate in dettaglio in \secref{sec:proc_fork}).
162 Se si vuole che il processo padre si fermi fino alla conclusione del processo
163 figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
164 funzione \func{wait} o la funzione \func{waitpid} (si veda
165 \secref{sec:proc_wait}); queste funzioni restituiscono anche una informazione
166 abbastanza limitata (lo stato di terminazione) sulle cause della terminazione
169 Quando un processo ha concluso il suo compito o ha incontrato un errore non
170 risolvibile esso può essere terminato con la funzione \func{exit} (si veda
171 quanto discusso in \secref{sec:proc_conclusion}). La vita del processo però
172 termina solo quando la notifica della sua conclusione viene ricevuta dal
173 processo padre, a quel punto tutte le risorse allocate nel sistema ad esso
174 associate vengono rilasciate.
176 Avere due processi che eseguono esattamente lo stesso codice non è molto
177 utile, normalmente si genera un secondo processo per affidargli l'esecuzione
178 di un compito specifico (ad esempio gestire una connessione dopo che questa è
179 stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
180 quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
181 coi processi che è la \func{exec}.
183 Il programma che un processo sta eseguendo si chiama immagine del processo (o
184 \textit{process image}), le funzioni della famiglia \func{exec} permettono di
185 caricare un'altro programma da disco sostituendo quest'ultimo all'immagine
186 corrente; questo fa si che l'immagine precedente venga completamente
187 cancellata. Questo significa che quando il nuovo programma esce anche il
188 processo termina, e non si può tornare alla precedente immagine.
190 Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
191 particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
192 prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
193 non ritorna mai (in quanto con essa viene eseguito un altro programma).
197 \section{Le funzioni di base}% della gestione dei processi}
198 \label{sec:proc_handling}
200 In questa sezione tratteremo le problematiche della gestione dei processi
201 all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con le
202 funzioni elementari che permettono di leggerne gli identificatori, per poi
203 passare alla spiegazione delle funzioni base che si usano per la creazione e
204 la terminazione dei processi, e per la messa in esecuzione degli altri
208 \subsection{Gli identificatori dei processi}
211 Come accennato nell'introduzione ogni processo viene identificato dal sistema
212 da un numero identificativo unico, il \textit{process id} o \acr{pid};
213 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
214 intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è \type{int}).
216 Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
217 processo viene creato, fino ad un limite massimo (in genere essendo detto
218 numero memorizzato in un intero a 16 bit si arriva a 32767) oltre il quale si
219 riparte dal numero più basso disponibile (FIXME: verificare, non sono sicuro).
220 Per questo motivo processo il processo di avvio (\cmd{init}) ha sempre il
221 \acr{pid} uguale a uno.
223 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
224 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
225 \textit{parent process id}). Questi due identificativi possono essere
226 ottenuti da programma usando le funzioni:
228 \headdecl{sys/types.h}
230 \funcdecl{pid\_t getpid(void)} Restituisce il pid del processo corrente.
231 \funcdecl{pid\_t getppid(void)} Restituisce il pid del padre del processo
234 \bodydesc{Entrambe le funzioni non riportano condizioni di errore.}
236 \noindent esempi dell'uso di queste funzioni sono riportati in
237 \figref{fig:proc_fork_code}, nel programma di esempio \file{ForkTest.c}.
239 Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende il
240 candidato ideale per generare ulteriori indicatori associati al processo di
241 cui diventa possibile garantire l'unicità: ad esempio la funzione
242 \func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid} per
243 generare un pathname univoco, che non potrà essere replicato da un'altro
244 processo che usi la stessa funzione.
246 Tutti i processi figli dello stesso processo padre sono detti
247 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
248 sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
249 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
250 \secref{cha:session}, dove esamineremo gli altri identificativi associati ad
251 un processo e le varie relazioni fra processi utilizzate per definire una
254 Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
255 \secref{sec:sess_xxx}, relativi al controllo di sessione), ad ogni processo
256 vengono associati degli altri identificatori che vengono usati per il
257 controllo di accesso. Questi servono per determinare se un processo può
258 eseguire o meno le operazioni richieste, a seconda dei privilegi e
259 dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
260 affrontato in dettaglio in \secref{sec:proc_perms}.
263 \subsection{La funzione \func{fork}}
264 \label{sec:proc_fork}
266 La funzione \func{fork} è la funzione fondamentale della gestione dei
267 processi: come si è detto l'unico modo di creare un nuovo processo è
268 attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale
269 tutte le volte che si devono scrivere programmi che usano il multitasking. Il
270 prototipo della funzione è:
272 \headdecl{sys/types.h}
274 \funcdecl{pid\_t fork(void)}
275 Crea un nuovo processo.
277 \bodydesc{Restituisce zero al padre e il \acr{pid} al figlio in caso di
278 successo, ritorna -1 al padre (senza creare il figlio) in caso di errore;
279 \var{errno} può assumere i valori:
281 \item[\macro{EAGAIN}] non ci sono risorse sufficienti per creare un'altro
282 processo (per allocare la tabella delle pagine e le strutture del task) o
283 si è esaurito il numero di processi disponibili.
284 \item[\macro{ENOMEM}] non è stato possibile allocare la memoria per le
285 strutture necessarie al kernel per creare il nuovo processo.
289 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
290 il processo figlio continuano ad essere eseguiti normalmente alla istruzione
291 seguente la \func{fork}; il processo figlio è però una copia del padre, e
292 riceve una copia dei segmenti di testo, stack e dati (vedi
293 \secref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
294 padre, ma la memoria è copiata, non condivisa\footnote{In generale il segmento
295 di testo, che è identico, è condiviso e tenuto in read-only, Linux poi
296 utilizza la tecnica del \textit{copy-on-write}, per cui la memoria degli
297 altri segmenti viene copiata dal kernel per il nuovo processo solo in caso
298 di scrittura, rendendo molto più efficiente il meccanismo della creazione di
299 un nuovo processo}, pertanto padre e figlio vedono variabili diverse.
301 La differenza che si ha nei due processi è che nel processo padre il valore di
302 ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
303 nel figlio è zero; in questo modo il programma può identificare se viene
304 eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
305 \textbf{due} volte: una nel padre e una nel figlio.
307 La scelta di questi valori di ritorno non è casuale, un processo infatti può
308 avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
309 permette di identificare quello appena creato; al contrario un figlio ha
310 sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
311 \func{getppid}, vedi \secref{sec:proc_pid}) per cui si usa il valore nullo,
312 che non è il \acr{pid} di nessun processo.
317 #include <errno.h> /* error definitions and routines */
318 #include <stdlib.h> /* C standard library */
319 #include <unistd.h> /* unix standard library */
320 #include <stdio.h> /* standard I/O library */
321 #include <string.h> /* string functions */
323 /* Help printing routine */
326 int main(int argc, char *argv[])
329 * Variables definition
336 ... /* handling options */
337 nchild = atoi(argv[optind]);
338 printf("Test for forking %d child\n", nchild);
339 /* loop to fork children */
340 for (i=0; i<nchild; i++) {
341 if ( (pid = fork()) < 0) {
343 printf("Error on %d child creation, %s\n", i+1, strerror(errno));
346 if (pid == 0) { /* child */
347 printf("Child %d successfully executing\n", ++i);
348 if (wait_child) sleep(wait_child);
349 printf("Child %d, parent %d, exiting\n", i, getppid());
351 } else { /* parent */
352 printf("Spawned %d child, pid %d \n", i+1, pid);
353 if (wait_parent) sleep(wait_parent);
354 printf("Go to next child \n");
358 if (wait_end) sleep(wait_end);
362 \caption{Esempio di codice per la creazione di nuovi processi.}
363 \label{fig:proc_fork_code}
366 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
367 sono già troppi processi nel sistema (il che di solito è sintomo che
368 qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
369 sul numero totale di processi permessi all'utente (vedi \secref{sec:sys_xxx}).
371 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
372 quella in cui all'interno di un programma si creano processi figli per
373 affidargli l'esecuzione di una certa sezione di codice, mentre il processo
374 padre ne esegue un'altra. È il caso tipico dei server di rete in cui il padre
375 riceve ed accetta le richieste da parte dei client, per ciascuna delle quali
376 pone in esecuzione un figlio che è incaricato di fornire il servizio.
378 La seconda modalità è quella in cui il processo vuole eseguire un altro
379 programma; questo è ad esempio il caso della shell. In questo caso il processo
380 crea un figlio la cui unica operazione è quella fare una \func{exec} (di cui
381 parleremo in \secref{sec:proc_exec}) subito dopo la \func{fork}.
383 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
384 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
385 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
386 scelto di mantenere questa separazione, dato che, come per la prima modalità
387 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
388 aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
389 seconda modalità di uso, avere le due funzioni separate permette al figlio di
390 cambiare gli attributi del processo (maschera dei segnali, redirezione
391 dell'output, \textit{user id}) prima della \func{exec}, rendendo così
392 relativamente facile intervenire sulle le modalità di esecuzione del nuovo
395 In \curfig\ si è riportato il corpo del codice del programma di esempio
396 \cmd{forktest}, che ci permette di illustrare molte caratteristiche dell'uso
397 della funzione \func{fork}. Il programma permette di creare un numero di figli
398 specificato a linea di comando, e prende anche alcune opzioni per indicare
399 degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
400 \func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
401 descrizione delle opzioni); il codice completo, compresa la parte che gestisce
402 le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c}.
404 Decifrato il numero di figli da creare, il ciclo principale del programma
405 (\texttt{\small 28--40}) esegue in successione la creazione dei processi figli
406 controllando il successo della chiamata a \func{fork} (\texttt{\small
407 29--31}); ciascun figlio (\texttt{\small 29--31}) si limita a stampare il
408 suo numero di successione, eventualmente attendere il numero di secondi
409 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
410 (\texttt{\small 29--31}) stampa un messaggio di creazione, eventualmente
411 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
412 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
415 Se eseguiamo il comando senza specificare attese (come si può notare in
416 \texttt{\small 17--19} i valori di default specificano di non attendere),
417 otterremo come output sul terminale:
421 [piccardi@selidor sources]$ ./forktest 3
422 Process 1963: forking 3 child
423 Spawned 1 child, pid 1964
424 Child 1 successfully executing
425 Child 1, parent 1963, exiting
427 Spawned 2 child, pid 1965
428 Child 2 successfully executing
429 Child 2, parent 1963, exiting
431 Child 3 successfully executing
432 Child 3, parent 1963, exiting
433 Spawned 3 child, pid 1966
438 Esaminiamo questo risultato: una prima conclusione che si può trarre è non si
439 può dire quale processo fra il padre ed il figlio venga eseguito per
440 primo\footnote{anche se nel kernel 2.4.x era stato introdotto un meccanismo
441 che metteva in esecuzione sempre il xxx per primo (TODO recuperare le
442 informazioni esatte)} dopo la chiamata a \func{fork}; dall'esempio si può
443 notare infatti come nei primi due cicli sia stato eseguito per primo il padre
444 (con la stampa del \acr{pid} del nuovo processo) per poi passare
445 all'esecuzione del figlio (completata con i due avvisi di esecuzione ed
446 uscita), e tornare all'esecuzione del padre (con la stampa del passaggio al
447 ciclo successivo), mentre la terza volta è stato prima eseguito il figlio
448 (fino alla conclusione) e poi il padre.
450 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
451 scheduling usato dal kernel, dalla particolare situazione in si trova la
452 macchina al momento della chiamata, risultando del tutto impredicibile.
453 Eseguendo più volte il programma di prova e producendo un numero diverso di
454 figli, si sono ottenute situazioni completamente diverse, compreso il caso in
455 cui il processo padre ha eseguito più di una \func{fork} prima che uno dei
456 figli venisse messo in esecuzione.
458 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
459 istruzioni del codice fra padre e figli, nè sull'ordine in cui questi potranno
460 essere messi in esecuzione, e se è necessaria una qualche forma di precedenza
461 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
462 rischio di incorrere nelle cosiddette \textit{race condition} \index{race
463 condition} (vedi \secref{sec:proc_race_cond}.
465 Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
466 processi completamente separati, le modifiche delle variabili nei processi
467 figli (come l'incremento di \var{i} in \texttt{\small 33}) sono visibili solo
468 a loro, e non hanno alcun effetto sul valore che le stesse variabili hanno nel
469 processo padre (ed in eventuali altri processi figli che eseguano lo stesso
472 Un secondo aspetto molto importante nella creazione dei processi figli è
473 quello dell'interazione dei vari processi con i file; per illustrarlo meglio
474 proviamo a redirigere su un file l'output del nostro programma di test, quello
479 [piccardi@selidor sources]$ ./forktest 3 > output
480 [piccardi@selidor sources]$ cat output
481 Process 1967: forking 3 child
482 Child 1 successfully executing
483 Child 1, parent 1967, exiting
484 Test for forking 3 child
485 Spawned 1 child, pid 1968
487 Child 2 successfully executing
488 Child 2, parent 1967, exiting
489 Test for forking 3 child
490 Spawned 1 child, pid 1968
492 Spawned 2 child, pid 1969
494 Child 3 successfully executing
495 Child 3, parent 1967, exiting
496 Test for forking 3 child
497 Spawned 1 child, pid 1968
499 Spawned 2 child, pid 1969
501 Spawned 3 child, pid 1970
505 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
507 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
508 in gran dettaglio in \capref{cha:file_unix_interface} e in
509 \secref{cha:files_std_interface}. Qui basta accennare che si sono usate le
510 funzioni standard della libreria del C che prevedono l'output bufferizzato; e
511 questa bufferizzazione (di veda \secref{sec:file_buffering}) varia a seconda
512 che si tratti di un file su disco (in cui il buffer viene scaricato su disco
513 solo quando necessario) o di un terminale (nel qual caso il buffer viene
514 scaricato ad ogni carattere di a capo).
516 Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
517 buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
518 l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
519 non avviene più alla fine di ogni riga e l'output resta nel buffer. Per questo
520 motivo, dato che ogni figlio riceve una copia della memoria del padre, esso
521 riceverà anche quanto c'è nel buffer delle funzioni di I/O, comprese le linee
522 scritte dal padre fino allora. Così quando all'uscita del figlio il buffer
523 viene scritto su disco, troveremo nel file anche tutto quello che il processo
524 padre aveva scritto prima della sua creazione. E solo alla fine del file,
525 dato che in questo caso il padre esce per ultimo, troveremo anche l'output del
528 Ma l'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i
529 file, che era valido anche per l'esempio precedente, ma meno evidente; il
530 fatto cioè che non solo processi diversi possono scrivere in contemporanea
531 sullo stesso file (l'argomento della condivisione dei file in unix è trattato
532 in dettaglio in \secref{sec:file_sharing}), ma anche che, a differenza di
533 quanto avviene per le variabili, la posizione corrente sul file è condivisa
534 fra il padre e tutti i processi figli.
536 Quello che succede è che quando lo standard output del padre viene rediretto,
537 lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha
538 la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione
539 \func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file
540 descriptor aperti nel padre, il che comporta che padre e figli condividono le
541 stesse voci della \textit{file table} (per la spiegazione di questi termini si
542 veda \secref{sec:file_sharing}) e fra cui c'è anche la posizione corrente nel
545 In questo modo se un processo scrive sul file aggiornerà la posizione corrente
546 sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
547 \textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
548 casi come quello appena mostrato in cui diversi processi scrivono sullo stesso
549 file, che l'output successivo di un processo vada a sovrapporsi a quello dei
550 precedenti: l'output potrà risultare mescolato, ma non ci saranno parti
551 perdute per via di una sovrascrittura.
553 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
554 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
555 scrivono sullo stesso file (un caso tipico è la shell quando lancia un
556 programma, il cui output va sullo standard output).
558 In questo modo, anche se l'output viene rediretto, il padre potrà sempre
559 continuare a scrivere in coda a quanto scritto dal figlio in maniera
560 automatica; se così non fosse ottenere questo comportamento sarebbe
561 estremamente complesso necessitando di una qualche forma di comunicazione fra
562 i due processi per far riprendere al padre la scrittura al punto giusto.
564 In generale comunque non è buona norma far scrivere più processi sullo stesso
565 file senza una qualche forma di sincronizzazione in quanto, come visto anche
566 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
567 una sequenza impredicibile. Per questo le modalità con cui in genere si usano
568 i file dopo una \func{fork} sono sostanzialmente due:
570 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
571 è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
572 della posizione corrente dopo eventuali operazioni di lettura e scrittura
573 effettuate dal figlio è automatica.
574 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
575 ciascuno dei due processi deve chiudere i file che non gli servono una volta
576 che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
579 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
580 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
581 comune dopo l'esecuzione di una \func{fork} è la seguente:
583 \item i file aperti e gli eventuali flag di \textit{close-on-exec} settati
584 (vedi \secref{sec:proc_exec} e \secref{sec:file_fcntl}).
585 \item gli identificatori per il controllo di accesso: il \textit{real user
586 id}, il \textit{real group id}, l'\textit{effective user id},
587 l'\textit{effective group id} ed i \textit{supplementary group id} (vedi
588 \secref{sec:proc_access_id}).
589 \item gli identificatori per il controllo di sessione: il \textit{process
590 group id} e il \textit{session id} ed il terminale di controllo (vedi
591 \secref{sec:sess_xxx} e \secref{sec:sess_xxx}).
592 \item la directory di lavoro e la directory radice (vedi
593 \secref{sec:file_work_dir} e \secref{sec:file_chroot}).
594 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
595 \item la maschera dei segnali bloccati e le azioni installate (vedi
596 \secref{sec:sig_xxx}).
597 \item i segmenti di memoria condivisa agganciati al processo (vedi
598 \secref{sec:ipc_xxx}).
599 \item i limiti sulle risorse (vedi \secref{sec:sys_xxx}).
600 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
602 le differenze fra padre e figlio dopo la \func{fork} invece sono:
604 \item il valore di ritorno di \func{fork}.
605 \item il \textit{process id}.
606 \item il \textit{parent process id} (quello del figlio viene settato al
607 \acr{pid} del padre).
608 \item i valori dei tempi di esecuzione (vedi \secref{sec:sys_xxx}) che
609 nel figlio sono posti a zero.
610 \item i \textit{file lock} (vedi \secref{sec:file_locking}), che non
611 vengono ereditati dal figlio.
612 \item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_xxx}), che per il figlio vengono cancellati.
616 \subsection{La funzione \func{vfork}}
617 \label{sec:proc_vfork}
619 La funzione \func{vfork} è esattamente identica a \func{fork} ed ha la stessa
620 semantica e gli stessi errori; la sola differenza è che non viene creata la
621 tabella delle pagine né la struttura dei task per il nuovo processo. Il
622 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
623 \func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
624 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
625 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
627 Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
628 \func{fork} comportava anche la copia completa del segmento dati del processo
629 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
630 \func{fork} veniva fatto solo per poi eseguire una \func{exec}. La funzione
631 venne introdotta in BSD per migliorare le prestazioni.
633 Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è
634 assolutamente trascurabile, e l'uso di questa funzione (che resta un caso
635 speciale della funzione \func{clone}), è deprecato; per questo eviteremo di
636 trattarla ulteriormente.
639 \subsection{La conclusione di un processo.}
640 \label{sec:proc_termination}
642 In \secref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
643 chiudere un programma, ma dal punto di vista del programma stesso; avendo a
644 che fare con un sistema multitasking occorre adesso affrontare l'argomento dal
645 punto di vista generale di come il sistema gestisce la conclusione dei
648 Abbiamo già visto in \secref{sec:proc_conclusion} le tre modalità con cui un
649 programma viene terminato in maniera normale: la chiamata di \func{exit} (che
650 esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
651 dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
652 chiamata ad \func{\_exit} (che passa direttamente alle operazioni di
653 terminazione del processo da parte del kernel).
655 Ma oltre alla conclusione normale abbiamo accennato che esistono anche delle
656 modalità di conclusione anomala; queste sono in sostanza due: il programma può
657 chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
658 terminato da un segnale. In realtà anche la prima modalità si riconduce alla
659 seconda, dato che \func{abort} si limita a generare il segnale
662 Qualunque sia la modalità di conclusione di un processo, il kernel esegue
663 comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
664 memoria che stava usando, e così via; l'elenco completo delle operazioni
665 eseguite alla chiusura di un processo è il seguente:
667 \item tutti i file descriptor sono chiusi.
668 \item viene memorizzato lo stato di terminazione del processo.
669 \item ad ogni processo figlio viene assegnato un nuovo padre (in genere
671 \item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi
672 \secref{sec:sig_xxx}).
673 \item se il processo è un leader di sessione viene mandato un segnale di
674 \macro{SIGHUP} a tutti i processi in background e il terminale di
675 controllo viene disconnesso (vedi \secref{sec:sess_xxx}).
676 \item se la conclusione di un processo rende orfano un \textit{process
677 group} ciascun membro del gruppo viene bloccato, e poi gli vengono
678 inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}
679 (vedi \secref{sec:sess_xxx}).
681 ma al di la di queste operazioni è necessario poter disporre di un meccanismo
682 ulteriore che consenta di sapere come questa terminazione è avvenuta; dato che
683 in un sistema unix-like tutto viene gestito attraverso i processi il
684 meccanismo scelto consiste nel riportare lo stato di terminazione (il
685 cosiddetto \textit{termination status}) al processo padre.
687 Nel caso di conclusione normale, abbiamo visto in \secref{sec:proc_conclusion}
688 che lo stato di uscita del processo viene caratterizzato tramite il valore del
689 cosiddetto \textit{exit status}, cioè il valore passato alle funzioni
690 \func{exit} o \func{\_exit} (o dal valore di ritorno per \func{main}). Ma se
691 il processo viene concluso in maniera anomala il programma non può specificare
692 nessun \textit{exit status}, ed è il kernel che deve generare autonomamente il
693 \textit{termination status} per indicare le ragioni della conclusione anomala.
695 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
696 quello che contraddistingue lo stato di chiusura del processo e viene
697 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
698 \secref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
699 il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
702 La scelta di riportare al padre lo stato di terminazione dei figli, pur
703 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
704 alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
705 che sia così alla sua conclusione, dato che il padre potrebbe essere già
706 terminato (si potrebbe avere cioè quello che si chiama un processo
709 Questa complicazione viene superata facendo in modo che il processo figlio
710 venga \textsl{adottato} da \cmd{init}: come già accennato quando un processo
711 termina il kernel controlla se è il padre di altri processi in esecuzione: in
712 caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
713 con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
714 avrà sempre un padre (nel caso \textsl{adottivo}) cui riportare il suo stato
715 di terminazione. Come verifica di questo comportamento possiamo eseguire il
716 comando \cmd{forktest} imponendo a ciascun processo figlio due
717 secondi di attesa prima di uscire, il risultato è:
721 [piccardi@selidor sources]$ ./forktest -c2 3
722 Process 1972: forking 3 child
723 Spawned 1 child, pid 1973
724 Child 1 successfully executing
726 Spawned 2 child, pid 1974
727 Child 2 successfully executing
729 Child 3 successfully executing
730 Spawned 3 child, pid 1975
732 [piccardi@selidor sources]$ Child 3, parent 1, exiting
733 Child 2, parent 1, exiting
734 Child 1, parent 1, exiting
737 come si può notare in questo caso il processo padre si conclude prima dei
738 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
739 secondi dopo viene stampato a video anche l'output dei tre figli che
740 terminano, e come si può notare in questo caso, al contrario di quanto visto
741 in precedenza, essi riportano 1 come \acr{ppid}.
743 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
744 perché non è detto che il padre possa ricevere immediatamente lo stato di
745 terminazione, quindi il kernel deve comunque conservare una certa quantità di
746 informazioni riguardo ai processi che sta terminando.
748 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
749 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
750 dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di
751 terminazione\footnote{NdA verificare esattamente cosa c'è!}, mentre la memoria
752 in uso ed i file aperti vengono rilasciati immediatamente. I processi che sono
753 terminati, ma il cui stato di terminazione non è stato ancora ricevuto dal
754 padre sono chiamati \textit{zombie}, essi restano presenti nella tabella dei
755 processi ed in genere possono essere identificati dall'output di \cmd{ps} per
756 la presenza di una \texttt{Z} nella colonna che ne indica lo stato. Quando il
757 padre effettuerà la lettura dello stato di uscita anche questa informazione,
758 non più necessaria, verrà scartata e la terminazione potrà dirsi completamente
761 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
762 condizione: lanciamo il comando \cmd{forktest} in background, indicando al
763 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
764 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
769 [piccardi@selidor sources]$ ps T
770 PID TTY STAT TIME COMMAND
771 419 pts/0 S 0:00 bash
772 568 pts/0 S 0:00 ./forktest -e10 3
773 569 pts/0 Z 0:00 [forktest <defunct>]
774 570 pts/0 Z 0:00 [forktest <defunct>]
775 571 pts/0 Z 0:00 [forktest <defunct>]
776 572 pts/0 R 0:00 ps T
779 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
780 terminazione, i tre processi figli sono ancora presenti pur essendosi
781 conclusi, con lo stato di zombie e l'indicazione che sono stati terminati.
783 La possibilità di avere degli zombie deve essere tenuta sempre presente quando
784 si scrive un programma che deve essere mantenuto in esecuzione a lungo e
785 creare molti figli. In questo caso si deve sempre avere cura di far leggere
786 l'eventuale stato di uscita di tutti i figli (in genere questo si fa
787 attraverso un apposito \textit{signal handler}, che chiama la funzione
788 \func{wait}, vedi \secref{sec:sig_xxx} e \secref{sec:proc_wait}). Questa
789 operazione è necessaria perché anche se gli \textit{zombie} non consumano
790 risorse di memoria o processore, occupano comunque una voce nella tabella dei
791 processi, che a lungo andare potrebbe esaurirsi.
793 Si noti che quando un processo adottato da \cmd{init} termina, esso non
794 diviene uno \textit{zombie}; questo perché una delle funzioni di \cmd{init} è
795 appunto quella di chiamare la funzione \func{wait} per i processi cui fa da
796 padre, completandone la terminazione. Questo è quanto avviene anche quando,
797 come nel caso del precedente esempio con \cmd{forktest}, il padre termina con
798 dei figli in stato di zombie: alla sua terminazione infatti tutti i suoi figli
799 vengono ereditati (compresi gli zombie) verranno adottati da \cmd{init}, il
800 quale provvederà a completarne la terminazione.
802 Si tenga presente infine che siccome gli zombie sono processi già usciti, non
803 c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità è quella
804 di terminare il processo che li ha generati, in modo che \cmd{init} possa
805 adottarli e provvedere a concludere la terminazione.
808 \subsection{Le funzioni \func{wait} e \func{waitpid}}
809 \label{sec:proc_wait}
811 Abbiamo già accennato come uno degli usi possibili delle capacità multitasking
812 di un sistema unix-like consista nella creazione di programmi di tipo server,
813 in cui un processo principale attende le richieste che vengono poi soddisfatte
814 creando una serie di processi figli. Si è già sottolineato al paragrafo
815 precedente come in questo caso diventi necessario gestire esplicitamente la
816 conclusione dei vari processi figli onde evitare di riempire di
817 \textit{zombie} la tabella dei processi; le funzioni deputate a questo compito
818 sono sostanzialmente due, \func{wait} e \func{waitpid}. La prima, il cui
821 \headdecl{sys/types.h}
822 \headdecl{sys/wait.h}
823 \funcdecl{pid\_t wait(int *status)}
825 Sospende il processo corrente finché un figlio non è uscito, o finché un
826 segnale termina il processo o chiama una funzione di gestione.
828 \bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
829 e -1 in caso di errore; \var{errno} può assumere i valori:
831 \item[\macro{EINTR}] la funzione è stata interrotta da un segnale.
835 è presente fin dalle prime versioni di unix; la funzione ritorna non appena un
836 processo figlio termina. Se un figlio è già terminato la funzione ritorna
839 Al ritorno lo stato di termininazione del processo viene salvato nella
840 variabile puntata da \var{status} e tutte le informazioni relative al
841 processo (vedi \secref{sec:proc_termination}) vengono rilasciate. Nel
842 caso un processo abbia più figli il valore di ritorno permette di
843 identificare qual'è quello che è uscito.
845 Questa funzione ha il difetto di essere poco flessibile, in quanto
846 ritorna all'uscita di un figlio qualunque. Nelle occasioni in cui è
847 necessario attendere la conclusione di un processo specifico occorre
848 predisporre un meccanismo che tenga conto dei processi già terminati, e
849 provveda a ripetere la chiamata alla funzione nel caso il processo
850 cercato sia ancora attivo.
852 Per questo motivo lo standard POSIX.1 ha introdotto la funzione \func{waitpid}
853 che effettua lo stesso servizio, ma dispone di una serie di funzionalità più
854 ampie, legate anche al controllo di sessione. Dato che è possibile ottenere
855 lo stesso comportamento di \func{wait} si consiglia di utilizzare sempre
856 questa funzione, il cui prototipo è:
858 \headdecl{sys/types.h}
859 \headdecl{sys/wait.h}
860 \funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
861 Attende la conclusione di un processo figlio.
863 \bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
864 è stata specificata l'opzione \macro{WNOHANG} e il processo non è uscito e
865 -1 per un errore, nel qual caso \var{errno} assumerà i valori:
867 \item[\macro{EINTR}] se non è stata specificata l'opzione \macro{WNOHANG} e
868 la funzione è stata interrotta da un segnale.
869 \item[\macro{ECHILD}] il processo specificato da \var{pid} non esiste o non è
870 figlio del processo chiamante.
874 Le differenze principali fra le due funzioni sono che \func{wait} si blocca
875 sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la
876 possibilità si specificare un'opzione \macro{WNOHANG} che ne previene il
877 blocco; inoltre \func{waitpid} può specificare quale processo attendere sulla
878 base del valore specificato tramite la variabile \var{pid}, secondo lo
879 specchietto riportato in \ntab:
883 \begin{tabular}[c]{|c|p{10cm}|}
885 \textbf{Valore} & \textbf{Significato}\\
888 $<-1$& attende per un figlio il cui \textit{process group} è uguale al
889 valore assoluto di \var{pid}. \\
890 $-1$ & attende per un figlio qualsiasi, usata in questa maniera è
891 equivalente a \func{wait}.\\
892 $0$ & attende per un figlio il cui \textit{process group} è uguale a
893 quello del processo chiamante. \\
894 $>0$ & attende per un figlio il cui \acr{pid} è uguale al
895 valore di \var{pid}.\\
898 \caption{Significato dei valori del parametro \var{pid} della funzione
900 \label{tab:proc_waidpid_pid}
903 Il comportamento di \func{waitpid} può essere modificato passando delle
904 opportune opzioni tramite la variabile \var{option}. I valori possibili sono
905 il già citato \macro{WNOHANG}, che previene il blocco della funzione quando il
906 processo figlio non è terminato, e \macro{WUNTRACED} (usata per il controllo
907 di sessione, trattato in \capref{cha:session}) che fa ritornare la funzione
908 anche per i processi figli che sono bloccati ed il cui stato non è stato
909 ancora riportato al padre. Il valore dell'opzione deve essere specificato come
910 maschera binaria ottenuta con l'OR delle suddette costanti con zero.
912 La terminazione di un processo figlio è chiaramente un evento asincrono
913 rispetto all'esecuzione di un programma e può avvenire in un qualunque
914 momento, per questo motivo, come si è visto nella sezione precedente, una
915 delle azioni prese dal kernel alla conclusione di un processo è quella di
916 mandare un segnale di \macro{SIGCHLD} al padre. Questo segnale viene ignorato
917 di default, ma costituisce il meccanismo di comunicazione asincrona con cui il
918 kernel avverte un processo padre che uno dei suoi figli è terminato.
920 In genere in un programma non si vuole essere forzati ad attendere la
921 conclusione di un processo per proseguire, specie se tutto questo serve solo
922 per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}),
923 per questo la modalità più usata per chiamare queste funzioni è quella di
924 utilizzarle all'interno di un \textit{signal handler} (torneremo sui segnali e
925 su come gestire \macro{SIGCHLD} in \secref{sec:sig_sigwait_xxx}) nel qual
926 caso, dato che il segnale è generato dalla terminazione un figlio, avremo la
927 certezza che la chiamata a \func{wait} non si bloccherà.
932 \begin{tabular}[c]{|c|p{10cm}|}
934 \textbf{Macro} & \textbf{Descrizione}\\
937 \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo
938 figlio che sia terminato normalmente. \\
939 \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
940 stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit}
941 o come valore di ritorno di \func{main}). Può essere valutata solo se
942 \macro{WIFEXITED} ha restituito un valore non nullo.\\
943 \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
944 in maniera anomala a causa di un segnale che non è stato catturato (vedi
945 \secref{sec:sig_notification}).\\
946 \macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato
947 la terminazione anomala del processo. Può essere valutata solo se
948 \macro{WIFSIGNALED} ha restituito un valore non nullo.\\
949 \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
950 file si \textit{core dump}. Può essere valutata solo se
951 \macro{WIFSIGNALED} ha restituito un valore non nullo\footnote{questa
952 macro non è definita dallo standard POSIX.1, ma è presente come estensione
953 sia in Linux che in altri unix}.\\
954 \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
955 \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato
956 l'opzione \macro{WUNTRACED}. \\
957 \macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato
958 il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha
959 restituito un valore non nullo. \\
962 \caption{Descrizione delle varie macro di preprocessore utilizzabili per
963 verificare lo stato di terminazione \var{s} di un processo.}
964 \label{tab:proc_status_macro}
967 Entrambe le funzioni di attesa restituiscono lo stato di terminazione del
968 processo tramite il puntatore \var{status} (se non interessa memorizzare lo
969 stato si può passare un puntatore nullo). Il valore restituito da entrambe le
970 funzioni dipende dall'implementazione, e tradizionalmente alcuni bit sono
971 riservati per memorizzare lo stato di uscita (in genere 8) altri per indicare
972 il segnale che ha causato la terminazione (in caso di conclusione anomala),
973 uno per indicare se è stato generato un core file, ecc\footnote{le
974 definizioni esatte si possono trovare in \file{<bits/waitstatus.h} ma questo
975 file non deve mai essere usato direttamente, esso viene incluso attraverso
976 \file{<sys/wait.h>}}. Lo standard POSIX.1 definisce una serie di macro di
977 preprocessore da usare per analizzare lo stato di uscita; esse sono definite
978 sempre in \file{<sys/wait.h>} ed elencate in \curtab\ (si tenga presente che
979 queste macro prendono come parametro la variabile di tipo \type{int} puntata
982 Si tenga conto che nel caso di conclusione anomala il valore restituito da
983 \macro{WTERMSIG} può essere controllato contro le costanti definite in
984 \file{signal.h} ed elencate in \tabref{tab:sig_signal_list}, e stampato usando
985 le apposite funzioni trattate in \secref{sec:sig_strsignal}.
988 \subsection{Le funzioni \func{wait3} e \func{wait4}}
989 \label{sec:proc_wait4}
991 Linux, seguendo una estensione di BSD, supporta altre due funzioni per la
992 lettura dello stato di terminazione di un processo, analoghe a \func{wait} e
993 \func{waitpid}, ma che prevedono un ulteriore parametro attraverso il quale il
994 kernel può restituire al padre informazioni sulle risorse usate dal processo
995 terminato e dai vari figli. Queste funzioni, che diventano accessibili
996 definendo la costante \macro{\_USE\_BSD}, sono:
998 \headdecl{sys/times.h}
999 \headdecl{sys/types.h}
1000 \headdecl{sys/wait.h}
1001 \headdecl{sys/resource.h}
1002 \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
1004 È identica a \func{waitpid} sia per comportamento che per i
1005 valori dei parametri, ma restituisce in \param{rusage} un sommario delle
1006 risorse usate dal processo (per i dettagli vedi \secref{sec:sys_xxx})
1008 \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
1009 Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
1010 ormai deprecata in favore di \func{wait4}.
1013 la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
1014 utilizzata anche dalla funzione \func{getrusage} (vedi \secref{sec:sys_xxx})
1015 per ottenere le risorse di sistema usate dal processo; la sua definizione è
1016 riportata in \figref{fig:sys_rusage_struct}.
1018 In genere includere esplicitamente \file{<sys/time.h>} non è più
1019 necessario, ma aumenta la portabilità, e serve in caso si debba accedere
1020 ai campi di \var{rusage} definiti come \type{struct timeval}. La
1021 struttura è ripresa da BSD 4.3, attualmente (con il kernel 2.4.x) i soli
1022 campi che sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime},
1023 \var{ru\_minflt}, \var{ru\_majflt}, e \var{ru\_nswap}.
1026 \subsection{Le funzioni \func{exec}}
1027 \label{sec:proc_exec}
1029 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1030 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1031 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1032 processo chiama una di queste funzioni esso viene completamente sostituito dal
1033 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
1034 creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo
1035 heap, i dati ed il testo del processo corrente con un nuovo programma letto da
1038 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1039 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1040 (come mostrato in \figref{fig:proc_exec_relat}), sono tutte un front-end a
1041 \func{execve}. Il prototipo di quest'ultima è:
1042 \begin{prototype}{unistd.h}
1043 {int execve(const char *filename, char *const argv[], char *const envp[])}
1044 Esegue il programma contenuto nel file \param{filename}.
1046 \bodydesc{La funzione ritorna -1 solo in caso di errore, nel qual caso
1047 caso la \var{errno} può assumere i valori:
1049 \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è
1050 montato in \cmd{noexec}, oppure non è un file normale o un interprete.
1051 \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid} ma l'utente non
1052 è root o il filesystem è montato con \cmd{nosuid}, oppure
1053 \item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non
1054 riconosciuto come tale, o compilato per un'altra architettura.
1055 \item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1056 necessari per eseguirlo non esistono.
1057 \item[\macro{ETXTBSY}] L'eseguibile è aperto in scrittura da uno o più
1059 \item[\macro{EINVAL}] L'eseguibile ELF ha più di un segmento
1060 \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un
1062 \item[\macro{ELIBBAD}] Un interprete ELF non è in un formato
1065 ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO},
1066 \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}, \macro{ENOTDIR},
1067 \macro{ENFILE}, \macro{EMFILE}.}
1070 La funzione \func{exec} esegue il file o lo script indicato da
1071 \var{filename}, passandogli la lista di argomenti indicata da \var{argv}
1072 e come ambiente la lista di stringhe indicata da \var{envp}; entrambe le
1073 liste devono essere terminate da un puntatore nullo. I vettori degli
1074 argomenti e dell'ambiente possono essere acceduti dal nuovo programma
1075 quando la sua funzione \func{main} è dichiarata nella forma
1076 \code{main(int argc, char *argv[], char *envp[])}.
1078 Le altre funzioni della famiglia servono per fornire all'utente una serie
1079 possibile di diverse interfacce per la creazione di un nuovo processo. I loro
1083 \funcdecl{int execl(const char *path, const char *arg, ...)}
1084 \funcdecl{int execv(const char *path, char *const argv[])}
1085 \funcdecl{int execle(const char *path, const char *arg, ..., char
1087 \funcdecl{int execlp(const char *file, const char *arg, ...)}
1088 \funcdecl{int execvp(const char *file, char *const argv[])}
1090 Sostituiscono l'immagine corrente del processo con quella indicata nel primo
1091 argomento. I parametri successivi consentono di specificare gli argomenti a
1092 linea di comando e l'ambiente ricevuti dal nuovo processo.
1094 \bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo
1095 -1; nel qual caso \var{errno} andrà ad assumere i valori visti in
1096 precedenza per \func{execve}.}
1099 Per capire meglio le differenze fra le funzioni della famiglia si può fare
1100 riferimento allo specchietto riportato in \ntab. La prima differenza riguarda
1101 le modalità di passaggio dei parametri che poi andranno a costituire gli
1102 argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
1103 dalla funzione \func{main} del programma chiamato).
1105 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
1106 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
1107 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
1108 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
1109 questo vettore \emph{deve} essere terminato da un puntatore nullo.
1111 Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
1112 lista di puntatori, nella forma:
1113 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
1114 char *arg0, char *arg1, ..., char *argn, NULL
1116 che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
1117 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1118 per indicare il nome del file che contiene il programma che verrà eseguito.
1123 \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1125 \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
1126 \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1128 &\func{execl\ }&\func{execlp}&\func{execle}
1129 &\func{execv\ }& \func{execvp}& \func{execve} \\
1132 argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
1133 argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
1135 filename completo &&$\bullet$&&&$\bullet$& \\
1136 ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\
1138 ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
1139 uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1142 \caption{Confronto delle caratteristiche delle varie funzioni della
1143 famiglia \func{exec}.}
1144 \label{tab:proc_exec_scheme}
1147 La seconda differenza fra le funzioni riguarda le modalità con cui si
1148 specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
1149 indicano le due funzioni che replicano il comportamento della shell nello
1150 specificare il comando da eseguire; quando il parametro \var{file} non
1151 contiene una \file{/} esso viene considerato come un nome di programma, e
1152 viene eseguita automaticamente una ricerca fra i file presenti nella lista di
1153 directory specificate dalla variabile di ambiente \var{PATH}. Il file che
1154 viene posto in esecuzione è il primo che viene trovato. Se si ha un errore di
1155 permessi negati (cioè l'esecuzione della sottostante \func{execve} ritorna un
1156 \macro{EACCESS}), la ricerca viene proseguita nelle eventuali ulteriori
1157 directory indicate nel \var{PATH}, solo se non viene trovato nessun altro file
1158 viene finalmente restituito \macro{EACCESS}.
1160 Le altre quattro funzioni si limitano invece a cercare di eseguire il file
1161 indicato dal parametro \var{path}, che viene interpretato come il
1162 \textit{pathname} del programma.
1166 \includegraphics[width=13cm]{img/exec_rel}
1167 \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}}
1168 \label{fig:proc_exec_relat}
1171 La terza differenza è come viene passata la lista delle variabili di ambiente.
1172 Con lo mnemonico \code{e} vengono indicate quelle funzioni che necessitano di
1173 un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti
1174 a riga di comando (terminato quindi da un \macro{NULL}), le altre usano il
1175 valore della variabile \var{environ} (vedi \secref{sec:proc_environ}) del
1176 processo di partenza per costruire l'ambiente.
1178 Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
1179 \func{exec} assume anche una serie di altre proprietà del processo chiamante;
1180 la lista completa è la seguente:
1182 \item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
1184 \item il \textit{real user id} ed il \textit{real group id} (vedi
1185 \secref{sec:proc_access_id}).
1186 \item i \textit{supplementary group id} (vedi \secref{sec:proc_access_id}).
1187 \item il \textit{session id} ed il \textit{process group id} (vedi
1188 \secref{sec:sess_xxx}).
1189 \item il terminale di controllo (vedi \secref{sec:sess_xxx}).
1190 \item il tempo restante ad un allarme (vedi \secref{sec:sig_xxx}).
1191 \item la directory radice e la directory di lavoro corrente (vedi
1192 \secref{sec:file_work_dir}).
1193 \item la maschera di creazione dei file (\var{umask}, vedi
1194 \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
1195 \secref{sec:file_locking}).
1196 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
1197 \secref{sec:sig_xxx}).
1198 \item i limiti sulle risorse (vedi \secref{sec:sys_limits}).
1199 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
1200 \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).
1203 Oltre a questo i segnali che sono stati settati per essere ignorati nel
1204 processo chiamante mantengono lo stesso settaggio pure nel nuovo programma,
1205 tutti gli altri segnali vengono settati alla loro azione di default. Un caso
1206 speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN},
1207 può anche non essere resettato a \macro{SIG\_DFL} (si veda
1208 \secref{sec:sig_xxx}).
1210 La gestione dei file aperti dipende dal valore del flag di
1211 \textit{close-on-exec} per ciascun file descriptor (si veda
1212 \secref{sec:file_fcntl}); i file per cui è settato vengono chiusi, tutti gli
1213 altri file restano aperti. Questo significa che il comportamento di default è
1214 che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
1215 esplicita a \func{fcntl} che setti il suddetto flag.
1217 Per le directory lo standard POSIX.1 richiede che esse vengano chiuse
1218 attraverso una \func{exec}, in genere questo è fatto dalla funzione
1219 \func{opendir} (vedi \secref{sec:file_dir_read}) che effettua da sola il
1220 settaggio del flag di \textit{close-on-exec} sulle directory che apre, in
1221 maniera trasparente all'utente.
1223 Abbiamo detto che il \textit{real user id} ed il \textit{real group id}
1224 restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
1225 l'\textit{effective user id} ed l'\textit{effective group id}, tranne il caso
1226 in cui il file che si va ad eseguire ha o il \acr{suid} bit o lo \acr{sgid}
1227 bit settato, nel qual caso \textit{effective user id} e \textit{effective
1228 group id} vengono settati rispettivamente all'utente o al gruppo cui il file
1229 appartiene (per i dettagli vedi \secref{sec:proc_perms}).
1231 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1232 condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
1233 programma per caricare le librerie necessarie ed effettuare il link
1234 dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
1235 dinamiche viene usato l'interprete indicato nel segmento \macro{PT\_INTERP},
1236 in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
1237 \emph{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
1238 \emph{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
1239 una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
1240 deve esse un valido programma (binario, non un altro script) che verrà
1241 chiamato come se si fosse eseguito il comando \cmd{interpreter [arg]
1244 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1245 basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
1246 processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
1247 \func{wait} si effettua e verifica la conclusione dei programmi. Tutte le
1248 altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari
1249 parametri connessi ai processi.
1253 \section{Il controllo di accesso}
1254 \label{sec:proc_perms}
1256 In questa sezione esamineremo le problematiche relative al controllo di
1257 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
1258 usati, come questi possono essere modificati nella creazione e nel lancio di
1259 nuovi processi, e le varie funzioni per la loro manipolazione diretta e tutte
1260 le problematiche connesse ad una gestione accorta dei privilegi.
1263 \subsection{Gli identificatori del controllo di accesso}
1264 \label{sec:proc_access_id}
1266 Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
1267 realtà già esistono estensioni di questo modello base, che lo rendono più
1268 flessibile e controllabile, come le \textit{capabilities}, le ACL per i file
1269 o il \textit{Mandatory Access Control} di SELinux} di sicurezza di un
1270 sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
1271 separazione fra l'amministratore (\textsl{root}, detto spesso anche
1272 \textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
1273 utenti, per i quali invece vengono effettuati i vari controlli di accesso.
1275 %Benché il sistema sia piuttosto semplice (è basato su un solo livello di
1276 % separazione) il sistema permette una
1277 %notevole flessibilità,
1279 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1280 identificatori univoci, lo \acr{uid} e il \acr{gid}; questi servono al kernel
1281 per identificare uno specifico utente o un gruppo di utenti, per poi poter
1282 controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
1283 esempio in \secref{sec:file_access_control} vedremo come ad ogni file vengano
1284 associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
1285 appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
1286 kernel nella gestione dei permessi di accesso.
1288 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1289 evidente che per poter implementare un controllo sulle operazioni occorre
1290 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1291 anche a ciascun processo è associato un utente e a un gruppo.
1293 Un semplice controllo di una corrispondenza fra identificativi però non
1294 garantisce però sufficiente flessibilità per tutti quei casi in cui è
1295 necessario poter disporre di privilegi diversi, o dover impersonare un altro
1296 utente per un limitato insieme di operazioni. Per questo motivo in generale
1297 tutti gli Unix prevedono che i processi abbiano almeno due gruppi di
1298 identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}.
1303 \begin{tabular}[c]{|c|l|p{6.5cm}|}
1305 \textbf{Suffisso} & \textbf{Significato} & \textbf{Utilizzo} \\
1308 \acr{uid} & \textit{real user id} & indica l'utente che ha lanciato
1310 \acr{gid} & \textit{real group id} & indica il gruppo dell'utente
1311 che ha lanciato il programma \\
1313 \acr{euid} & \textit{effective user id} & indica l'utente usato
1314 dal programma nel controllo di accesso \\
1315 \acr{egid} & \textit{effective group id} & indica il gruppo
1316 usato dal programma nel controllo di accesso \\
1317 -- & \textit{supplementary group id} & indica i gruppi cui
1318 l'utente appartiene \\
1320 -- & \textit{saved user id} & copia dell'\acr{euid} iniziale\\
1321 -- & \textit{saved group id} & copia dell'\acr{egid} iniziale \\
1323 \acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per
1325 \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo
1326 per il filesystem \\
1329 \caption{Identificatori di utente e gruppo associati a ciascun processo con
1330 indicazione dei suffissi usate dalle varie funzioni di manipolazione.}
1331 \label{tab:proc_uid_gid}
1334 Al primo gruppo appartengono il \textit{real user id} e il \textit{real group
1335 id}: questi vengono settati al login ai valori corrispondenti all'utente con
1336 cui si accede al sistema (e relativo gruppo di default). Servono per
1337 l'identificazione dell'utente e normalmente non vengono mai cambiati. In
1338 realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma
1339 solo ad un processo che abbia i privilegi di amministratore; questa
1340 possibilità è usata ad esempio da \cmd{login} che una volta completata la
1341 procedura di autenticazione lancia una shell per la quale setta questi
1342 identificatori ai valori corrispondenti all'utente che entra nel sistema.
1344 Al secondo gruppo appartengono l'\textit{effective user id} e
1345 l'\textit{effective group id} (a cui si aggiungono gli eventuali
1346 \textit{supplementary group id} dei gruppi dei quale l'utente fa parte).
1347 Questi sono invece gli identificatori usati nella verifiche dei permessi del
1348 processo e per il controllo di accesso ai file (argomento affrontato in
1349 dettaglio in \secref{sec:file_perm_overview}).
1351 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1352 \textsl{reale} tranne nel caso in cui, come accennato in
1353 \secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
1354 \acr{suid} o \acr{sgid} settati (il significato di questi bit è affrontato in
1355 dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati
1356 all'utente e al gruppo proprietari del file; questo consente, per programmi in
1357 cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
1358 di un'altro (o dell'amministratore).
1360 Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
1361 possono essere letti dal processo attraverso delle opportune funzioni, i cui
1362 prototipi sono i seguenti:
1365 \headdecl{sys/types.h}
1366 \funcdecl{uid\_t getuid(void)} Restituisce il \textit{real user id} del
1369 \funcdecl{uid\_t geteuid(void)} Restituisce l'\textit{effective user id} del
1372 \funcdecl{gid\_t getgid(void)} Restituisce il \textit{real group id} del
1375 \funcdecl{gid\_t getegid(void)} Restituisce l'\textit{effective group id} del
1378 \bodydesc{Queste funzioni non riportano condizioni di errore.}
1381 In generale l'uso di privilegi superiori deve essere limitato il più
1382 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1383 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1384 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1385 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1388 Questo in Linux viene fatto usando altri due gruppi di identificatori, il
1389 \textit{saved} ed il \textit{filesystem}, analoghi ai precedenti. Il primo
1390 gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è
1391 definita la costante \macro{\_POSIX\_SAVED\_IDS}\footnote{in caso si abbia a
1392 cuore la portabilità del programma su altri Unix è buona norma controllare
1393 sempre la disponibilità di queste funzioni controllando se questa costante è
1394 definita}, il secondo gruppo è specifico di Linux e viene usato per
1395 migliorare la sicurezza con NFS.
1397 Il \textit{saved user id} e il \textit{saved group id} sono copie
1398 dell'\textit{effective user id} e dell'\textit{effective group id} del
1399 processo padre, e vengono settati dalla funzione \func{exec} all'avvio del
1400 processo, come copie dell'\textit{effective user id} e dell'\textit{effective
1401 group id} dopo che questo sono stati settati tenendo conto di eventuali
1402 \acr{suid} o \acr{sgid}. Essi quindi consentono di tenere traccia di quale
1403 fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo
1406 Il \textit{filesystem user id} e il \textit{filesystem group id} sono una
1407 estensione introdotta in Linux per rendere più sicuro l'uso di NFS (torneremo
1408 sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una replica dei
1409 corrispondenti \textit{effective id}, ai quali si sostituiscono per tutte le
1410 operazioni di verifica dei permessi relativi ai file (trattate in
1411 \secref{sec:file_perm_overview}). Ogni cambiamento effettuato sugli
1412 \textit{effective id} viene automaticamente riportato su di essi, per cui in
1413 condizioni normali se ne può tranquillamente ignorare l'esistenza, in quanto
1414 saranno del tutto equivalenti ai precedenti.
1416 Uno specchietto riassuntivo, contenente l'elenco completo degli identificatori
1417 di utente e gruppo associati dal kernel ad ogni processo, è riportato in
1418 \tabref{tab:proc_uid_gid}.
1421 \subsection{Le funzioni \func{setuid} e \func{setgid}}
1422 \label{sec:proc_setuid}
1424 Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
1425 di appartenenza) ad un processo sono rispettivamente \func{setuid} e
1426 \func{setgid}; come accennato in \secref{sec:proc_access_id} in Linux esse
1427 seguono la semantica POSIX che prevede l'esistenza del \textit{saved user id}
1428 e del \textit{saved group id}; i loro prototipi sono:
1431 \headdecl{sys/types.h}
1433 \funcdecl{int setuid(uid\_t uid)} Setta l'\textit{user id} del processo
1436 \funcdecl{int setgid(gid\_t gid)} Setta il \textit{group id} del processo
1439 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1440 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1443 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1444 la prima; la seconda si comporta esattamente allo stesso modo facendo
1445 riferimento al \textit{group id} invece che all'\textit{user id}. Gli
1446 eventuali \textit{supplementary group id} non vengono modificati da nessuna
1447 delle funzioni che tratteremo in questa sezione.
1450 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1451 l'\textit{effective user id} è zero (cioè è quello dell'amministratore di
1452 sistema) allora tutti gli identificatori (\textit{real}, \textit{effective}
1453 e \textit{saved}) vengono settati al valore specificato da \var{uid},
1454 altrimenti viene settato solo l'\textit{effective user id}, e soltanto se il
1455 valore specificato corrisponde o al \textit{real user id} o al \textit{saved
1456 user id}. Negli altri casi viene segnalato un errore (con \macro{EPERM}).
1458 Come accennato l'uso principale di queste funzioni è quello di poter
1459 consentire ad un programma con i bit \acr{suid} o \acr{sgid} settati di
1460 riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il
1461 programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
1462 eventualmente tornare indietro.
1464 Come esempio per chiarire dell'uso di queste funzioni prediamo quello con cui
1465 viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene
1466 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1467 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1468 falsificare la registrazione. Per questo motivo questo file (e l'analogo
1469 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
1470 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
1471 esempio tutti i programmi di terminale in X, o il programma \cmd{screen}
1472 che crea terminali multipli su una console) appartengono a questo gruppo ed
1473 hanno il bit \acr{sgid} settato.
1475 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato la
1476 situazione degli identificatori è la seguente:
1479 \textit{real group id} &=& \textrm{\acr{gid} (del chiamante)} \\
1480 \textit{effective group id} &=& \textrm{\acr{utmp}} \\
1481 \textit{saved group id} &=& \textrm{\acr{utmp}}
1483 in questo modo, dato che l'\textit{effective group id} è quello giusto, il
1484 programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo, a
1485 questo punto il programma può eseguire una \code{setgid(getgid())} per settare
1486 l'\textit{effective group id} a quello dell'utente (e dato che il \textit{real
1487 group id} corrisponde la funzione avrà successo), in questo modo non sarà
1488 possibile lanciare dal terminale programmi che modificano detto file, in tal
1489 caso infatti la situazione degli identificatori sarebbe:
1492 \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\
1493 \textit{effective group id} &=& \textrm{\acr{gid}} \\
1494 \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)}
1496 e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
1497 \textit{effective group id}. All'uscita dal terminale, per poter di nuovo
1498 aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una
1499 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
1500 \acr{utmp}, ottenuto ad esempio con una \func{getegid}), dato che in questo
1501 caso il valore richiesto corrisponde al \textit{saved group id} la funzione
1502 avrà successo e riporterà la situazione a:
1505 \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\
1506 \textit{effective group id} &=& \textrm{\acr{utmp}} \\
1507 \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)}
1509 consentendo l'accesso a \file{/var/log/utmp}.
1511 Occorre però tenere conto che tutto questo non è possibile con un processo con
1512 i privilegi di root, in tal caso infatti l'esecuzione una \func{setuid}
1513 comporta il cambiamento di tutti gli identificatori associati al processo,
1514 rendendo impossibile riguadagnare i privilegi di amministratore. Questo
1515 comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea
1516 una nuova shell per l'utente; ma quando si vuole cambiare soltanto
1517 l'\textit{effective user id} del processo per cedere i privilegi occorre
1518 ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
1521 \subsection{Le funzioni \func{setreuid} e \func{setresuid}}
1522 \label{sec:proc_setreuid}
1524 Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino
1525 alla versione 4.3+BSD TODO, verificare e aggiornare la nota.} i
1526 \textit{saved id}, le usava per poter scambiare fra di loro \textit{effective}
1527 e \textit{real id}. I loro prototipi sono:
1530 \headdecl{sys/types.h}
1532 \funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Setta il \textit{real user
1533 id} e l'\textit{effective user id} del processo corrente ai valori
1534 specificati da \var{ruid} e \var{euid}.
1536 \funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Setta il \textit{real group
1537 id} e l'\textit{effective group id} del processo corrente ai valori
1538 specificati da \var{rgid} e \var{egid}.
1540 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1541 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1544 I processi non privilegiati possono settare i \textit{real id} soltanto ai
1545 valori dei loro \textit{effective id} o \textit{real id} e gli
1546 \textit{effective id} ai valori dei loro \textit{real id}, \textit{effective
1547 id} o \textit{saved id}; valori diversi comportano il fallimento della
1548 chiamata; l'amministratore invece può specificare un valore qualunque.
1549 Specificando un valore di -1 l'identificatore corrispondente viene lasciato
1552 Con queste funzione si possono scambiare fra loro \textit{real id} e
1553 \textit{effective id}, e pertanto è possibile implementare un comportamento
1554 simile a quello visto in precedenza per \func{setgid}, cedendo i privilegi con
1555 un primo scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un
1558 In questo caso però occorre porre molta attenzione quando si creano nuovi
1559 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
1560 questo caso infatti essi avranno un \textit{real id} privilegiato, che dovrà
1561 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
1562 programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork}, e
1563 prima della \func{exec} per uniformare i \textit{real id} agli
1564 \textit{effective id}) in caso contrario quest'ultimo potrebbe a sua volta
1565 effettuare uno scambio e riottenere privilegi non previsti.
1567 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
1568 si porrebbe per i \textit{saved id}: queste funzioni derivano da
1569 un'implementazione che non ne prevede la presenza, e quindi non è possibile
1570 usarle per correggere la situazione come nel caso precedente. Per questo
1571 motivo in Linux tutte le volte che vengono usata per modificare uno degli
1572 identificatori ad un valore diverso dal \textit{real id} precedente, il
1573 \textit{saved id} viene sempre settato al valore dell'\textit{effective id}.
1577 \subsection{Le funzioni \func{seteuid} e \func{setegid}}
1578 \label{sec:proc_seteuid}
1580 Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque
1581 supportate dalla maggior parte degli Unix) e usate per cambiare gli
1582 \textit{effective id}; i loro prototipi sono:
1585 \headdecl{sys/types.h}
1587 \funcdecl{int seteuid(uid\_t uid)} Setta l'\textit{effective user id} del
1588 processo corrente a \var{uid}.
1590 \funcdecl{int setegid(gid\_t gid)} Setta l'\textit{effective group id} del
1591 processo corrente a \var{gid}.
1593 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1594 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1597 Gli utenti normali possono settare l'\textit{effective id} solo al valore del
1598 \textit{real id} o del \textit{saved id}, l'amministratore può specificare
1599 qualunque valore. Queste funzioni sono usate per permettere a root di settare
1600 solo l'\textit{effective id}, dato che l'uso normale di \func{setuid} comporta
1601 il settaggio di tutti gli identificatori.
1604 \subsection{Le funzioni \func{setresuid} e \func{setresgid}}
1605 \label{sec:proc_setresuid}
1607 Queste due funzioni sono una estensione introdotta in Linux dal kernel 2.1.44,
1608 e permettono un completo controllo su tutti gli identificatori (\textit{real},
1609 \textit{effective} e \textit{saved}), i prototipi sono:
1612 \headdecl{sys/types.h}
1614 \funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Setta il
1615 \textit{real user id}, l'\textit{effective user id} e il \textit{saved user
1616 id} del processo corrente ai valori specificati rispettivamente da
1617 \var{ruid}, \var{euid} e \var{suid}.
1619 \funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Setta il
1620 \textit{real group id}, l'\textit{effective group id} e il \textit{saved group
1621 id} del processo corrente ai valori specificati rispettivamente da
1622 \var{rgid}, \var{egid} e \var{sgid}.
1624 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1625 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1628 I processi non privilegiati possono cambiare uno qualunque degli
1629 identificatori usando uno qualunque dei valori correnti di \textit{real id},
1630 \textit{effective id} o \textit{saved id}, l'amministratore può specificare i
1631 valori che vuole; un valore di -1 per un qualunque parametro lascia inalterato
1632 l'identificatore corrispondente.
1634 Per queste funzioni esistono anche due controparti che permettono di leggere
1635 in blocco i vari identificatori: \func{getresuid} e \func{getresgid}; i loro
1639 \headdecl{sys/types.h}
1641 \funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge il
1642 \textit{real user id}, l'\textit{effective user id} e il \textit{saved user
1643 id} del processo corrente.
1645 \funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il
1646 \textit{real group id}, l'\textit{effective group id} e il \textit{saved group
1647 id} del processo corrente.
1649 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
1650 fallimento: l'unico errore possibile è \macro{EFAULT} se gli indirizzi delle
1651 variabili di ritorno non sono validi.}
1654 Anche queste funzioni sono una estensione specifica di Linux, e non richiedono
1655 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
1656 specificati come puntatori (è un'altro esempio di \textit{value result
1657 argument}). Si noti che queste funzioni sono le uniche in grado di leggere i
1661 \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
1662 \label{sec:proc_setfsuid}
1664 Queste funzioni sono usate per settare gli identificatori usati da Linux per
1665 il controllo dell'accesso ai file. Come già accennato in
1666 \secref{sec:proc_access_id} in Linux è definito questo ulteriore gruppo di
1667 identificatori, che di norma sono assolutamente equivalenti agli
1668 \textit{effective id}, dato che ogni cambiamento di questi ultimi viene
1669 immediatamente riportato sui \textit{filesystem id}.
1671 C'è un solo caso in cui si ha necessità di introdurre una differenza fra
1672 \textit{effective id} e \textit{filesystem id}, ed è per ovviare ad un
1673 problema di sicurezza che si presenta quando si deve implementare un server
1674 NFS. Il server NFS infatti deve poter cambiare l'identificatore con cui accede
1675 ai file per assumere l'identità del singolo utente remoto, ma se questo viene
1676 fatto cambiando l'\textit{effective id} o il \textit{real id} il server si
1677 espone alla ricezione di eventuali segnali ostili da parte dell'utente di cui
1678 ha temporaneamente assunto l'identità. Cambiando solo il \textit{filesystem
1679 id} si ottengono i privilegi necessari per accedere ai file, mantenendo
1680 quelli originari per quanto riguarda tutti gli altri controlli di accesso,
1681 così che l'utente non possa inviare segnali al server NFS.
1683 Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid}
1684 e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
1685 usate se si intendono scrivere programmi portabili; i loro prototipi sono:
1687 \headdecl{sys/fsuid.h}
1689 \funcdecl{int setfsuid(uid\_t fsuid)} Setta il \textit{filesystem user id} del
1690 processo corrente a \var{fsuid}.
1692 \funcdecl{int setfsgid(gid\_t fsgid)} Setta l'\textit{filesystem group id} del
1693 processo corrente a \var{fsgid}.
1695 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1696 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1698 \noindent queste funzioni hanno successo solo se il processo chiamante ha i
1699 privilegi di amministratore o, per gli altri utenti, se il valore specificato
1700 coincide con uno dei \textit{real}, \textit{effective} o \textit{saved id}.
1703 \subsection{Le funzioni \func{setgroups} e \func{getgroups}}
1704 \label{sec:proc_setgroups}
1706 Le ultime funzioni che esamineremo sono quelle sono quelle che permettono di
1707 operare sui gruppi supplementari. Ogni processo può avere fino a
1708 \macro{NGROUPS\_MAX} gruppi supplementari in aggiunta al gruppo primario,
1709 questi vengono ereditati dal processo padre e possono essere cambiati con
1712 La funzione che permette di leggere i gruppi supplementari è \func{getgroups};
1713 questa funzione è definita nello standard POSIX ed il suo prototipo è:
1715 \headdecl{sys/types.h}
1718 \funcdecl{int getgroups(int size, gid\_t list[])} Legge gli identificatori
1719 dei gruppi supplementari del processo sul vettore \param{list} di dimensione
1722 \bodydesc{La funzione restituisce il numero di gruppi letti in caso di
1723 successo e -1 in caso di fallimento, nel qual caso \var{errno} viene
1726 \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1727 \item[\macro{EINVAL}] il valore di \param{size} è diverso da zero ma
1728 minore del numero di gruppi supplementari del processo.
1731 \noindent non è specificato se la funzione inserisca o meno nella lista
1732 l'\textit{effective user id} del processo. Se si specifica un valore di
1733 \param{size} uguale a 0 \param{list} non viene modificato, ma si ottiene il
1734 numero di gruppi supplementari.
1736 Una seconda funzione, \func{getgrouplist}, può invece essere usata per
1737 ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo è:
1739 \headdecl{sys/types.h}
1742 \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups,
1743 int *ngroups)} Legge i gruppi supplementari dell'utente \param{user}.
1745 \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori,
1746 restituisce 0 in caso di successo e -1 in caso di fallimento.}
1748 \noindent la funzione esegue una scansione del database dei gruppi (si veda
1749 \secref{sec:sys_xxx}) e ritorna in \param{groups} la lista di quelli a cui
1750 l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore
1751 perché qualora il valore specificato sia troppo piccolo la funzione ritorna -1
1752 e passando indietro il numero dei gruppi trovati.
1754 Per settare i gruppi supplementari di un processo ci sono due funzioni, che
1755 possono essere usate solo se si hanno i privilegi di amministratore. La prima
1756 delle due è \func{setgroups}, ed il suo prototipo è:
1758 \headdecl{sys/types.h}
1761 \funcdecl{int setgroups(size\_t size, gid\_t *list)} Setta i gruppi
1762 supplementari del processo ai valori specificati in \param{list}.
1764 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1765 fallimento, nel qual caso \var{errno} viene settata a:
1767 \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1768 \item[\macro{EPERM}] il processo non ha i privilegi di amministratore.
1769 \item[\macro{EINVAL}] il valore di \param{size} è maggiore del valore
1770 massimo (\macro{NGROUPS}, che per Linux è 32).
1774 Se invece si vogliono settare i gruppi supplementari del processo a quelli di
1775 un utente specifico si può usare \func{initgroups} il cui prototipo è:
1777 \headdecl{sys/types.h}
1780 \funcdecl{int initgroups(const char *user, gid\_t group)} Setta i gruppi
1781 supplementari del processo a quelli di cui è membro l'utente \param{user},
1782 aggiungendo il gruppo addizionale \param{group}.
1784 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1785 fallimento, nel qual caso \var{errno} viene settata agli stessi valori di
1786 \func{setgroups} più \macro{ENOMEM} quando non c'è memoria sufficiente per
1787 allocare lo spazio per informazioni dei gruppi.}
1790 La funzione esegue la scansione del database dei gruppi (usualmente
1791 \file{/etc/groups}) cercando i gruppi di cui è membro \param{user} costruendo
1792 una lista di gruppi supplementari a cui aggiunge \param{group}, che poi setta
1793 usando \func{setgroups}.
1795 Si tenga presente che sia \func{setgroups} che \func{initgroups} non sono
1796 definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle
1797 quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
1801 \section{La gestione della priorità di esecuzione}
1802 \label{sec:proc_priority}
1804 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
1805 lo \textit{scheduler} assegna la CPU ai vari processi attivi, illustrando le
1806 varie funzioni che permettono di leggere e modificare le priorità di
1807 esecuzione dei programmi.
1813 \section{Problematiche di programmazione multitasking}
1814 \label{sec:proc_multi_prog}
1816 Benché i processi siano strutturati in modo da apparire il più possibile come
1817 indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
1818 occorre tenere conto di una serie di problematiche che normalmente non
1819 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
1820 programma alla volta.
1822 Pur essendo questo argomento di carattere generale, in questa sezione
1823 conclusiva del capitolo in cui abbiamo affrontato la gestione dei processi ci
1824 è parso opportuno introdurre sinteticamente queste problematiche, che
1825 ritroveremo a più riprese in capitoli successivi, dando una breve descrizione
1826 delle loro caratteristiche principali e della terminologia relativa.
1829 \subsection{Le operazioni atomiche}
1830 \label{sec:proc_atom_oper}
1832 La nozione di \textsl{operazione atomica} deriva dal significato greco della
1833 parola atomo, cioè indivisibile; si dice infatti che una operazione è atomica
1834 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
1835 che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
1836 di interruzione in una fase intermedia.
1838 In un ambiente multitasking il concetto è essenziale, dato che un processo può
1839 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
1840 altro processo o dalla ricezione di un segnale; occorre pertanto essere
1841 accorti nei confronti delle possibili \textit{race condition} (vedi
1842 \secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in
1843 cui non erano ancora state completate.
1845 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
1846 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
1847 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
1848 \capref{cha:IPC}) o nella operazioni con i file (vedremo alcuni esempi in
1849 \secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
1850 funzioni di libreria per compiere le operazioni necessarie è garanzia
1851 sufficiente di atomicità in quanto le system call con cui esse sono realizzate
1852 non possono essere interrotte (o subire interferenze pericolose) da altri
1855 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
1856 stesso processo, e pure alcune system call, possono essere interrotti in
1857 qualunque momento, e le operazioni di un eventuale \textit{signal handler}
1858 sono compiute nello stesso spazio di indirizzi del processo. Per questo anche
1859 il solo accesso o l'assegnazione di una variabile possono non essere più
1860 operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}).
1862 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
1863 il cui accesso è assicurato essere atomico. In pratica comunque si può
1864 assumere che in ogni piattaforma su cui è implementato Linux il tipo
1865 \type{int} (e gli altri interi di dimensione inferiore) ed i puntatori sono
1866 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
1867 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
1868 le strutture. In questi casi è anche opportuno marcare come \type{volatile} le
1869 variabili che possono essere interessate ad accesso condiviso, onde evitare
1870 problemi con le ottimizzazioni del codice.
1873 \subsection{Le \textit{race condition} e i \textit{deadlock}}
1874 \label{sec:proc_race_cond}
1876 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
1877 diversi operano su una risorsa comune, ed in cui il risultato viene a
1878 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
1879 tipico è quella di una operazione che viene eseguita da un processo in più
1880 passi, e può essere compromessa dall'intervento di un altro processo che
1881 accede alla stessa risorsa quando ancora non tutti i passi sono stati
1884 Dato che in un sistema multitasking ogni processo può essere interrotto in
1885 qualunque momento per farne subentrare un'altro in esecuzione, niente può
1886 assicurare un preciso ordine di esecuzione fra processi diversi o che una
1887 sezione di un programma possa essere eseguita senza interruzioni da parte di
1888 altri. Queste situazioni comportano pertanto errori estremamente subdoli e
1889 difficili da tracciare, in quanto nella maggior parte dei casi tutto
1890 funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
1892 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
1893 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
1894 gli adeguati provvedimenti per far si che non si verifichino. Casi tipici di
1895 \textit{race condition} si hanno quando diversi processi accedono allo stesso
1896 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
1897 condivisa. In questi casi, se non si dispone della possibilità di eseguire
1898 atomicamente le operazioni necessarie, occorre che quelle parti di codice in
1899 cui si compiono le operazioni critiche sulle risorse condivise, le cosiddette
1900 \textsl{sezioni critiche} del programma, siano opportunamente protette da
1901 meccanismi di sincronizzazione (torneremo su queste problematiche di questo
1902 tipo in \secref{sec:ipc_semaph}).
1904 Un caso particolare di \textit{race condition} sono poi i cosiddetti
1905 \textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
1906 completo di un servizio, e non il fallimento di una singola operazione.
1907 L'esempio tipico di una situazione che può condurre ad un \textit{deadlock} è
1908 quello in cui un flag di ``occupazione'' viene rilasciato da un evento
1909 asincrono (come un segnale o un altro processo) fra il momento in cui lo si è
1910 controllato (trovandolo occupato) e la successiva operazione di attesa per lo
1911 sblocco. In questo caso, dato che l'evento di sblocco del flag è avvenuto
1912 senza che ce ne accorgessimo proprio fra il controllo e la messa in attesa,
1913 quest'ultima diventerà perpetua (da cui il nome di \textit{deadlock}).
1915 In tutti questi casi è di fondamentale importanza il concetto di atomicità
1916 visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere
1917 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
1918 eseguire in maniera atomica le operazioni necessarie, proteggendo con gli
1919 adeguati meccanismi le \textsl{sezioni critiche} del programma.
1922 \subsection{Le funzioni rientranti}
1923 \label{sec:proc_reentrant}
1925 Si dice \textsl{rientrante} una funzione che può essere interrotta in
1926 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
1927 un altro thread di esecuzione senza che questo comporti nessun problema nella
1928 esecuzione della stessa. La problematica è comune nella programmazione
1929 multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare
1930 delle funzioni all'interno dei manipolatori dei segnali.
1932 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
1933 queste infatti vengono tutte le volte allocate nello stack, e un'altra
1934 invocazione non fa altro che allocarne un'altra copia. Una funzione può non
1935 essere rientrante quando opera su memoria che non è nello stack. Ad esempio
1936 una funzione non è mai rientrante se usa una variabile globale o statica.
1938 Nel caso invece la funzione operi su un oggetto allocato dinamicamente la cosa
1939 viene a dipendere da come avvengono le operazioni; se l'oggetto è creato ogni
1940 volta e ritornato indietro la funzione può essere rientrante, se invece esso
1941 viene individuato dalla funzione stessa due chiamate alla stessa funzione
1942 potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
1943 Allo stesso modo una funzione può non essere rientrante se usa e modifica un
1944 oggetto che le viene fornito dal chiamante: due chiamate possono interferire
1945 se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
1946 parte del programmatore.
1948 In genere le funzioni di libreria non sono rientranti, molte di esse ad
1949 esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
1950 disposizione due macro di compilatore, \macro{\_REENTRANT} e
1951 \macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
1952 varie funzioni di libreria, che sono identificate aggiungendo il suffisso
1953 \code{\_r} al nome della versione normale.
1957 %%% Local Variables:
1959 %%% TeX-master: "gapil"