1 \chapter{La gestione dei processi}
2 \label{cha:process_handling}
4 Come accennato nell'introduzione in un sistema Unix tutte le operazioni
5 vengono svolte tramite opportuni processi. In sostanza questi ultimi vengono
6 a costituire l'unità 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 terminazione dei processi, della gestione dei loro attributi e
12 privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione
13 finale introdurremo alcune problematiche generiche della programmazione in
14 ambiente multitasking.
17 \section{Introduzione}
20 Inizieremo con un'introduzione generale ai concetti che stanno alla base della
21 gestione dei processi in un sistema unix-like. Introdurremo in questa sezione
22 l'architettura della gestione dei processi e le sue principali
23 caratteristiche, dando una panoramica sull'uso delle principali funzioni di
27 \subsection{L'architettura della gestione dei processi}
28 \label{sec:proc_hierarchy}
30 A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
31 generazione di nuovi processi è un'operazione privilegiata) una delle
32 caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
33 qualunque processo può a sua volta generarne altri, detti processi figli
34 (\textit{child process}). Ogni processo è identificato presso il sistema da un
35 numero unico, il cosiddetto \textit{process identifier} o, più brevemente,
38 Una seconda caratteristica di un sistema Unix è che la generazione di un
39 processo è un'operazione separata rispetto al lancio di un programma. In
40 genere la sequenza è sempre quella di creare un nuovo processo, il quale
41 eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
42 quello che fa la shell quando mette in esecuzione il programma che gli
43 indichiamo nella linea di comando.
45 Una terza caratteristica è che ogni processo è sempre stato generato da un
46 altro, che viene chiamato processo padre (\textit{parent process}). Questo
47 vale per tutti i processi, con una sola eccezione: dato che ci deve essere un
48 punto di partenza esiste un processo speciale (che normalmente è
49 \cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
50 di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
51 \acr{pid} uguale a 1 e non è figlio di nessun altro processo.
53 Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
54 partire tutti gli altri processi necessari al funzionamento del sistema,
55 inoltre \cmd{init} è essenziale per svolgere una serie di compiti
56 amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
57 essi in \secref{sec:proc_termination}) e non può mai essere terminato. La
58 struttura del sistema comunque consente di lanciare al posto di \cmd{init}
59 qualunque altro programma, e in casi di emergenza (ad esempio se il file di
60 \cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
61 posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
66 [piccardi@gont piccardi]$ pstree -n
83 |-bash---startx---xinit-+-XFree86
84 | `-WindowMaker-+-ssh-agent
92 | |-wterm---bash---pstree
93 | `-wterm---bash-+-emacs
99 \caption{L'albero dei processi, così come riportato dal comando
101 \label{fig:proc_tree}
104 Dato che tutti i processi attivi nel sistema sono comunque generati da
105 \cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
106 vero, in Linux ci sono alcuni processi che pur comparendo come figli di
107 init, o con \acr{pid} successivi, sono in realtà generati direttamente dal
108 kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.)} si possono classificare i
109 processi con la relazione padre/figlio in un'organizzazione gerarchica ad
110 albero, in maniera analoga a come i file sono organizzati in un albero di
111 directory (si veda \secref{sec:file_organization}); in \curfig\ si è mostrato
112 il risultato del comando \cmd{pstree} che permette di visualizzare questa
113 struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
117 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
118 \textit{process table}; per ciascun processo viene mantenuta una voce nella
119 tabella dei processi costituita da una struttura \type{task\_struct}, che
120 contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
121 usate a questo scopo sono dichiarate nell'header file \file{linux/sched.h}, ed
122 uno schema semplificato che riporta la struttura delle principali informazioni
123 contenute nella \type{task\_struct} (che in seguito incontreremo a più
124 riprese), è mostrato in \nfig.
128 \includegraphics[width=13cm]{img/task_struct}
129 \caption{Schema semplificato dell'architettura delle strutture usate dal
130 kernel nella gestione dei processi.}
131 \label{fig:proc_task_struct}
135 Come accennato in \secref{sec:intro_unix_struct} è lo \textit{scheduler} che
136 decide quale processo mettere in esecuzione; esso viene eseguito ad ogni
137 system call ed ad ogni interrupt, (ma può essere anche attivato
138 esplicitamente). Il timer di sistema provvede comunque a che esso sia invocato
139 periodicamente, generando un interrupt periodico secondo la frequenza
140 specificata dalla costante \macro{HZ}, definita in \file{asm/param.h} Il
141 valore usuale è 100 (è espresso in Hertz), si ha cioè un interrupt dal timer
142 ogni centesimo di secondo.
144 Ogni volta che viene eseguito, lo \textit{scheduler} effettua il calcolo delle
145 priorità dei vari processi attivi (torneremo su questo in
146 \secref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
147 esecuzione fino alla successiva invocazione.
150 \subsection{Una panoramica sulle funzioni fondamentali}
151 \label{sec:proc_handling_intro}
153 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
154 una system call, Linux però usa un'altra nomenclatura, e la funzione
155 \func{fork} è basata a sua volta sulla system call \func{\_\_clone}, che viene
156 usata anche per generare i \textit{thread}. Il processo figlio creato dalla
157 \func{fork} è una copia identica del processo processo padre, ma ha nuovo
158 \acr{pid} e viene eseguito in maniera indipendente (le differenze fra padre e
159 figlio sono affrontate in dettaglio in \secref{sec:proc_fork}).
161 Se si vuole che il processo padre si fermi fino alla conclusione del processo
162 figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
163 funzione \func{wait} o la funzione \func{waitpid} (si veda
164 \secref{sec:proc_wait}); queste funzioni restituiscono anche un'informazione
165 abbastanza limitata sulle cause della terminazione del processo figlio.
167 Quando un processo ha concluso il suo compito o ha incontrato un errore non
168 risolvibile esso può essere terminato con la funzione \func{exit} (si veda
169 quanto discusso in \secref{sec:proc_conclusion}). La vita del processo però
170 termina solo quando la notifica della sua conclusione viene ricevuta dal
171 processo padre, a quel punto tutte le risorse allocate nel sistema ad esso
172 associate vengono rilasciate.
174 Avere due processi che eseguono esattamente lo stesso codice non è molto
175 utile, normalmente si genera un secondo processo per affidargli l'esecuzione
176 di un compito specifico (ad esempio gestire una connessione dopo che questa è
177 stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
178 quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
179 coi processi che è la \func{exec}.
181 Il programma che un processo sta eseguendo si chiama immagine del processo (o
182 \textit{process image}), le funzioni della famiglia \func{exec} permettono di
183 caricare un'altro programma da disco sostituendo quest'ultimo all'immagine
184 corrente; questo fa sì che l'immagine precedente venga completamente
185 cancellata. Questo significa che quando il nuovo programma esce, anche il
186 processo termina, e non si può tornare alla precedente immagine.
188 Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
189 particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
190 prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
191 non ritorna mai (in quanto con essa viene eseguito un altro programma).
195 \section{Le funzioni di base}% della gestione dei processi}
196 \label{sec:proc_handling}
198 In questa sezione tratteremo le problematiche della gestione dei processi
199 all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con le
200 funzioni elementari che permettono di leggerne gli identificatori, per poi
201 passare alla spiegazione delle funzioni base che si usano per la creazione e
202 la terminazione dei processi, e per la messa in esecuzione degli altri
206 \subsection{Gli identificatori dei processi}
209 Come accennato nell'introduzione, ogni processo viene identificato dal sistema
210 da un numero identificativo unico, il \textit{process id} o \acr{pid};
211 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
212 intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
215 Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
216 processo viene creato, fino ad un limite massimo (in genere essendo detto
217 numero memorizzato in un intero a 16 bit si arriva a 32767) oltre il quale si
218 riparte dal numero più basso disponibile\footnote{FIXME: verificare, non sono
219 sicuro}. Per questo motivo, come visto in \secref{sec:proc_hierarchy}, il
220 processo di avvio (\cmd{init}) ha sempre il \acr{pid} uguale a uno.
222 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
223 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
224 \textit{parent process id}). Questi due identificativi possono essere
225 ottenuti da programma usando le funzioni:
227 \headdecl{sys/types.h}
229 \funcdecl{pid\_t getpid(void)} Restituisce il pid del processo corrente.
230 \funcdecl{pid\_t getppid(void)} Restituisce il pid del padre del processo
233 \bodydesc{Entrambe le funzioni non riportano condizioni di errore.}
235 \noindent esempi dell'uso di queste funzioni sono riportati in
236 \figref{fig:proc_fork_code}, nel programma di esempio \file{ForkTest.c}.
238 Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
239 candidato per generare ulteriori indicatori associati al processo di cui
240 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
241 funzione \func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid}
242 per generare un pathname univoco, che non potrà essere replicato da un'altro
243 processo che usi la stessa funzione.
245 Tutti i processi figli dello stesso processo padre sono detti
246 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
247 sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
248 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
249 \secref{cha:session}, dove esamineremo gli altri identificativi associati ad
250 un processo e le varie relazioni fra processi utilizzate per definire una
253 Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
254 \secref{sec:sess_xxx}, relativi al controllo di sessione), ad ogni processo
255 vengono associati degli altri identificatori che vengono usati per il
256 controllo di accesso. Questi servono per determinare se un processo può
257 eseguire o meno le operazioni richieste, a seconda dei privilegi e
258 dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
259 affrontato in dettaglio in \secref{sec:proc_perms}.
262 \subsection{La funzione \func{fork}}
263 \label{sec:proc_fork}
265 La funzione \func{fork} è la funzione fondamentale della gestione dei
266 processi: come si è detto l'unico modo di creare un nuovo processo è
267 attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale
268 tutte le volte che si devono scrivere programmi che usano il multitasking. Il
269 prototipo della funzione è:
271 \headdecl{sys/types.h}
273 \funcdecl{pid\_t fork(void)}
274 Crea un nuovo processo.
276 \bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
277 zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
278 errore; \var{errno} può assumere i valori:
280 \item[\macro{EAGAIN}] non ci sono risorse sufficienti per creare un'altro
281 processo (per allocare la tabella delle pagine e le strutture del task) o
282 si è esaurito il numero di processi disponibili.
283 \item[\macro{ENOMEM}] non è stato possibile allocare la memoria per le
284 strutture necessarie al kernel per creare il nuovo processo.
288 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
289 il processo figlio continuano ad essere eseguiti normalmente all'istruzione
290 seguente la \func{fork}; il processo figlio è però una copia del padre, e
291 riceve una copia dei segmenti di testo, stack e dati (vedi
292 \secref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
293 padre. Si tenga presente però che la memoria è copiata, non condivisa,
294 pertanto padre e figlio vedono variabili diverse.
296 Per quanto riguarda la gestione della memoria in generale il segmento di
297 testo, che è identico, è condiviso e tenuto in read-only per il padre e per i
298 figli. Per gli altri segmenti Linux utilizza la tecnica del \textit{copy on
299 write}\index{copy on write}; questa tecnica comporta che una pagina di
300 memoria viene effettivamente copiata per il nuovo processo solo quando ci
301 viene effettuata sopra una scrittura (e si ha quindi una reale differenza fra
302 padre e figlio). In questo modo si rende molto più efficiente il meccanismo
303 della creazione di un nuovo processo, non essendo più necessaria la copia di
304 tutto lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di
305 memoria che sono state modificate, e solo al momento della modifica stessa.
307 La differenza che si ha nei due processi è che nel processo padre il valore di
308 ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
309 nel figlio è zero; in questo modo il programma può identificare se viene
310 eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
311 \textbf{due} volte: una nel padre e una nel figlio.
313 La scelta di questi valori di ritorno non è casuale, un processo infatti può
314 avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
315 permette di identificare quello appena creato; al contrario un figlio ha
316 sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
317 \func{getppid}, vedi \secref{sec:proc_pid}) per cui si usa il valore nullo,
318 che non è il \acr{pid} di nessun processo.
323 #include <errno.h> /* error definitions and routines */
324 #include <stdlib.h> /* C standard library */
325 #include <unistd.h> /* unix standard library */
326 #include <stdio.h> /* standard I/O library */
327 #include <string.h> /* string functions */
329 /* Help printing routine */
332 int main(int argc, char *argv[])
335 * Variables definition
342 ... /* handling options */
343 nchild = atoi(argv[optind]);
344 printf("Test for forking %d child\n", nchild);
345 /* loop to fork children */
346 for (i=0; i<nchild; i++) {
347 if ( (pid = fork()) < 0) {
349 printf("Error on %d child creation, %s\n", i+1, strerror(errno));
352 if (pid == 0) { /* child */
353 printf("Child %d successfully executing\n", ++i);
354 if (wait_child) sleep(wait_child);
355 printf("Child %d, parent %d, exiting\n", i, getppid());
357 } else { /* parent */
358 printf("Spawned %d child, pid %d \n", i+1, pid);
359 if (wait_parent) sleep(wait_parent);
360 printf("Go to next child \n");
364 if (wait_end) sleep(wait_end);
368 \caption{Esempio di codice per la creazione di nuovi processi.}
369 \label{fig:proc_fork_code}
372 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
373 sono già troppi processi nel sistema (il che di solito è sintomo che
374 qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
375 sul numero totale di processi permessi all'utente (vedi \secref{sec:sys_xxx}).
377 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
378 quella in cui all'interno di un programma si creano processi figli cui viene
379 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
380 ne esegue un'altra. È il caso tipico dei server di rete in cui il padre riceve
381 ed accetta le richieste da parte dei client, per ciascuna delle quali pone in
382 esecuzione un figlio che è incaricato di fornire il servizio.
384 La seconda modalità è quella in cui il processo vuole eseguire un altro
385 programma; questo è ad esempio il caso della shell. In questo caso il processo
386 crea un figlio la cui unica operazione è quella fare una \func{exec} (di cui
387 parleremo in \secref{sec:proc_exec}) subito dopo la \func{fork}.
389 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
390 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
391 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
392 scelto di mantenere questa separazione, dato che, come per la prima modalità
393 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
394 aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
395 seconda modalità d'uso, avere le due funzioni separate permette al figlio di
396 cambiare gli attributi del processo (maschera dei segnali, redirezione
397 dell'output, \textit{user id}) prima della \func{exec}, rendendo così
398 relativamente facile intervenire sulle le modalità di esecuzione del nuovo
401 In \curfig\ si è riportato il corpo del codice del programma di esempio
402 \cmd{forktest}, che ci permette di illustrare molte caratteristiche dell'uso
403 della funzione \func{fork}. Il programma permette di creare un numero di figli
404 specificato da linea di comando, e prende anche alcune opzioni per indicare
405 degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
406 \func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
407 descrizione delle opzioni); il codice completo, compresa la parte che gestisce
408 le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
409 distribuito insieme agli altri sorgenti degli esempi su
410 \href{http://firenze.linux.it/~piccardi/gapil_source.tgz}
411 {\texttt{http://firenze.linux.it/\~~\hspace{-2.0mm}piccardi/gapil\_source.tgz}}.
413 Decifrato il numero di figli da creare, il ciclo principale del programma
414 (\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
415 controllando il successo della chiamata a \func{fork} (\texttt{\small
416 25--29}); ciascun figlio (\texttt{\small 31--34}) si limita a stampare il
417 suo numero di successione, eventualmente attendere il numero di secondi
418 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
419 (\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
420 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
421 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
424 Se eseguiamo il comando senza specificare attese (come si può notare in
425 \texttt{\small 17--19} i valori di default specificano di non attendere),
426 otterremo come output sul terminale:
430 [piccardi@selidor sources]$ ./forktest 3
431 Process 1963: forking 3 child
432 Spawned 1 child, pid 1964
433 Child 1 successfully executing
434 Child 1, parent 1963, exiting
436 Spawned 2 child, pid 1965
437 Child 2 successfully executing
438 Child 2, parent 1963, exiting
440 Child 3 successfully executing
441 Child 3, parent 1963, exiting
442 Spawned 3 child, pid 1966
447 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
448 si può dire quale processo fra il padre ed il figlio venga eseguito per
449 primo\footnote{a partire dal kernel 2.5.2-pre10 è stato introdotto il nuovo
450 scheduler di Ingo Molnar che esegue sempre per primo il figlio; per
451 mantenere la portabilità è opportuno non fare comunque affidamento su questo
452 comportamento} dopo la chiamata a \func{fork}; dall'esempio si può notare
453 infatti come nei primi due cicli sia stato eseguito per primo il padre (con la
454 stampa del \acr{pid} del nuovo processo) per poi passare all'esecuzione del
455 figlio (completata con i due avvisi di esecuzione ed uscita), e tornare
456 all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
457 mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
460 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
461 scheduling usato dal kernel, dalla particolare situazione in si trova la
462 macchina al momento della chiamata, risultando del tutto impredicibile.
463 Eseguendo più volte il programma di prova e producendo un numero diverso di
464 figli, si sono ottenute situazioni completamente diverse, compreso il caso in
465 cui il processo padre ha eseguito più di una \func{fork} prima che uno dei
466 figli venisse messo in esecuzione.
468 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
469 istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
470 essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
471 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
472 rischio di incorrere nelle cosiddette \textit{race condition} \index{race
473 condition} (vedi \secref{sec:proc_race_cond}.
475 Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
476 processi completamente separati, le modifiche delle variabili nei processi
477 figli (come l'incremento di \var{i} in \texttt{\small 31}) sono visibili solo
478 a loro (ogni processo vede solo la propria copia della memoria), e non hanno
479 alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed
480 in eventuali altri processi figli che eseguano lo stesso codice).
482 Un secondo aspetto molto importante nella creazione dei processi figli è
483 quello dell'interazione dei vari processi con i file; per illustrarlo meglio
484 proviamo a redirigere su un file l'output del nostro programma di test, quello
489 [piccardi@selidor sources]$ ./forktest 3 > output
490 [piccardi@selidor sources]$ cat output
491 Process 1967: forking 3 child
492 Child 1 successfully executing
493 Child 1, parent 1967, exiting
494 Test for forking 3 child
495 Spawned 1 child, pid 1968
497 Child 2 successfully executing
498 Child 2, parent 1967, exiting
499 Test for forking 3 child
500 Spawned 1 child, pid 1968
502 Spawned 2 child, pid 1969
504 Child 3 successfully executing
505 Child 3, parent 1967, exiting
506 Test for forking 3 child
507 Spawned 1 child, pid 1968
509 Spawned 2 child, pid 1969
511 Spawned 3 child, pid 1970
515 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
517 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
518 in gran dettaglio in \capref{cha:file_unix_interface} e in
519 \secref{cha:files_std_interface}. Qui basta accennare che si sono usate le
520 funzioni standard della libreria del C che prevedono l'output bufferizzato; e
521 questa bufferizzazione (trattata in dettaglio in \secref{sec:file_buffering})
522 varia a seconda che si tratti di un file su disco (in cui il buffer viene
523 scaricato su disco solo quando necessario) o di un terminale (nel qual caso il
524 buffer viene scaricato ad ogni carattere di a capo).
526 Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
527 buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
528 l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
529 non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
530 ogni figlio riceve una copia della memoria del padre, esso riceverà anche
531 quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
532 padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
533 figlio, troveremo nel file anche tutto quello che il processo padre aveva
534 scritto prima della sua creazione. E alla fine del file (dato che in questo
535 caso il padre esce per ultimo) troveremo anche l'output completo del padre.
537 L'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i file,
538 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
539 solo processi diversi possono scrivere in contemporanea sullo stesso file
540 (l'argomento della condivisione dei file è trattato in dettaglio in
541 \secref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
542 le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
545 Quello che succede è che quando lo standard output del padre viene rediretto,
546 lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha
547 la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione
548 \func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file
549 descriptor aperti nel padre, il che comporta che padre e figli condividono le
550 stesse voci della \textit{file table} (per la spiegazione di questi termini si
551 veda \secref{sec:file_sharing}) e fra cui c'è anche la posizione corrente nel
554 In questo modo se un processo scrive sul file aggiornerà la posizione corrente
555 sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
556 \textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
557 casi come quello appena mostrato in cui diversi processi scrivono sullo stesso
558 file, che l'output successivo di un processo vada a sovrapporsi a quello dei
559 precedenti: l'output potrà risultare mescolato, ma non ci saranno parti
560 perdute per via di una sovrascrittura.
562 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
563 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
564 scrivono sullo stesso file (un caso tipico è la shell quando lancia un
565 programma, il cui output va sullo standard output).
567 In questo modo, anche se l'output viene rediretto, il padre potrà sempre
568 continuare a scrivere in coda a quanto scritto dal figlio in maniera
569 automatica; se così non fosse ottenere questo comportamento sarebbe
570 estremamente complesso necessitando di una qualche forma di comunicazione fra
571 i due processi per far riprendere al padre la scrittura al punto giusto.
573 In generale comunque non è buona norma far scrivere più processi sullo stesso
574 file senza una qualche forma di sincronizzazione in quanto, come visto anche
575 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
576 una sequenza impredicibile. Per questo le modalità con cui in genere si usano
577 i file dopo una \func{fork} sono sostanzialmente due:
579 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
580 è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
581 della posizione corrente dopo eventuali operazioni di lettura e scrittura
582 effettuate dal figlio è automatica.
583 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
584 ciascuno dei due processi deve chiudere i file che non gli servono una volta
585 che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
588 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
589 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
590 comune dopo l'esecuzione di una \func{fork} è la seguente:
592 \item i file aperti e gli eventuali flag di \textit{close-on-exec} settati
593 (vedi \secref{sec:proc_exec} e \secref{sec:file_fcntl}).
594 \item gli identificatori per il controllo di accesso: il \textit{real user
595 id}, il \textit{real group id}, l'\textit{effective user id},
596 l'\textit{effective group id} ed i \textit{supplementary group id} (vedi
597 \secref{sec:proc_access_id}).
598 \item gli identificatori per il controllo di sessione: il \textit{process
599 group id} e il \textit{session id} ed il terminale di controllo (vedi
600 \secref{sec:sess_xxx} e \secref{sec:sess_xxx}).
601 \item la directory di lavoro e la directory radice (vedi
602 \secref{sec:file_work_dir} e \secref{sec:file_chroot}).
603 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
604 \item la maschera dei segnali bloccati (vedi \secref{sec:sig_sigpending}) e le
605 azioni installate (vedi \secref{sec:sig_gen_beha}).
606 \item i segmenti di memoria condivisa agganciati al processo (vedi
607 \secref{sec:ipc_xxx}).
608 \item i limiti sulle risorse (vedi \secref{sec:sys_xxx}).
609 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
611 le differenze fra padre e figlio dopo la \func{fork} invece sono:
613 \item il valore di ritorno di \func{fork}.
614 \item il \textit{process id}.
615 \item il \textit{parent process id} (quello del figlio viene settato al
616 \acr{pid} del padre).
617 \item i valori dei tempi di esecuzione (vedi \secref{sec:sys_xxx}) che
618 nel figlio sono posti a zero.
619 \item i \textit{file lock} (vedi \secref{sec:file_locking}), che non
620 vengono ereditati dal figlio.
621 \item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_gen_beha}), che
622 per il figlio vengono cancellati.
626 \subsection{La funzione \func{vfork}}
627 \label{sec:proc_vfork}
629 La funzione \func{vfork} è esattamente identica a \func{fork} ed ha la stessa
630 semantica e gli stessi errori; la sola differenza è che non viene creata la
631 tabella delle pagine né la struttura dei task per il nuovo processo. Il
632 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
633 \func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
634 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
635 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
637 Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
638 \func{fork} comportava anche la copia completa del segmento dati del processo
639 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
640 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
641 venne introdotta in BSD per migliorare le prestazioni.
643 Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è
644 assolutamente trascurabile, e l'uso di questa funzione (che resta un caso
645 speciale della funzione \func{clone}), è deprecato; per questo eviteremo di
646 trattarla ulteriormente.
649 \subsection{La conclusione di un processo.}
650 \label{sec:proc_termination}
652 In \secref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
653 chiudere un programma, ma dall'interno del programma stesso; avendo a che fare
654 con un sistema multitasking resta da affrontare l'argomento dal punto di vista
655 di come il sistema gestisce la conclusione dei processi.
657 Abbiamo visto in \secref{sec:proc_conclusion} le tre modalità con cui un
658 programma viene terminato in maniera normale: la chiamata di \func{exit} (che
659 esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
660 dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
661 chiamata ad \func{\_exit} (che passa direttamente alle operazioni di
662 terminazione del processo da parte del kernel).
664 Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
665 modalità di conclusione anomala; queste sono in sostanza due: il programma può
666 chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
667 terminato da un segnale. In realtà anche la prima modalità si riconduce alla
668 seconda, dato che \func{abort} si limita a generare il segnale
671 Qualunque sia la modalità di conclusione di un processo, il kernel esegue
672 comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
673 memoria che stava usando, e così via; l'elenco completo delle operazioni
674 eseguite alla chiusura di un processo è il seguente:
676 \item tutti i file descriptor sono chiusi.
677 \item viene memorizzato lo stato di terminazione del processo.
678 \item ad ogni processo figlio viene assegnato un nuovo padre (in genere
680 \item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi
681 \secref{sec:sig_xxx}).
682 \item se il processo è un leader di sessione viene mandato un segnale di
683 \macro{SIGHUP} a tutti i processi in background e il terminale di
684 controllo viene disconnesso (vedi \secref{sec:sess_xxx}).
685 \item se la conclusione di un processo rende orfano un \textit{process
686 group} ciascun membro del gruppo viene bloccato, e poi gli vengono
687 inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}
688 (vedi \secref{sec:sess_xxx}).
691 Oltre queste operazioni è però necessario poter disporre di un meccanismo
692 ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
693 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
694 scelto consiste nel riportare lo stato di terminazione (il cosiddetto
695 \textit{termination status}) al processo padre.
697 Nel caso di conclusione normale, abbiamo visto in \secref{sec:proc_conclusion}
698 che lo stato di uscita del processo viene caratterizzato tramite il valore del
699 cosiddetto \textit{exit status}, cioè il valore passato alle funzioni
700 \func{exit} o \func{\_exit} (o dal valore di ritorno per \func{main}). Ma se
701 il processo viene concluso in maniera anomala il programma non può specificare
702 nessun \textit{exit status}, ed è il kernel che deve generare autonomamente il
703 \textit{termination status} per indicare le ragioni della conclusione anomala.
705 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
706 quello che contraddistingue lo stato di chiusura del processo e viene
707 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
708 \secref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
709 il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
712 La scelta di riportare al padre lo stato di terminazione dei figli, pur
713 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
714 alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
715 che sia così alla sua conclusione, dato che il padre potrebbe essere già
716 terminato (si potrebbe avere cioè quello che si chiama un processo
719 Questa complicazione viene superata facendo in modo che il processo orfano
720 venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
721 termina, il kernel controlla se è il padre di altri processi in esecuzione: in
722 caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
723 con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
724 avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
725 cui riportare il suo stato di terminazione. Come verifica di questo
726 comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
727 ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
731 [piccardi@selidor sources]$ ./forktest -c2 3
732 Process 1972: forking 3 child
733 Spawned 1 child, pid 1973
734 Child 1 successfully executing
736 Spawned 2 child, pid 1974
737 Child 2 successfully executing
739 Child 3 successfully executing
740 Spawned 3 child, pid 1975
742 [piccardi@selidor sources]$ Child 3, parent 1, exiting
743 Child 2, parent 1, exiting
744 Child 1, parent 1, exiting
747 come si può notare in questo caso il processo padre si conclude prima dei
748 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
749 secondi dopo viene stampato a video anche l'output dei tre figli che
750 terminano, e come si può notare in questo caso, al contrario di quanto visto
751 in precedenza, essi riportano 1 come \acr{ppid}.
753 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
754 perché non è detto che il padre possa ricevere immediatamente lo stato di
755 terminazione, quindi il kernel deve comunque conservare una certa quantità di
756 informazioni riguardo ai processi che sta terminando.
758 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
759 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
760 dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di
761 terminazione\footnote{NdA verificare esattamente cosa c'è!}, mentre la memoria
762 in uso ed i file aperti vengono rilasciati immediatamente. I processi che sono
763 terminati, ma il cui stato di terminazione non è stato ancora ricevuto dal
764 padre sono chiamati \textit{zombie}, essi restano presenti nella tabella dei
765 processi ed in genere possono essere identificati dall'output di \cmd{ps} per
766 la presenza di una \texttt{Z} nella colonna che ne indica lo stato. Quando il
767 padre effettuerà la lettura dello stato di uscita anche questa informazione,
768 non più necessaria, verrà scartata e la terminazione potrà dirsi completamente
771 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
772 condizione: lanciamo il comando \cmd{forktest} in background, indicando al
773 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
774 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
779 [piccardi@selidor sources]$ ps T
780 PID TTY STAT TIME COMMAND
781 419 pts/0 S 0:00 bash
782 568 pts/0 S 0:00 ./forktest -e10 3
783 569 pts/0 Z 0:00 [forktest <defunct>]
784 570 pts/0 Z 0:00 [forktest <defunct>]
785 571 pts/0 Z 0:00 [forktest <defunct>]
786 572 pts/0 R 0:00 ps T
789 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
790 terminazione, i tre processi figli sono ancora presenti pur essendosi
791 conclusi, con lo stato di zombie e l'indicazione che sono stati terminati.
793 La possibilità di avere degli zombie deve essere tenuta sempre presente quando
794 si scrive un programma che deve essere mantenuto in esecuzione a lungo e
795 creare molti figli. In questo caso si deve sempre avere cura di far leggere
796 l'eventuale stato di uscita di tutti i figli (in genere questo si fa
797 attraverso un apposito \textit{signal handler}, che chiama la funzione
798 \func{wait}, vedi \secref{sec:sig_xxx} e \secref{sec:proc_wait}). Questa
799 operazione è necessaria perché anche se gli \textit{zombie} non consumano
800 risorse di memoria o processore, occupano comunque una voce nella tabella dei
801 processi, che a lungo andare potrebbe esaurirsi.
803 Si noti che quando un processo adottato da \cmd{init} termina, esso non
804 diviene uno \textit{zombie}; questo perché una delle funzioni di \cmd{init} è
805 appunto quella di chiamare la funzione \func{wait} per i processi cui fa da
806 padre, completandone la terminazione. Questo è quanto avviene anche quando,
807 come nel caso del precedente esempio con \cmd{forktest}, il padre termina con
808 dei figli in stato di zombie: alla sua terminazione infatti tutti i suoi figli
809 (compresi gli zombie) verranno adottati da \cmd{init}, il quale provvederà a
810 completarne la terminazione.
812 Si tenga presente infine che siccome gli zombie sono processi già usciti, non
813 c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità di
814 cancellarli dalla tabella dei processi è quella di terminare il processo che
815 li ha generati, in modo che \cmd{init} possa adottarli e provvedere a
816 concluderne la terminazione.
819 \subsection{Le funzioni \func{wait} e \func{waitpid}}
820 \label{sec:proc_wait}
822 Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
823 consiste nella creazione di programmi di tipo server, in cui un processo
824 principale attende le richieste che vengono poi soddisfatte da una serie di
825 processi figli. Si è già sottolineato al paragrafo precedente come in questo
826 caso diventi necessario gestire esplicitamente la conclusione dei figli onde
827 evitare di riempire di \textit{zombie} la tabella dei processi; le funzioni
828 deputate a questo compito sono sostanzialmente due, \func{wait} e
829 \func{waitpid}. La prima, il cui prototipo è:
831 \headdecl{sys/types.h}
832 \headdecl{sys/wait.h}
833 \funcdecl{pid\_t wait(int *status)}
835 Sospende il processo corrente finché un figlio non è uscito, o finché un
836 segnale termina il processo o chiama una funzione di gestione.
838 \bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
839 e -1 in caso di errore; \var{errno} può assumere i valori:
841 \item[\macro{EINTR}] la funzione è stata interrotta da un segnale.
845 è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
846 processo figlio termina. Se un figlio è già terminato la funzione ritorna
849 Al ritorno lo stato di termininazione del processo viene salvato nella
850 variabile puntata da \var{status} e tutte le informazioni relative al
851 processo (vedi \secref{sec:proc_termination}) vengono rilasciate. Nel
852 caso un processo abbia più figli il valore di ritorno permette di
853 identificare qual'è quello che è uscito.
855 Questa funzione ha il difetto di essere poco flessibile, in quanto
856 ritorna all'uscita di un figlio qualunque. Nelle occasioni in cui è
857 necessario attendere la conclusione di un processo specifico occorre
858 predisporre un meccanismo che tenga conto dei processi già terminati, e
859 provveda a ripetere la chiamata alla funzione nel caso il processo
860 cercato sia ancora attivo.
862 Per questo motivo lo standard POSIX.1 ha introdotto la funzione \func{waitpid}
863 che effettua lo stesso servizio, ma dispone di una serie di funzionalità più
864 ampie, legate anche al controllo di sessione. Dato che è possibile ottenere
865 lo stesso comportamento di \func{wait} si consiglia di utilizzare sempre
866 questa funzione, il cui prototipo è:
868 \headdecl{sys/types.h}
869 \headdecl{sys/wait.h}
870 \funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
871 Attende la conclusione di un processo figlio.
873 \bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
874 è stata specificata l'opzione \macro{WNOHANG} e il processo non è uscito e
875 -1 per un errore, nel qual caso \var{errno} assumerà i valori:
877 \item[\macro{EINTR}] se non è stata specificata l'opzione \macro{WNOHANG} e
878 la funzione è stata interrotta da un segnale.
879 \item[\macro{ECHILD}] il processo specificato da \param{pid} non esiste o
880 non è figlio del processo chiamante.
884 Le differenze principali fra le due funzioni sono che \func{wait} si blocca
885 sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la
886 possibilità si specificare un'opzione \macro{WNOHANG} che ne previene il
887 blocco; inoltre \func{waitpid} può specificare quale processo attendere sulla
888 base del valore fornito dall'argomento \param{pid}, secondo lo
889 specchietto riportato in \ntab:
893 \begin{tabular}[c]{|c|p{10cm}|}
895 \textbf{Valore} & \textbf{Significato}\\
898 $<-1$& attende per un figlio il cui \textit{process group} è uguale al
899 valore assoluto di \var{pid}. \\
900 $-1$ & attende per un figlio qualsiasi, usata in questa maniera è
901 equivalente a \func{wait}.\\
902 $0$ & attende per un figlio il cui \textit{process group} è uguale a
903 quello del processo chiamante. \\
904 $>0$ & attende per un figlio il cui \acr{pid} è uguale al
905 valore di \var{pid}.\\
908 \caption{Significato dei valori del parametro \var{pid} della funzione
910 \label{tab:proc_waidpid_pid}
913 Il comportamento di \func{waitpid} può inoltre essere modificato passando
914 delle opportune opzioni tramite l'argomento \param{option}. I valori possibili
915 sono il già citato \macro{WNOHANG}, che previene il blocco della funzione
916 quando il processo figlio non è terminato, e \macro{WUNTRACED} (usata per il
917 controllo di sessione, trattato in \capref{cha:session}) che fa ritornare la
918 funzione anche per i processi figli che sono bloccati ed il cui stato non è
919 stato ancora riportato al padre. Il valore dell'opzione deve essere
920 specificato come maschera binaria ottenuta con l'OR delle suddette costanti
923 La terminazione di un processo figlio è chiaramente un evento asincrono
924 rispetto all'esecuzione di un programma e può avvenire in un qualunque
925 momento. Per questo motivo, come accennato nella sezione precedente, una delle
926 azioni prese dal kernel alla conclusione di un processo è quella di mandare un
927 segnale di \macro{SIGCHLD} al padre. L'azione di default (si veda
928 \secref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
929 generazione costituisce il meccanismo di comunicazione asincrona con cui il
930 kernel avverte il processo padre che uno dei suoi figli è terminato.
932 In genere in un programma non si vuole essere forzati ad attendere la
933 conclusione di un processo per proseguire, specie se tutto questo serve solo
934 per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}),
935 per questo la modalità più usata per chiamare queste funzioni è quella di
936 utilizzarle all'interno di un \textit{signal handler} (torneremo sui segnali e
937 su come gestire \macro{SIGCHLD} in \secref{sec:sig_sigwait_xxx}). In questo
938 caso infatti, dato che il segnale è generato dalla terminazione di un figlio,
939 avremo la certezza che la chiamata a \func{wait} non si bloccherà.
944 \begin{tabular}[c]{|c|p{10cm}|}
946 \textbf{Macro} & \textbf{Descrizione}\\
949 \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo
950 figlio che sia terminato normalmente. \\
951 \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
952 stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit}
953 o come valore di ritorno di \func{main}). Può essere valutata solo se
954 \macro{WIFEXITED} ha restituito un valore non nullo.\\
955 \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
956 in maniera anomala a causa di un segnale che non è stato catturato (vedi
957 \secref{sec:sig_notification}).\\
958 \macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato
959 la terminazione anomala del processo. Può essere valutata solo se
960 \macro{WIFSIGNALED} ha restituito un valore non nullo.\\
961 \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
962 file si \textit{core dump}. Può essere valutata solo se
963 \macro{WIFSIGNALED} ha restituito un valore non nullo\footnote{questa
964 macro non è definita dallo standard POSIX.1, ma è presente come estensione
965 sia in Linux che in altri unix}.\\
966 \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
967 \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato
968 l'opzione \macro{WUNTRACED}. \\
969 \macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato
970 il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha
971 restituito un valore non nullo. \\
974 \caption{Descrizione delle varie macro di preprocessore utilizzabili per
975 verificare lo stato di terminazione \var{s} di un processo.}
976 \label{tab:proc_status_macro}
979 Entrambe le funzioni di attesa restituiscono lo stato di terminazione del
980 processo tramite il puntatore \param{status} (se non interessa memorizzare lo
981 stato si può passare un puntatore nullo). Il valore restituito da entrambe le
982 funzioni dipende dall'implementazione, e tradizionalmente alcuni bit (in
983 genere 8) sono riservati per memorizzare lo stato di uscita, e altri per
984 indicare il segnale che ha causato la terminazione (in caso di conclusione
985 anomala), uno per indicare se è stato generato un core file, ecc.\footnote{le
986 definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
987 questo file non deve mai essere usato direttamente, esso viene incluso
988 attraverso \file{<sys/wait.h>}.}
990 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
991 analizzare lo stato di uscita. Esse sono definite sempre in
992 \file{<sys/wait.h>} ed elencate in \tabref{tab:proc_status_macro} (si tenga
993 presente che queste macro prendono come parametro la variabile di tipo
994 \type{int} puntata da \var{status}).
996 Si tenga conto che nel caso di conclusione anomala il valore restituito da
997 \macro{WTERMSIG} può essere confrontato con le costanti definite in
998 \file{signal.h} ed elencate in \tabref{tab:sig_signal_list}, e stampato usando
999 le apposite funzioni trattate in \secref{sec:sig_strsignal}.
1002 \subsection{Le funzioni \func{wait3} e \func{wait4}}
1003 \label{sec:proc_wait4}
1005 Linux, seguendo un'estensione di BSD, supporta altre due funzioni per la
1006 lettura dello stato di terminazione di un processo \func{wait3} e
1007 \func{wait4}, analoghe alle precedenti ma che prevedono un ulteriore
1008 parametro attraverso il quale il kernel può restituire al padre informazioni
1009 sulle risorse usate dal processo terminato e dai vari figli. I prototipi di
1010 queste funzioni, che diventano accessibili definendo la costante
1011 \macro{\_USE\_BSD}, sono:
1013 \headdecl{sys/times.h}
1014 \headdecl{sys/types.h}
1015 \headdecl{sys/wait.h}
1016 \headdecl{sys/resource.h}
1017 \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
1019 È identica a \func{waitpid} sia per comportamento che per i
1020 valori dei parametri, ma restituisce in \param{rusage} un sommario delle
1021 risorse usate dal processo (per i dettagli vedi \secref{sec:sys_xxx})
1023 \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
1024 Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
1025 ormai deprecata in favore di \func{wait4}.
1028 la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
1029 utilizzata anche dalla funzione \func{getrusage} (vedi \secref{sec:sys_xxx})
1030 per ottenere le risorse di sistema usate da un processo; la sua definizione è
1031 riportata in \figref{fig:sys_rusage_struct}.
1033 In genere includere esplicitamente \file{<sys/time.h>} non è più
1034 necessario, ma aumenta la portabilità, e serve in caso si debba accedere
1035 ai campi di \var{rusage} definiti come \type{struct timeval}. La
1036 struttura è ripresa da BSD 4.3, attualmente (con il kernel 2.4.x) i soli
1037 campi che sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime},
1038 \var{ru\_minflt}, \var{ru\_majflt}, e \var{ru\_nswap}.
1041 \subsection{Le funzioni \func{exec}}
1042 \label{sec:proc_exec}
1044 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1045 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1046 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1047 processo chiama una di queste funzioni esso viene completamente sostituito dal
1048 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
1049 creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo
1050 heap, i dati ed il testo del processo corrente con un nuovo programma letto da
1053 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1054 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1055 (come mostrato in \figref{fig:proc_exec_relat}), sono tutte un front-end a
1056 \func{execve}. Il prototipo di quest'ultima è:
1057 \begin{prototype}{unistd.h}
1058 {int execve(const char *filename, char *const argv[], char *const envp[])}
1059 Esegue il programma contenuto nel file \param{filename}.
1061 \bodydesc{La funzione ritorna -1 solo in caso di errore, nel qual caso
1062 caso la \var{errno} può assumere i valori:
1064 \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è
1065 montato in \cmd{noexec}, oppure non è un file normale o un interprete.
1066 \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non
1067 è root, e o il processo viene tracciato, o il filesystem è montato con
1068 l'opzione \cmd{nosuid}.
1069 \item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non
1070 riconosciuto come tale, o compilato per un'altra architettura.
1071 \item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1072 necessari per eseguirlo non esistono.
1073 \item[\macro{ETXTBSY}] L'eseguibile è aperto in scrittura da uno o più
1075 \item[\macro{EINVAL}] L'eseguibile ELF ha più di un segmento
1076 \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un
1078 \item[\macro{ELIBBAD}] Un interprete ELF non è in un formato
1081 ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO},
1082 \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}, \macro{ENOTDIR},
1083 \macro{ENFILE}, \macro{EMFILE}.}
1086 La funzione \func{exec} esegue il file o lo script indicato da
1087 \var{filename}, passandogli la lista di argomenti indicata da \var{argv}
1088 e come ambiente la lista di stringhe indicata da \var{envp}; entrambe le
1089 liste devono essere terminate da un puntatore nullo. I vettori degli
1090 argomenti e dell'ambiente possono essere acceduti dal nuovo programma
1091 quando la sua funzione \func{main} è dichiarata nella forma
1092 \code{main(int argc, char *argv[], char *envp[])}.
1094 Le altre funzioni della famiglia servono per fornire all'utente una serie
1095 possibile di diverse interfacce per la creazione di un nuovo processo. I loro
1099 \funcdecl{int execl(const char *path, const char *arg, ...)}
1100 \funcdecl{int execv(const char *path, char *const argv[])}
1101 \funcdecl{int execle(const char *path, const char *arg, ..., char
1103 \funcdecl{int execlp(const char *file, const char *arg, ...)}
1104 \funcdecl{int execvp(const char *file, char *const argv[])}
1106 Sostituiscono l'immagine corrente del processo con quella indicata nel primo
1107 argomento. I parametri successivi consentono di specificare gli argomenti a
1108 linea di comando e l'ambiente ricevuti dal nuovo processo.
1110 \bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo
1111 -1; nel qual caso \var{errno} andrà ad assumere i valori visti in
1112 precedenza per \func{execve}.}
1115 Per capire meglio le differenze fra le funzioni della famiglia si può fare
1116 riferimento allo specchietto riportato in \ntab. La prima differenza riguarda
1117 le modalità di passaggio dei parametri che poi andranno a costituire gli
1118 argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
1119 dalla funzione \func{main} del programma chiamato).
1121 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
1122 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
1123 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
1124 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
1125 questo vettore \emph{deve} essere terminato da un puntatore nullo.
1127 Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
1128 lista di puntatori, nella forma:
1129 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
1130 char *arg0, char *arg1, ..., char *argn, NULL
1132 che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
1133 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1134 per indicare il nome del file che contiene il programma che verrà eseguito.
1139 \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1141 \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
1142 \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1144 &\func{execl\ }&\func{execlp}&\func{execle}
1145 &\func{execv\ }& \func{execvp}& \func{execve} \\
1148 argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
1149 argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
1151 filename completo &&$\bullet$&&&$\bullet$& \\
1152 ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\
1154 ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
1155 uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1158 \caption{Confronto delle caratteristiche delle varie funzioni della
1159 famiglia \func{exec}.}
1160 \label{tab:proc_exec_scheme}
1163 La seconda differenza fra le funzioni riguarda le modalità con cui si
1164 specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
1165 indicano le due funzioni che replicano il comportamento della shell nello
1166 specificare il comando da eseguire; quando il parametro \var{file} non
1167 contiene una \file{/} esso viene considerato come un nome di programma, e
1168 viene eseguita automaticamente una ricerca fra i file presenti nella lista di
1169 directory specificate dalla variabile di ambiente \var{PATH}. Il file che
1170 viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
1171 relativo a permessi di accesso insufficienti (cioè l'esecuzione della
1172 sottostante \func{execve} ritorna un \macro{EACCESS}), la ricerca viene
1173 proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
1174 non viene trovato nessun altro file viene finalmente restituito
1177 Le altre quattro funzioni si limitano invece a cercare di eseguire il file
1178 indicato dal parametro \var{path}, che viene interpretato come il
1179 \textit{pathname} del programma.
1183 \includegraphics[width=13cm]{img/exec_rel}
1184 \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
1185 \label{fig:proc_exec_relat}
1188 La terza differenza è come viene passata la lista delle variabili di ambiente.
1189 Con lo mnemonico \code{e} vengono indicate quelle funzioni che necessitano di
1190 un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti
1191 a riga di comando (terminato quindi da un \macro{NULL}), le altre usano il
1192 valore della variabile \var{environ} (vedi \secref{sec:proc_environ}) del
1193 processo di partenza per costruire l'ambiente.
1195 Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
1196 \func{exec} assume anche una serie di altre proprietà del processo chiamante;
1197 la lista completa è la seguente:
1199 \item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
1201 \item il \textit{real user id} ed il \textit{real group id} (vedi
1202 \secref{sec:proc_access_id}).
1203 \item i \textit{supplementary group id} (vedi \secref{sec:proc_access_id}).
1204 \item il \textit{session id} ed il \textit{process group id} (vedi
1205 \secref{sec:sess_xxx}).
1206 \item il terminale di controllo (vedi \secref{sec:sess_xxx}).
1207 \item il tempo restante ad un allarme (vedi \secref{sec:sig_xxx}).
1208 \item la directory radice e la directory di lavoro corrente (vedi
1209 \secref{sec:file_work_dir}).
1210 \item la maschera di creazione dei file (\var{umask}, vedi
1211 \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
1212 \secref{sec:file_locking}).
1213 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
1214 \secref{sec:sig_sigpending}).
1215 \item i limiti sulle risorse (vedi \secref{sec:sys_limits}).
1216 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
1217 \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).
1220 Inoltre i segnali che sono stati settati per essere ignorati nel processo
1221 chiamante mantengono lo stesso settaggio pure nel nuovo programma, tutti gli
1222 altri segnali vengono settati alla loro azione di default. Un caso speciale è
1223 il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN}, può anche
1224 non essere resettato a \macro{SIG\_DFL} (si veda \secref{sec:sig_gen_beha}).
1226 La gestione dei file aperti dipende dal valore che ha il flag di
1227 \textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file
1228 descriptor. I file per cui è settato vengono chiusi, tutti gli altri file
1229 restano aperti. Questo significa che il comportamento di default è che i file
1230 restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
1231 \func{fcntl} che setti il suddetto flag.
1233 Per le directory, lo standard POSIX.1 richiede che esse vengano chiuse
1234 attraverso una \func{exec}, in genere questo è fatto dalla funzione
1235 \func{opendir} (vedi \secref{sec:file_dir_read}) che effettua da sola il
1236 settaggio del flag di \textit{close-on-exec} sulle directory che apre, in
1237 maniera trasparente all'utente.
1239 Abbiamo detto che il \textit{real user id} ed il \textit{real group id}
1240 restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
1241 l'\textit{effective user id} ed l'\textit{effective group id}, tranne quando
1242 il file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit
1243 settato, in questo caso l'\textit{effective user id} e l'\textit{effective
1244 group id} vengono settati rispettivamente all'utente o al gruppo cui il file
1245 appartiene (per i dettagli vedi \secref{sec:proc_perms}).
1247 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1248 condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
1249 programma per caricare le librerie necessarie ed effettuare il link
1250 dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
1251 dinamiche viene usato l'interprete indicato nel segmento \macro{PT\_INTERP},
1252 in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
1253 \emph{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
1254 \emph{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
1255 una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
1256 deve esse un valido programma (binario, non un altro script) che verrà
1257 chiamato come se si fosse eseguito il comando \cmd{interpreter [arg]
1260 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1261 basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
1262 processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
1263 \func{wait} si effettua e verifica la conclusione dei programmi. Tutte le
1264 altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari
1265 parametri connessi ai processi.
1269 \section{Il controllo di accesso}
1270 \label{sec:proc_perms}
1272 In questa sezione esamineremo le problematiche relative al controllo di
1273 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
1274 usati, come questi possono essere modificati nella creazione e nel lancio di
1275 nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
1276 problematiche connesse ad una gestione accorta dei privilegi.
1279 \subsection{Gli identificatori del controllo di accesso}
1280 \label{sec:proc_access_id}
1282 Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
1283 realtà già esistono estensioni di questo modello base, che lo rendono più
1284 flessibile e controllabile, come le \textit{capabilities}, le ACL per i file
1285 o il \textit{Mandatory Access Control} di SELinux} di sicurezza di un
1286 sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
1287 separazione fra l'amministratore (\textsl{root}, detto spesso anche
1288 \textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
1289 utenti, per i quali invece vengono effettuati i vari controlli di accesso.
1291 %Benché il sistema sia piuttosto semplice (è basato su un solo livello di
1292 % separazione) il sistema permette una
1293 %notevole flessibilità,
1295 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1296 identificatori univoci, lo \acr{uid} e il \acr{gid}; questi servono al kernel
1297 per identificare uno specifico utente o un gruppo di utenti, per poi poter
1298 controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
1299 esempio in \secref{sec:file_access_control} vedremo come ad ogni file vengano
1300 associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
1301 appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
1302 kernel nella gestione dei permessi di accesso.
1304 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1305 evidente che per poter implementare un controllo sulle operazioni occorre
1306 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1307 anche a ciascun processo è associato un utente e a un gruppo.
1309 Un semplice controllo di una corrispondenza fra identificativi non garantisce
1310 però sufficiente flessibilità per tutti quei casi in cui è necessario poter
1311 disporre di privilegi diversi, o dover impersonare un altro utente per un
1312 limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
1313 prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
1314 rispettivamente \textit{real} ed \textit{effective}.
1319 \begin{tabular}[c]{|c|l|p{6.5cm}|}
1321 \textbf{Suffisso} & \textbf{Significato} & \textbf{Utilizzo} \\
1324 \acr{uid} & \textit{real user id} & indica l'utente che ha lanciato
1326 \acr{gid} & \textit{real group id} & indica il gruppo dell'utente
1327 che ha lanciato il programma \\
1329 \acr{euid} & \textit{effective user id} & indica l'utente usato
1330 dal programma nel controllo di accesso \\
1331 \acr{egid} & \textit{effective group id} & indica il gruppo
1332 usato dal programma nel controllo di accesso \\
1333 -- & \textit{supplementary group id} & indica i gruppi cui
1334 l'utente appartiene \\
1336 -- & \textit{saved user id} & copia dell'\acr{euid} iniziale\\
1337 -- & \textit{saved group id} & copia dell'\acr{egid} iniziale \\
1339 \acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per
1341 \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo
1342 per il filesystem \\
1345 \caption{Identificatori di utente e gruppo associati a ciascun processo con
1346 indicazione dei suffissi usate dalle varie funzioni di manipolazione.}
1347 \label{tab:proc_uid_gid}
1350 Al primo gruppo appartengono il \textit{real user id} e il \textit{real group
1351 id}: questi vengono settati al login ai valori corrispondenti all'utente con
1352 cui si accede al sistema (e relativo gruppo di default). Servono per
1353 l'identificazione dell'utente e normalmente non vengono mai cambiati. In
1354 realtà vedremo (in \secref{sec:proc_setuid}) che è possibile modificarli, ma
1355 solo ad un processo che abbia i privilegi di amministratore; questa
1356 possibilità è usata ad esempio da \cmd{login} che, una volta completata la
1357 procedura di autenticazione, lancia una shell per la quale setta questi
1358 identificatori ai valori corrispondenti all'utente che entra nel sistema.
1360 Al secondo gruppo appartengono l'\textit{effective user id} e
1361 l'\textit{effective group id} (a cui si aggiungono gli eventuali
1362 \textit{supplementary group id} dei gruppi dei quali l'utente fa parte).
1363 Questi sono invece gli identificatori usati nella verifiche dei permessi del
1364 processo e per il controllo di accesso ai file (argomento affrontato in
1365 dettaglio in \secref{sec:file_perm_overview}).
1367 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1368 \textit{real} tranne nel caso in cui, come accennato in
1369 \secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
1370 \acr{suid} o \acr{sgid} settati (il significato di questi bit è affrontato in
1371 dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati
1372 all'utente e al gruppo proprietari del file. Questo consente, per programmi in
1373 cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
1374 di un'altro (o dell'amministratore).
1376 Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
1377 possono essere letti dal processo attraverso delle opportune funzioni, i cui
1378 prototipi sono i seguenti:
1381 \headdecl{sys/types.h}
1382 \funcdecl{uid\_t getuid(void)} Restituisce il \textit{real user id} del
1385 \funcdecl{uid\_t geteuid(void)} Restituisce l'\textit{effective user id} del
1388 \funcdecl{gid\_t getgid(void)} Restituisce il \textit{real group id} del
1391 \funcdecl{gid\_t getegid(void)} Restituisce l'\textit{effective group id} del
1394 \bodydesc{Queste funzioni non riportano condizioni di errore.}
1397 In generale l'uso di privilegi superiori deve essere limitato il più
1398 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1399 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1400 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1401 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1404 Questo in Linux viene fatto usando altri due gruppi di identificatori, il
1405 \textit{saved} ed il \textit{filesystem}, analoghi ai precedenti. Il primo
1406 gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è
1407 definita la costante \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a
1408 cuore la portabilità del programma su altri Unix è buona norma controllare
1409 sempre la disponibilità di queste funzioni controllando se questa costante è
1410 definita.} il secondo gruppo è specifico di Linux e viene usato per
1411 migliorare la sicurezza con NFS.
1413 Il \textit{saved user id} e il \textit{saved group id} sono copie
1414 dell'\textit{effective user id} e dell'\textit{effective group id} del
1415 processo padre, e vengono settati dalla funzione \func{exec} all'avvio del
1416 processo, come copie dell'\textit{effective user id} e dell'\textit{effective
1417 group id} dopo che questo sono stati settati tenendo conto di eventuali
1418 \acr{suid} o \acr{sgid}. Essi quindi consentono di tenere traccia di quale
1419 fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo
1422 Il \textit{filesystem user id} e il \textit{filesystem group id} sono una
1423 estensione introdotta in Linux per rendere più sicuro l'uso di NFS (torneremo
1424 sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una replica dei
1425 corrispondenti \textit{effective id}, ai quali si sostituiscono per tutte le
1426 operazioni di verifica dei permessi relativi ai file (trattate in
1427 \secref{sec:file_perm_overview}). Ogni cambiamento effettuato sugli
1428 \textit{effective id} viene automaticamente riportato su di essi, per cui in
1429 condizioni normali se ne può tranquillamente ignorare l'esistenza, in quanto
1430 saranno del tutto equivalenti ai precedenti.
1432 Uno specchietto riassuntivo, contenente l'elenco completo degli identificatori
1433 di utente e gruppo associati dal kernel ad ogni processo, è riportato in
1434 \tabref{tab:proc_uid_gid}.
1437 \subsection{Le funzioni \func{setuid} e \func{setgid}}
1438 \label{sec:proc_setuid}
1440 Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
1441 di appartenenza) ad un processo sono rispettivamente \func{setuid} e
1442 \func{setgid}; come accennato in \secref{sec:proc_access_id} in Linux esse
1443 seguono la semantica POSIX che prevede l'esistenza del \textit{saved user id}
1444 e del \textit{saved group id}; i loro prototipi sono:
1447 \headdecl{sys/types.h}
1449 \funcdecl{int setuid(uid\_t uid)} Setta l'\textit{user id} del processo
1452 \funcdecl{int setgid(gid\_t gid)} Setta il \textit{group id} del processo
1455 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1456 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1459 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1460 la prima; la seconda si comporta esattamente allo stesso modo facendo
1461 riferimento al \textit{group id} invece che all'\textit{user id}. Gli
1462 eventuali \textit{supplementary group id} non vengono modificati.
1465 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1466 l'\textit{effective user id} è zero (cioè è quello dell'amministratore di
1467 sistema) allora tutti gli identificatori (\textit{real}, \textit{effective}
1468 e \textit{saved}) vengono settati al valore specificato da \var{uid},
1469 altrimenti viene settato solo l'\textit{effective user id}, e soltanto se il
1470 valore specificato corrisponde o al \textit{real user id} o al \textit{saved
1471 user id}. Negli altri casi viene segnalato un errore (con \macro{EPERM}).
1473 Come accennato l'uso principale di queste funzioni è quello di poter
1474 consentire ad un programma con i bit \acr{suid} o \acr{sgid} settati di
1475 riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il
1476 programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
1477 eventualmente tornare indietro.
1479 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
1480 viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene
1481 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1482 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1483 falsificare la registrazione. Per questo motivo questo file (e l'analogo
1484 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
1485 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
1486 esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
1487 crea terminali multipli su una console) appartengono a questo gruppo ed hanno
1488 il bit \acr{sgid} settato.
1490 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
1491 situazione degli identificatori è la seguente:
1494 \textit{real group id} &=& \textrm{\acr{gid} (del chiamante)} \\
1495 \textit{effective group id} &=& \textrm{\acr{utmp}} \\
1496 \textit{saved group id} &=& \textrm{\acr{utmp}}
1498 in questo modo, dato che l'\textit{effective group id} è quello giusto, il
1499 programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo. A
1500 questo punto il programma può eseguire una \code{setgid(getgid())} per settare
1501 l'\textit{effective group id} a quello dell'utente (e dato che il \textit{real
1502 group id} corrisponde la funzione avrà successo), in questo modo non sarà
1503 possibile lanciare dal terminale programmi che modificano detto file, in tal
1504 caso infatti la situazione degli identificatori sarebbe:
1507 \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\
1508 \textit{effective group id} &=& \textrm{\acr{gid}} \\
1509 \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)}
1511 e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
1512 \textit{effective group id}. All'uscita dal terminale, per poter di nuovo
1513 aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una
1514 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
1515 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
1516 in questo caso il valore richiesto corrisponde al \textit{saved group id} la
1517 funzione avrà successo e riporterà la situazione a:
1520 \textit{real group id} &=& \textrm{\acr{gid} (invariato)} \\
1521 \textit{effective group id} &=& \textrm{\acr{utmp}} \\
1522 \textit{saved group id} &=& \textrm{\acr{utmp} (invariato)}
1524 consentendo l'accesso a \file{/var/log/utmp}.
1526 Occorre però tenere conto che tutto questo non è possibile con un processo con
1527 i privilegi di root, in tal caso infatti l'esecuzione una \func{setuid}
1528 comporta il cambiamento di tutti gli identificatori associati al processo,
1529 rendendo impossibile riguadagnare i privilegi di amministratore. Questo
1530 comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea
1531 una nuova shell per l'utente; ma quando si vuole cambiare soltanto
1532 l'\textit{effective user id} del processo per cedere i privilegi occorre
1533 ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
1536 \subsection{Le funzioni \func{setreuid} e \func{setresuid}}
1537 \label{sec:proc_setreuid}
1539 Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino
1540 alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} i
1541 \textit{saved id}, le usava per poter scambiare fra di loro \textit{effective}
1542 e \textit{real id}. I loro prototipi sono:
1545 \headdecl{sys/types.h}
1547 \funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Setta il \textit{real user
1548 id} e l'\textit{effective user id} del processo corrente ai valori
1549 specificati da \var{ruid} e \var{euid}.
1551 \funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Setta il \textit{real group
1552 id} e l'\textit{effective group id} del processo corrente ai valori
1553 specificati da \var{rgid} e \var{egid}.
1555 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1556 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1559 I processi non privilegiati possono settare i \textit{real id} soltanto ai
1560 valori dei loro \textit{effective id} o \textit{real id} e gli
1561 \textit{effective id} ai valori dei loro \textit{real id}, \textit{effective
1562 id} o \textit{saved id}; valori diversi comportano il fallimento della
1563 chiamata; l'amministratore invece può specificare un valore qualunque.
1564 Specificando un valore di -1 l'identificatore corrispondente viene lasciato
1567 Con queste funzione si possono scambiare fra loro \textit{real id} e
1568 \textit{effective id}, e pertanto è possibile implementare un comportamento
1569 simile a quello visto in precedenza per \func{setgid}, cedendo i privilegi con
1570 un primo scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un
1573 In questo caso però occorre porre molta attenzione quando si creano nuovi
1574 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
1575 questo caso infatti essi avranno un \textit{real id} privilegiato, che dovrà
1576 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
1577 programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork}, e
1578 prima della \func{exec} per uniformare i \textit{real id} agli
1579 \textit{effective id}) in caso contrario quest'ultimo potrebbe a sua volta
1580 effettuare uno scambio e riottenere privilegi non previsti.
1582 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
1583 si porrebbe per i \textit{saved id}: queste funzioni derivano da
1584 un'implementazione che non ne prevede la presenza, e quindi non è possibile
1585 usarle per correggere la situazione come nel caso precedente. Per questo
1586 motivo in Linux tutte le volte che vengono usate per modificare uno degli
1587 identificatori ad un valore diverso dal \textit{real id} precedente, il
1588 \textit{saved id} viene sempre settato al valore dell'\textit{effective id}.
1592 \subsection{Le funzioni \func{seteuid} e \func{setegid}}
1593 \label{sec:proc_seteuid}
1595 Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque
1596 supportate dalla maggior parte degli Unix) e usate per cambiare gli
1597 \textit{effective id}; i loro prototipi sono:
1600 \headdecl{sys/types.h}
1602 \funcdecl{int seteuid(uid\_t uid)} Setta l'\textit{effective user id} del
1603 processo corrente a \var{uid}.
1605 \funcdecl{int setegid(gid\_t gid)} Setta l'\textit{effective group id} del
1606 processo corrente a \var{gid}.
1608 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1609 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1612 Gli utenti normali possono settare l'\textit{effective id} solo al valore del
1613 \textit{real id} o del \textit{saved id}, l'amministratore può specificare
1614 qualunque valore. Queste funzioni sono usate per permettere a root di settare
1615 solo l'\textit{effective id}, dato che l'uso normale di \func{setuid} comporta
1616 il settaggio di tutti gli identificatori.
1619 \subsection{Le funzioni \func{setresuid} e \func{setresgid}}
1620 \label{sec:proc_setresuid}
1622 Queste due funzioni sono un'estensione introdotta in Linux dal kernel 2.1.44,
1623 e permettono un completo controllo su tutti gli identificatori (\textit{real},
1624 \textit{effective} e \textit{saved}), i prototipi sono:
1627 \headdecl{sys/types.h}
1629 \funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Setta il
1630 \textit{real user id}, l'\textit{effective user id} e il \textit{saved user
1631 id} del processo corrente ai valori specificati rispettivamente da
1632 \var{ruid}, \var{euid} e \var{suid}.
1634 \funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Setta il
1635 \textit{real group id}, l'\textit{effective group id} e il \textit{saved group
1636 id} del processo corrente ai valori specificati rispettivamente da
1637 \var{rgid}, \var{egid} e \var{sgid}.
1639 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1640 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1643 I processi non privilegiati possono cambiare uno qualunque degli
1644 identificatori usando uno qualunque dei valori correnti di \textit{real id},
1645 \textit{effective id} o \textit{saved id}, l'amministratore può specificare i
1646 valori che vuole; un valore di -1 per un qualunque parametro lascia inalterato
1647 l'identificatore corrispondente.
1649 Per queste funzioni esistono anche due controparti che permettono di leggere
1650 in blocco i vari identificatori: \func{getresuid} e \func{getresgid}; i loro
1654 \headdecl{sys/types.h}
1656 \funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge il
1657 \textit{real user id}, l'\textit{effective user id} e il \textit{saved user
1658 id} del processo corrente.
1660 \funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il
1661 \textit{real group id}, l'\textit{effective group id} e il \textit{saved group
1662 id} del processo corrente.
1664 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
1665 fallimento: l'unico errore possibile è \macro{EFAULT} se gli indirizzi delle
1666 variabili di ritorno non sono validi.}
1669 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
1670 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
1671 specificati come puntatori (è un'altro esempio di \textit{value result
1672 argument}). Si noti che queste funzioni sono le uniche in grado di leggere i
1676 \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
1677 \label{sec:proc_setfsuid}
1679 Queste funzioni sono usate per settare gli identificatori usati da Linux per
1680 il controllo dell'accesso ai file. Come già accennato in
1681 \secref{sec:proc_access_id} in Linux è definito questo ulteriore gruppo di
1682 identificatori, che di norma sono assolutamente equivalenti agli
1683 \textit{effective id}, dato che ogni cambiamento di questi ultimi viene
1684 immediatamente riportato sui \textit{filesystem id}.
1686 C'è un solo caso in cui si ha necessità di introdurre una differenza fra
1687 \textit{effective id} e \textit{filesystem id}, ed è per ovviare ad un
1688 problema di sicurezza che si presenta quando si deve implementare un server
1689 NFS. Il server NFS infatti deve poter cambiare l'identificatore con cui accede
1690 ai file per assumere l'identità del singolo utente remoto, ma se questo viene
1691 fatto cambiando l'\textit{effective id} o il \textit{real id} il server si
1692 espone alla ricezione di eventuali segnali ostili da parte dell'utente di cui
1693 ha temporaneamente assunto l'identità. Cambiando solo il \textit{filesystem
1694 id} si ottengono i privilegi necessari per accedere ai file, mantenendo
1695 quelli originari per quanto riguarda tutti gli altri controlli di accesso,
1696 così che l'utente non possa inviare segnali al server NFS.
1698 Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid}
1699 e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
1700 usate se si intendono scrivere programmi portabili; i loro prototipi sono:
1702 \headdecl{sys/fsuid.h}
1704 \funcdecl{int setfsuid(uid\_t fsuid)} Setta il \textit{filesystem user id} del
1705 processo corrente a \var{fsuid}.
1707 \funcdecl{int setfsgid(gid\_t fsgid)} Setta l'\textit{filesystem group id} del
1708 processo corrente a \var{fsgid}.
1710 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1711 di fallimento: l'unico errore possibile è \macro{EPERM}.}
1713 \noindent queste funzioni hanno successo solo se il processo chiamante ha i
1714 privilegi di amministratore o, per gli altri utenti, se il valore specificato
1715 coincide con uno dei \textit{real}, \textit{effective} o \textit{saved id}.
1718 \subsection{Le funzioni \func{setgroups} e \func{getgroups}}
1719 \label{sec:proc_setgroups}
1721 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
1722 gruppi supplementari. Ogni processo può avere fino a \macro{NGROUPS\_MAX}
1723 gruppi supplementari in aggiunta al gruppo primario, questi vengono ereditati
1724 dal processo padre e possono essere cambiati con queste funzioni.
1726 La funzione che permette di leggere i gruppi supplementari è \func{getgroups};
1727 questa funzione è definita nello standard POSIX ed il suo prototipo è:
1729 \headdecl{sys/types.h}
1732 \funcdecl{int getgroups(int size, gid\_t list[])} Legge gli identificatori
1733 dei gruppi supplementari del processo sul vettore \param{list} di dimensione
1736 \bodydesc{La funzione restituisce il numero di gruppi letti in caso di
1737 successo e -1 in caso di fallimento, nel qual caso \var{errno} viene
1740 \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1741 \item[\macro{EINVAL}] il valore di \param{size} è diverso da zero ma
1742 minore del numero di gruppi supplementari del processo.
1745 \noindent non è specificato se la funzione inserisca o meno nella lista
1746 l'\textit{effective user id} del processo. Se si specifica un valore di
1747 \param{size} uguale a 0 \param{list} non viene modificato, ma si ottiene il
1748 numero di gruppi supplementari.
1750 Una seconda funzione, \func{getgrouplist}, può invece essere usata per
1751 ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo è:
1753 \headdecl{sys/types.h}
1756 \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups,
1757 int *ngroups)} Legge i gruppi supplementari dell'utente \param{user}.
1759 \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori,
1760 restituisce 0 in caso di successo e -1 in caso di fallimento.}
1762 \noindent la funzione esegue una scansione del database dei gruppi (si veda
1763 \secref{sec:sys_user_group}) e ritorna in \param{groups} la lista di quelli a
1764 cui l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore
1765 perché qualora il valore specificato sia troppo piccolo la funzione ritorna
1766 -1, passando indietro il numero dei gruppi trovati.
1768 Per settare i gruppi supplementari di un processo ci sono due funzioni, che
1769 possono essere usate solo se si hanno i privilegi di amministratore. La prima
1770 delle due è \func{setgroups}, ed il suo prototipo è:
1772 \headdecl{sys/types.h}
1775 \funcdecl{int setgroups(size\_t size, gid\_t *list)} Setta i gruppi
1776 supplementari del processo ai valori specificati in \param{list}.
1778 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1779 fallimento, nel qual caso \var{errno} viene settata a:
1781 \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1782 \item[\macro{EPERM}] il processo non ha i privilegi di amministratore.
1783 \item[\macro{EINVAL}] il valore di \param{size} è maggiore del valore
1784 massimo (\macro{NGROUPS}, che per Linux è 32).
1788 Se invece si vogliono settare i gruppi supplementari del processo a quelli di
1789 un utente specifico, si può usare \func{initgroups} il cui prototipo è:
1791 \headdecl{sys/types.h}
1794 \funcdecl{int initgroups(const char *user, gid\_t group)} Setta i gruppi
1795 supplementari del processo a quelli di cui è membro l'utente \param{user},
1796 aggiungendo il gruppo addizionale \param{group}.
1798 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1799 fallimento, nel qual caso \var{errno} viene settata agli stessi valori di
1800 \func{setgroups} più \macro{ENOMEM} quando non c'è memoria sufficiente per
1801 allocare lo spazio per informazioni dei gruppi.}
1804 La funzione esegue la scansione del database dei gruppi (usualmente
1805 \file{/etc/groups}) cercando i gruppi di cui è membro \param{user} e
1806 costruendo una lista di gruppi supplementari a cui aggiunge \param{group}, che
1807 poi setta usando \func{setgroups}.
1809 Si tenga presente che sia \func{setgroups} che \func{initgroups} non sono
1810 definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle
1811 quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
1815 \section{La gestione della priorità di esecuzione}
1816 \label{sec:proc_priority}
1818 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
1819 lo \textit{scheduler}\footnote{che è la parte del kernel che si occupa di
1820 stabilire quale processo dovrà essere posto in esecuzione.} assegna la CPU
1821 ai vari processi attivi. In particolare prendremo in esame i vari meccanismi
1822 con cui viene gestita l'assegnazione del tempo di CPU, ed illustreremo le
1823 varie funzioni di gestione.
1826 \subsection{I meccanismi di \textit{scheduling}}
1827 \label{sec:proc_sched}
1829 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
1830 il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
1831 ed oggetto di numerose ricerche; in ogni caso essa dipende in maniera
1832 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema.
1834 La cosa è resa ancora più complicata dal fatto che con le architetture
1835 multi-processore si introduce anche la problematica dovuta alla scelta di
1836 quale sia la CPU più opportuna da utilizzare.\footnote{nei processori moderni
1837 la presenza di ampie cache può rendere poco efficiente trasferire
1838 l'esecuzione di un processo da una CPU ad un'altra, per cui occorrono
1839 meccanismi per determininare quale è la migliore scelta fra le diverse CPU.}
1840 Tutto questo comunque appartiene alle sottigliezze dell'implementazione del
1841 kernel, e dal punto di vista dei programmi che girano in user space anche
1842 quando si hanno più processori, e quindi potenzialmente anche dei processi che
1843 sono eseguiti davvero in contemporanea, si può pensare alle politiche di
1844 scheduling come concernenti la risorsa \textsl{tempo di esecuzione}, la cui
1845 assegnazione sarà governata dagli stessi meccanismi di scelta di priorità,
1846 solo che nel caso di più processori sarà a disposizione di più di un processo
1849 Si tenga presente inoltre che l'utilizzo della CPU è soltanto una delle
1850 risorse (insieme alla memoria e all'accesso alle periferiche) che sono
1851 necessarie per l'esecuzione di un programma, e spesso non è neanche la più
1852 importante. Per questo non è affatto detto che dare ad un programma la massima
1853 priorità di esecuzione abbia risultati significativi in termini di
1856 La politica tradizionale di scheduling di Unix (che tratteremo in
1857 \secref{sec:proc_sched_stand}) è sempre stata basata su delle priorità
1858 dinamiche, che assicurassero che tutti i processi, anche i meno importanti,
1859 potessero ricevere un po' di tempo di CPU.
1861 Lo standard POSIX però per tenere conto dei sistemi real-time,\footnote{per
1862 sistema real-time si intende un sistema in grado di eseguire operazioni in
1863 tempo reale; in genere si tende a distinguere fra l'\textit{hard real-time}
1864 in cui è necessario che i tempi di esecuzione di un programma siano
1865 determinabili con certezza assoluta, come nel caso di meccanismi di
1866 controllo di macchine, dove uno sforamento dei tempi avrebbe conseguenze
1867 disastrose, e \textit{soft-real-time} in cui un occasionale sforamento è
1868 ritenuto accettabile.} in cui è vitale che i processi che devono essere
1869 eseguiti in un determinato momento non debbano aspettare la conclusione di
1870 altri processi che non hanno questa necessità, ha introdotto il concetto di
1871 \textsl{priorità assoluta}, chimata anche \textsl{priorità statica}, in
1872 contrapposizione con la normale priorità dinamica.
1874 Il concetto di prorità assoluta dice che quando due processi si contendono
1875 l'esecuzione, vince sempre quello con la priorità assoluta più alta, anche,
1876 grazie al \textit{prehemptive scheduling}, se l'altro è in esecuzione.
1877 Ovviamente questo avviene solo per i processi che sono pronti per essere
1878 eseguiti (cioè nello stato \textit{runnable}\footnote{lo stato di un processo
1879 è riportato nel campo \texttt{STAT} dell'output del comando \cmd{ps},
1880 abbiamo già visto che lo stato di \textit{zombie} è indicato con \texttt{Z},
1881 gli stati \textit{runnable}, \textit{sleep} e di I/O (\textit{uninteruttible
1882 sleep}) sono invece indicati con \texttt{R}, \texttt{S} e \texttt{D}.}),
1883 la priorità assoluta viene invece ignorata per quelli che sono bloccati su una
1884 richiesta di I/O o in stato di \textit{sleep}.
1886 Questa viene in genere indicata con un numero
1891 \subsection{Il meccanismo di \textit{scheduling} standard}
1892 \label{sec:proc_sched_stand}
1894 In Linux tutti i processi hanno sostanzialmente la stessa priorità; benché sia
1895 possibile specificare una priorità assoluta secondo lo standard POSIX
1896 (argomento che tratteremo più avanti) l'uso comune segue quello che è il
1897 meccanismo tradizionale con cui i sistemi
1899 \subsection{Il meccanismo di \textit{scheduling real-time}}
1900 \label{sec:proc_real_time}
1906 \section{Problematiche di programmazione multitasking}
1907 \label{sec:proc_multi_prog}
1909 Benché i processi siano strutturati in modo da apparire il più possibile come
1910 indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
1911 occorre tenere conto di una serie di problematiche che normalmente non
1912 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
1913 programma alla volta.
1915 Pur essendo questo argomento di carattere generale, ci è parso opportuno
1916 introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
1917 in capitoli successivi, in questa sezione conclusiva del capitolo in cui
1918 abbiamo affrontato la gestione dei processi.
1921 \subsection{Le operazioni atomiche}
1922 \label{sec:proc_atom_oper}
1924 La nozione di \textsl{operazione atomica} deriva dal significato greco della
1925 parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
1926 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
1927 che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
1928 di interruzione in una fase intermedia.
1930 In un ambiente multitasking il concetto è essenziale, dato che un processo può
1931 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
1932 altro processo o dalla ricezione di un segnale; occorre pertanto essere
1933 accorti nei confronti delle possibili \textit{race condition} (vedi
1934 \secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in
1935 cui non erano ancora state completate.
1937 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
1938 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
1939 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
1940 \capref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
1941 \secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
1942 funzioni di libreria per compiere le operazioni necessarie è garanzia
1943 sufficiente di atomicità in quanto le system call con cui esse sono realizzate
1944 non possono essere interrotte (o subire interferenze pericolose) da altri
1947 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
1948 stesso processo, e pure alcune system call, possono essere interrotti in
1949 qualunque momento, e le operazioni di un eventuale \textit{signal handler}
1950 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
1951 il solo accesso o l'assegnazione di una variabile possono non essere più
1952 operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}).
1954 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
1955 il cui accesso è assicurato essere atomico. In pratica comunque si può
1956 assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
1957 \type{int}, gli altri interi di dimensione inferiore ed i puntatori sono
1958 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
1959 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
1960 le strutture. In tutti questi casi è anche opportuno marcare come
1961 \type{volatile} le variabili che possono essere interessate ad accesso
1962 condiviso, onde evitare problemi con le ottimizzazioni del codice.
1965 \subsection{Le \textit{race condition} e i \textit{deadlock}}
1966 \label{sec:proc_race_cond}
1968 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
1969 diversi operano su una risorsa comune, ed in cui il risultato viene a
1970 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
1971 tipico è quello di un'operazione che viene eseguita da un processo in più
1972 passi, e può essere compromessa dall'intervento di un altro processo che
1973 accede alla stessa risorsa quando ancora non tutti i passi sono stati
1976 Dato che in un sistema multitasking ogni processo può essere interrotto in
1977 qualunque momento per farne subentrare un'altro in esecuzione, niente può
1978 assicurare un preciso ordine di esecuzione fra processi diversi o che una
1979 sezione di un programma possa essere eseguita senza interruzioni da parte di
1980 altri. Queste situazioni comportano pertanto errori estremamente subdoli e
1981 difficili da tracciare, in quanto nella maggior parte dei casi tutto
1982 funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
1984 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
1985 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
1986 gli adeguati provvedimenti per far si che non si verifichino. Casi tipici di
1987 \textit{race condition} si hanno quando diversi processi accedono allo stesso
1988 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
1989 condivisa. In questi casi, se non si dispone della possibilità di eseguire
1990 atomicamente le operazioni necessarie, occorre che quelle parti di codice in
1991 cui si compiono le operazioni sulle risorse condivise (le cosiddette
1992 \textsl{sezioni critiche}) del programma, siano opportunamente protette da
1993 meccanismi di sincronizzazione (torneremo su queste problematiche di questo
1994 tipo in \secref{sec:ipc_semaph}).
1996 Un caso particolare di \textit{race condition} sono poi i cosiddetti
1997 \textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
1998 completo di un servizio, e non il fallimento di una singola operazione.
1999 L'esempio tipico di una situazione che può condurre ad un \textit{deadlock} è
2000 quello in cui un flag di ``occupazione'' viene rilasciato da un evento
2001 asincrono (come un segnale o un altro processo) fra il momento in cui lo si è
2002 controllato (trovandolo occupato) e la successiva operazione di attesa per lo
2003 sblocco. In questo caso, dato che l'evento di sblocco del flag è avvenuto
2004 senza che ce ne accorgessimo proprio fra il controllo e la messa in attesa,
2005 quest'ultima diventerà perpetua (da cui il nome di \textit{deadlock}).
2007 In tutti questi casi è di fondamentale importanza il concetto di atomicità
2008 visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere
2009 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
2010 eseguire in maniera atomica le operazioni necessarie.
2013 \subsection{Le funzioni rientranti}
2014 \label{sec:proc_reentrant}
2016 Si dice \textsl{rientrante} una funzione che può essere interrotta in
2017 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
2018 un altro thread di esecuzione senza che questo comporti nessun problema
2019 nell'esecuzione della stessa. La problematica è comune nella programmazione
2020 multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare
2021 delle funzioni all'interno dei manipolatori dei segnali.
2023 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
2024 queste infatti vengono allocate nello stack, e un'altra invocazione non fa
2025 altro che allocarne un'altra copia. Una funzione può non essere rientrante
2026 quando opera su memoria che non è nello stack. Ad esempio una funzione non è
2027 mai rientrante se usa una variabile globale o statica.
2029 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
2030 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
2031 ogni volta e ritornato indietro la funzione può essere rientrante, se invece
2032 esso viene individuato dalla funzione stessa, due chiamate alla stessa
2033 funzione potranno interferire quando entrambe faranno riferimento allo stesso
2034 oggetto. Allo stesso modo una funzione può non essere rientrante se usa e
2035 modifica un oggetto che le viene fornito dal chiamante: due chiamate possono
2036 interferire se viene passato lo stesso oggetto; in tutti questi casi occorre
2037 molta cura da parte del programmatore.
2039 In genere le funzioni di libreria non sono rientranti, molte di esse ad
2040 esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
2041 disposizione due macro di compilatore, \macro{\_REENTRANT} e
2042 \macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
2043 varie funzioni di libreria, che sono identificate aggiungendo il suffisso
2044 \code{\_r} al nome della versione normale.
2048 %%% Local Variables:
2050 %%% TeX-master: "gapil"