Forzo un commit
[gapil.git] / prochand.tex
1 \chapter{La gestione dei processi}
2 \label{cha:process_handling}
3
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.
7
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.
15
16
17 \section{Introduzione}
18 \label{sec:proc_gen}
19
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
24 gestione.
25
26
27 \subsection{L'architettura della gestione dei processi}
28 \label{sec:proc_hierarchy}
29
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, 
36 \acr{pid}.
37
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.
44
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.
52
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.
62
63 \begin{figure}[!htb]
64   \footnotesize
65 \begin{verbatim}
66 [piccardi@gont piccardi]$ pstree -n 
67 init-+-keventd
68      |-kapm-idled
69      |-kreiserfsd
70      |-portmap
71      |-syslogd
72      |-klogd
73      |-named
74      |-rpc.statd
75      |-gpm
76      |-inetd
77      |-junkbuster
78      |-master-+-qmgr
79      |        `-pickup
80      |-sshd
81      |-xfs
82      |-cron
83      |-bash---startx---xinit-+-XFree86
84      |                       `-WindowMaker-+-ssh-agent
85      |                                     |-wmtime
86      |                                     |-wmmon
87      |                                     |-wmmount
88      |                                     |-wmppp
89      |                                     |-wmcube
90      |                                     |-wmmixer
91      |                                     |-wmgtemp
92      |                                     |-wterm---bash---pstree
93      |                                     `-wterm---bash-+-emacs
94      |                                                    `-man---pager
95      |-5*[getty]
96      |-snort
97      `-wwwoffled
98 \end{verbatim} %$
99   \caption{L'albero dei processi, così come riportato dal comando
100     \cmd{pstree}.}
101   \label{fig:proc_tree}
102 \end{figure}
103
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 speciali che pur comparendo come
107   figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
108   direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.).} si
109 possono classificare i processi con la relazione padre/figlio in
110 un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
111 organizzati in un albero di directory (si veda
112 \secref{sec:file_organization}); in \curfig\ si è mostrato il risultato del
113 comando \cmd{pstree} che permette di visualizzare questa struttura, alla cui
114 base c'è \cmd{init} che è progenitore di tutti gli altri processi.
115
116 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
117 \textit{process table}; per ciascun processo viene mantenuta una voce nella
118 tabella dei processi costituita da una struttura \type{task\_struct}, che
119 contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
120 usate a questo scopo sono dichiarate nell'header file \file{linux/sched.h}, ed
121 uno schema semplificato, che riporta la struttura delle principali informazioni
122 contenute nella \type{task\_struct} (che in seguito incontreremo a più
123 riprese), è mostrato in \nfig.
124
125 \begin{figure}[htb]
126   \centering
127   \includegraphics[width=13cm]{img/task_struct}
128   \caption{Schema semplificato dell'architettura delle strutture usate dal
129     kernel nella gestione dei processi.}
130   \label{fig:proc_task_struct}
131 \end{figure}
132
133
134 Come accennato in \secref{sec:intro_unix_struct} è lo \textit{scheduler} che
135 decide quale processo mettere in esecuzione; esso viene eseguito ad ogni
136 system call ed ad ogni interrupt,\footnote{più in una serie di altre
137   occasioni. NDT completare questa parte.} (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}, ed il
141 cui valore è espresso in Hertz.\footnote{Il valore usuale di questa costante è
142   100, per tutte le architetture eccetto l'alpha, per la quale è 1000. Occorre
143   fare attenzione a non confondere questo valore con quello dei clock tick
144   (vedi \secref{sec:sys_unix_time}).}
145 %Si ha cioè un interrupt dal timer ogni centesimo di secondo.
146
147 Ogni volta che viene eseguito, lo \textit{scheduler} effettua il calcolo delle
148 priorità dei vari processi attivi (torneremo su questo in
149 \secref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
150 esecuzione fino alla successiva invocazione.
151
152
153 \subsection{Una panoramica sulle funzioni fondamentali}
154 \label{sec:proc_handling_intro}
155
156 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
157 una system call, Linux però usa un'altra nomenclatura, e la funzione
158 \func{fork} è basata a sua volta sulla system call \func{\_\_clone}, che viene
159 usata anche per generare i \textit{thread}.  Il processo figlio creato dalla
160 \func{fork} è una copia identica del processo processo padre, ma ha nuovo
161 \acr{pid} e viene eseguito in maniera indipendente (le differenze fra padre e
162 figlio sono affrontate in dettaglio in \secref{sec:proc_fork}).
163
164 Se si vuole che il processo padre si fermi fino alla conclusione del processo
165 figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
166 funzione \func{wait} o la funzione \func{waitpid} (si veda
167 \secref{sec:proc_wait}); queste funzioni restituiscono anche un'informazione
168 abbastanza limitata sulle cause della terminazione del processo figlio.
169
170 Quando un processo ha concluso il suo compito o ha incontrato un errore non
171 risolvibile esso può essere terminato con la funzione \func{exit} (si veda
172 quanto discusso in \secref{sec:proc_conclusion}). La vita del processo però
173 termina solo quando la notifica della sua conclusione viene ricevuta dal
174 processo padre, a quel punto tutte le risorse allocate nel sistema ad esso
175 associate vengono rilasciate.
176
177 Avere due processi che eseguono esattamente lo stesso codice non è molto
178 utile, normalmente si genera un secondo processo per affidargli l'esecuzione
179 di un compito specifico (ad esempio gestire una connessione dopo che questa è
180 stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
181 quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
182 coi processi che è la \func{exec}.
183
184 Il programma che un processo sta eseguendo si chiama immagine del processo (o
185 \textit{process image}), le funzioni della famiglia \func{exec} permettono di
186 caricare un'altro programma da disco sostituendo quest'ultimo all'immagine
187 corrente; questo fa sì che l'immagine precedente venga completamente
188 cancellata. Questo significa che quando il nuovo programma esce, anche il
189 processo termina, e non si può tornare alla precedente immagine.
190
191 Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
192 particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
193 prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
194 non ritorna mai (in quanto con essa viene eseguito un altro programma).
195
196
197
198 \section{Le funzioni di base}% della gestione dei processi}
199 \label{sec:proc_handling}
200
201 In questa sezione tratteremo le problematiche della gestione dei processi
202 all'interno del sistema, illustrandone tutti i dettagli.  Inizieremo con le
203 funzioni elementari che permettono di leggerne gli identificatori, per poi
204 passare alla spiegazione delle funzioni base che si usano per la creazione e
205 la terminazione dei processi, e per la messa in esecuzione degli altri
206 programmi.
207
208
209 \subsection{Gli identificatori dei processi}
210 \label{sec:proc_pid}
211
212 Come accennato nell'introduzione, ogni processo viene identificato dal sistema
213 da un numero identificativo unico, il \textit{process id} o \acr{pid};
214 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
215 intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
216 \ctyp{int}).
217
218 Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
219 processo viene creato, fino ad un limite che, essendo il \acr{pid} un numero
220 positivo memorizzato in un intero a 16 bit, arriva ad un massimo di 32767.
221 Oltre questo valore l'assegnazione riparte dal numero più basso disponibile a
222 partire da un minimo di 300,\footnote{questi valori sono definiti dalla macro
223   \macro{PID\_MAX} in \file{threads.h} e direttamente in \file{fork.c} nei
224   sorgenti del kernel.} che serve a riservare i \acr{pid} più bassi ai processi
225 eseguiti dal direttamente dal kernel.  Per questo motivo, come visto in
226 \secref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha sempre il
227 \acr{pid} uguale a uno.
228
229 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
230 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
231 \textit{parent process id}).  Questi due identificativi possono essere
232 ottenuti da programma usando le funzioni:
233 \begin{functions}
234   \headdecl{sys/types.h} \headdecl{unistd.h} \funcdecl{pid\_t getpid(void)}
235   Restituisce il \acr{pid} del processo corrente.  \funcdecl{pid\_t
236     getppid(void)} Restituisce il \acr{pid} del padre del processo corrente.
237
238 \bodydesc{Entrambe le funzioni non riportano condizioni di errore.}
239 \end{functions}
240 \noindent esempi dell'uso di queste funzioni sono riportati in
241 \figref{fig:proc_fork_code}, nel programma di esempio \file{ForkTest.c}.
242
243 Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
244 candidato per generare ulteriori indicatori associati al processo di cui
245 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
246 funzione \func{tmpname} (si veda \secref{sec:file_temp_file}) usa il \acr{pid}
247 per generare un pathname univoco, che non potrà essere replicato da un'altro
248 processo che usi la stessa funzione.
249
250 Tutti i processi figli dello stesso processo padre sono detti
251 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
252   sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
253 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
254 \secref{cha:session}, dove esamineremo gli altri identificativi associati ad
255 un processo e le varie relazioni fra processi utilizzate per definire una
256 sessione.
257
258 Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
259 \secref{sec:sess_proc_group}, relativi al controllo di sessione), ad ogni
260 processo vengono associati degli altri identificatori che vengono usati per il
261 controllo di accesso.  Questi servono per determinare se un processo può
262 eseguire o meno le operazioni richieste, a seconda dei privilegi e
263 dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
264 affrontato in dettaglio in \secref{sec:proc_perms}.
265
266
267 \subsection{La funzione \func{fork}}
268 \label{sec:proc_fork}
269
270 La funzione \func{fork} è la funzione fondamentale della gestione dei
271 processi: come si è detto l'unico modo di creare un nuovo processo è
272 attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale
273 tutte le volte che si devono scrivere programmi che usano il multitasking.  Il
274 prototipo della funzione è:
275 \begin{functions}
276   \headdecl{sys/types.h} 
277   \headdecl{unistd.h} 
278   \funcdecl{pid\_t fork(void)} 
279   Crea un nuovo processo.
280   
281   \bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
282     zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
283     errore; \var{errno} può assumere i valori:
284   \begin{errlist}
285   \item[\macro{EAGAIN}] non ci sono risorse sufficienti per creare un'altro
286     processo (per allocare la tabella delle pagine e le strutture del task) o
287     si è esaurito il numero di processi disponibili.
288   \item[\macro{ENOMEM}] non è stato possibile allocare la memoria per le
289     strutture necessarie al kernel per creare il nuovo processo.
290   \end{errlist}}
291 \end{functions}
292
293 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
294 il processo figlio continuano ad essere eseguiti normalmente all'istruzione
295 seguente la \func{fork}; il processo figlio è però una copia del padre, e
296 riceve una copia dei segmenti di testo, stack e dati (vedi
297 \secref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
298 padre. Si tenga presente però che la memoria è copiata, non condivisa,
299 pertanto padre e figlio vedono variabili diverse.
300
301 Per quanto riguarda la gestione della memoria in generale il segmento di
302 testo, che è identico, è condiviso e tenuto in read-only per il padre e per i
303 figli. Per gli altri segmenti Linux utilizza la tecnica del \textit{copy on
304   write}\index{copy on write}; questa tecnica comporta che una pagina di
305 memoria viene effettivamente copiata per il nuovo processo solo quando ci
306 viene effettuata sopra una scrittura (e si ha quindi una reale differenza fra
307 padre e figlio). In questo modo si rende molto più efficiente il meccanismo
308 della creazione di un nuovo processo, non essendo più necessaria la copia di
309 tutto lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di
310 memoria che sono state modificate, e solo al momento della modifica stessa.
311
312 La differenza che si ha nei due processi è che nel processo padre il valore di
313 ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
314 nel figlio è zero; in questo modo il programma può identificare se viene
315 eseguito dal padre o dal figlio.  Si noti come la funzione \func{fork} ritorni
316 \textbf{due} volte: una nel padre e una nel figlio. 
317
318 La scelta di questi valori di ritorno non è casuale, un processo infatti può
319 avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
320 permette di identificare quello appena creato; al contrario un figlio ha
321 sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
322 \func{getppid}, vedi \secref{sec:proc_pid}) per cui si usa il valore nullo,
323 che non è il \acr{pid} di nessun processo.
324
325 \begin{figure}[!htb]
326   \footnotesize
327   \begin{lstlisting}{}
328 #include <errno.h>       /* error definitions and routines */ 
329 #include <stdlib.h>      /* C standard library */
330 #include <unistd.h>      /* unix standard library */
331 #include <stdio.h>       /* standard I/O library */
332 #include <string.h>      /* string functions */
333
334 /* Help printing routine */
335 void usage(void);
336
337 int main(int argc, char *argv[])
338 {
339 /* 
340  * Variables definition  
341  */
342     int nchild, i;
343     pid_t pid;
344     int wait_child  = 0;
345     int wait_parent = 0;
346     int wait_end    = 0;
347     ...        /* handling options */
348     nchild = atoi(argv[optind]);
349     printf("Test for forking %d child\n", nchild);
350     /* loop to fork children */
351     for (i=0; i<nchild; i++) {
352         if ( (pid = fork()) < 0) { 
353             /* on error exit */ 
354             printf("Error on %d child creation, %s\n", i+1, strerror(errno));
355             exit(-1); 
356         }
357         if (pid == 0) {   /* child */
358             printf("Child %d successfully executing\n", ++i);
359             if (wait_child) sleep(wait_child);
360             printf("Child %d, parent %d, exiting\n", i, getppid());
361             exit(0);
362         } else {          /* parent */
363             printf("Spawned %d child, pid %d \n", i+1, pid);
364             if (wait_parent) sleep(wait_parent);
365             printf("Go to next child \n");
366         }
367     }
368     /* normal exit */
369     if (wait_end) sleep(wait_end);
370     return 0;
371 }
372   \end{lstlisting}
373   \caption{Esempio di codice per la creazione di nuovi processi.}
374   \label{fig:proc_fork_code}
375 \end{figure}
376
377 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
378 sono già troppi processi nel sistema (il che di solito è sintomo che
379 qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
380 sul numero totale di processi permessi all'utente (vedi
381 \secref{sec:sys_resource_limit}, ed in particolare
382 \tabref{tab:sys_rlimit_values}).
383
384 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
385 quella in cui all'interno di un programma si creano processi figli cui viene
386 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
387 ne esegue un'altra. È il caso tipico dei server (il modello
388 \textit{client-server} è illustrato in \secref{sec:net_cliserv}) di rete in
389 cui il padre riceve ed accetta le richieste da parte dei client, per ciascuna
390 delle quali pone in esecuzione un figlio che è incaricato di fornire il
391 servizio.
392
393 La seconda modalità è quella in cui il processo vuole eseguire un altro
394 programma; questo è ad esempio il caso della shell. In questo caso il processo
395 crea un figlio la cui unica operazione è quella fare una \func{exec} (di cui
396 parleremo in \secref{sec:proc_exec}) subito dopo la \func{fork}.
397
398 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
399 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
400 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
401 scelto di mantenere questa separazione, dato che, come per la prima modalità
402 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
403 aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
404 seconda modalità d'uso, avere le due funzioni separate permette al figlio di
405 cambiare gli attributi del processo (maschera dei segnali, redirezione
406 dell'output, identificatori) prima della \func{exec}, rendendo così
407 relativamente facile intervenire sulle le modalità di esecuzione del nuovo
408 programma.
409
410 In \figref{fig:proc_fork_code} si è riportato il corpo del codice del
411 programma di esempio \cmd{forktest}, che ci permette di illustrare molte
412 caratteristiche dell'uso della funzione \func{fork}. Il programma permette di
413 creare un numero di figli specificato da linea di comando, e prende anche
414 alcune opzioni per indicare degli eventuali tempi di attesa in secondi
415 (eseguiti tramite la funzione \func{sleep}) per il padre ed il figlio (con
416 \cmd{forktest -h} si ottiene la descrizione delle opzioni); il codice
417 completo, compresa la parte che gestisce le opzioni a riga di comando, è
418 disponibile nel file \file{ForkTest.c}, distribuito insieme agli altri
419 sorgenti degli esempi su \href{http://gapil.firenze.linux.it/gapil_source.tgz}
420 {\texttt{http://gapil.firenze.linux.it/gapil\_source.tgz}}.
421
422 Decifrato il numero di figli da creare, il ciclo principale del programma
423 (\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
424 controllando il successo della chiamata a \func{fork} (\texttt{\small
425   25--29}); ciascun figlio (\texttt{\small 31--34}) si limita a stampare il
426 suo numero di successione, eventualmente attendere il numero di secondi
427 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
428 (\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
429 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
430 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
431 periodo di attesa.
432
433 Se eseguiamo il comando senza specificare attese (come si può notare in
434 \texttt{\small 17--19} i valori predefiniti specificano di non attendere),
435 otterremo come output sul terminale:
436
437 \footnotesize
438 \begin{verbatim}
439 [piccardi@selidor sources]$ ./forktest 3
440 Process 1963: forking 3 child
441 Spawned 1 child, pid 1964 
442 Child 1 successfully executing
443 Child 1, parent 1963, exiting
444 Go to next child 
445 Spawned 2 child, pid 1965 
446 Child 2 successfully executing
447 Child 2, parent 1963, exiting
448 Go to next child 
449 Child 3 successfully executing
450 Child 3, parent 1963, exiting
451 Spawned 3 child, pid 1966 
452 Go to next child 
453 \end{verbatim} %$
454 \normalsize
455
456 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
457 si può dire quale processo fra il padre ed il figlio venga eseguito per
458 primo\footnote{a partire dal kernel 2.5.2-pre10 è stato introdotto il nuovo
459   scheduler di Ingo Molnar che esegue sempre per primo il figlio; per
460   mantenere la portabilità è opportuno non fare comunque affidamento su questo
461   comportamento.} dopo la chiamata a \func{fork}; dall'esempio si può notare
462 infatti come nei primi due cicli sia stato eseguito per primo il padre (con la
463 stampa del \acr{pid} del nuovo processo) per poi passare all'esecuzione del
464 figlio (completata con i due avvisi di esecuzione ed uscita), e tornare
465 all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
466 mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
467 e poi il padre.
468
469 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
470 scheduling usato dal kernel, dalla particolare situazione in si trova la
471 macchina al momento della chiamata, risultando del tutto impredicibile.
472 Eseguendo più volte il programma di prova e producendo un numero diverso di
473 figli, si sono ottenute situazioni completamente diverse, compreso il caso in
474 cui il processo padre ha eseguito più di una \func{fork} prima che uno dei
475 figli venisse messo in esecuzione.
476
477 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
478 istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
479 essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
480 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
481 rischio di incorrere nelle cosiddette 
482 \textit{race condition}\index{race condition} 
483 (vedi \secref{sec:proc_race_cond}).
484
485 Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
486 processi completamente separati, le modifiche delle variabili nei processi
487 figli (come l'incremento di \var{i} in \texttt{\small 31}) sono visibili solo
488 a loro (ogni processo vede solo la propria copia della memoria), e non hanno
489 alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed
490 in eventuali altri processi figli che eseguano lo stesso codice).
491
492 Un secondo aspetto molto importante nella creazione dei processi figli è
493 quello dell'interazione dei vari processi con i file; per illustrarlo meglio
494 proviamo a redirigere su un file l'output del nostro programma di test, quello
495 che otterremo è:
496
497 \footnotesize
498 \begin{verbatim}
499 [piccardi@selidor sources]$ ./forktest 3 > output
500 [piccardi@selidor sources]$ cat output
501 Process 1967: forking 3 child
502 Child 1 successfully executing
503 Child 1, parent 1967, exiting
504 Test for forking 3 child
505 Spawned 1 child, pid 1968 
506 Go to next child 
507 Child 2 successfully executing
508 Child 2, parent 1967, exiting
509 Test for forking 3 child
510 Spawned 1 child, pid 1968 
511 Go to next child 
512 Spawned 2 child, pid 1969 
513 Go to next child 
514 Child 3 successfully executing
515 Child 3, parent 1967, exiting
516 Test for forking 3 child
517 Spawned 1 child, pid 1968 
518 Go to next child 
519 Spawned 2 child, pid 1969 
520 Go to next child 
521 Spawned 3 child, pid 1970 
522 Go to next child 
523 \end{verbatim}
524 \normalsize
525 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
526
527 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
528 in gran dettaglio in \capref{cha:file_unix_interface} e in
529 \secref{cha:files_std_interface}. Qui basta accennare che si sono usate le
530 funzioni standard della libreria del C che prevedono l'output bufferizzato; e
531 questa bufferizzazione (trattata in dettaglio in \secref{sec:file_buffering})
532 varia a seconda che si tratti di un file su disco (in cui il buffer viene
533 scaricato su disco solo quando necessario) o di un terminale (nel qual caso il
534 buffer viene scaricato ad ogni carattere di a capo).
535
536 Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
537 buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
538 l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
539 non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
540 ogni figlio riceve una copia della memoria del padre, esso riceverà anche
541 quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
542 padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
543 figlio, troveremo nel file anche tutto quello che il processo padre aveva
544 scritto prima della sua creazione.  E alla fine del file (dato che in questo
545 caso il padre esce per ultimo) troveremo anche l'output completo del padre.
546
547 L'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i file,
548 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
549 solo processi diversi possono scrivere in contemporanea sullo stesso file
550 (l'argomento della condivisione dei file è trattato in dettaglio in
551 \secref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
552 le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
553 i processi figli.
554
555 Quello che succede è che quando lo standard output del padre viene rediretto,
556 lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha
557 la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione
558 \func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file
559 descriptor aperti nel padre, il che comporta che padre e figli condividono le
560 stesse voci della \textit{file table} (per la spiegazione di questi termini si
561 veda \secref{sec:file_sharing}) e fra cui c'è anche la posizione corrente nel
562 file.
563
564 In questo modo se un processo scrive sul file aggiornerà la posizione corrente
565 sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
566 \textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
567 casi come quello appena mostrato in cui diversi processi scrivono sullo stesso
568 file, che l'output successivo di un processo vada a sovrapporsi a quello dei
569 precedenti: l'output potrà risultare mescolato, ma non ci saranno parti
570 perdute per via di una sovrascrittura.
571
572 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
573 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
574 scrivono sullo stesso file (un caso tipico è la shell quando lancia un
575 programma, il cui output va sullo standard output). 
576
577 In questo modo, anche se l'output viene rediretto, il padre potrà sempre
578 continuare a scrivere in coda a quanto scritto dal figlio in maniera
579 automatica; se così non fosse ottenere questo comportamento sarebbe
580 estremamente complesso necessitando di una qualche forma di comunicazione fra
581 i due processi per far riprendere al padre la scrittura al punto giusto.
582
583 In generale comunque non è buona norma far scrivere più processi sullo stesso
584 file senza una qualche forma di sincronizzazione in quanto, come visto anche
585 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
586 una sequenza impredicibile. Per questo le modalità con cui in genere si usano
587 i file dopo una \func{fork} sono sostanzialmente due:
588 \begin{enumerate}
589 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
590   è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
591   della posizione corrente dopo eventuali operazioni di lettura e scrittura
592   effettuate dal figlio è automatica.
593 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
594   ciascuno dei due processi deve chiudere i file che non gli servono una volta
595   che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
596 \end{enumerate}
597
598 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
599 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
600 comune dopo l'esecuzione di una \func{fork} è la seguente:
601 \begin{itemize*}
602 \item i file aperti e gli eventuali flag di \textit{close-on-exec} impostati
603   (vedi \secref{sec:proc_exec} e \secref{sec:file_fcntl}).
604 \item gli identificatori per il controllo di accesso: l'\textsl{userid reale},
605   il \textsl{groupid reale}, l'\textsl{userid effettivo}, il \textsl{groupid
606     effettivo} ed i \textit{groupid supplementari} (vedi
607   \secref{sec:proc_access_id}).
608 \item gli identificatori per il controllo di sessione: il \textit{process
609     groupid} e il \textit{session id} ed il terminale di controllo (vedi
610   \secref{sec:sess_proc_group}).
611 \item la directory di lavoro e la directory radice (vedi
612   \secref{sec:file_work_dir} e \secref{sec:file_chroot}).
613 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
614 \item la maschera dei segnali bloccati (vedi \secref{sec:sig_sigmask}) e le
615   azioni installate (vedi \secref{sec:sig_gen_beha}).
616 \item i segmenti di memoria condivisa agganciati al processo (vedi
617   \secref{sec:ipc_sysv_shm}).
618 \item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
619 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
620 \end{itemize*}
621 le differenze fra padre e figlio dopo la \func{fork} invece sono:
622 \begin{itemize*}
623 \item il valore di ritorno di \func{fork}.
624 \item il \acr{pid} (\textit{process id}). 
625 \item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
626   impostato al \acr{pid} del padre.
627 \item i valori dei tempi di esecuzione della struttura \var{tms} (vedi
628   \secref{sec:sys_cpu_times}) che nel figlio sono posti a zero.
629 \item i \textit{file lock} (vedi \secref{sec:file_locking}), che non
630   vengono ereditati dal figlio.
631 \item gli allarmi ed i segnali pendenti (vedi \secref{sec:sig_gen_beha}), che
632   per il figlio vengono cancellati.
633 \end{itemize*}
634
635
636 \subsection{La funzione \func{vfork}}
637 \label{sec:proc_vfork}
638
639 La funzione \func{vfork} è esattamente identica a \func{fork} ed ha la stessa
640 semantica e gli stessi errori; la sola differenza è che non viene creata la
641 tabella delle pagine né la struttura dei task per il nuovo processo. Il
642 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
643 \func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
644 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
645 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
646
647 Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
648 \func{fork} comportava anche la copia completa del segmento dati del processo
649 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
650 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
651 venne introdotta in BSD per migliorare le prestazioni.
652
653 Dato che Linux supporta il \textit{copy on write}\index{copy on write} la
654 perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
655 funzione (che resta un caso speciale della funzione \func{clone}), è
656 deprecato; per questo eviteremo di trattarla ulteriormente.
657
658
659 \subsection{La conclusione di un processo.}
660 \label{sec:proc_termination}
661
662 In \secref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
663 chiudere un programma, ma dall'interno del programma stesso; avendo a che fare
664 con un sistema multitasking resta da affrontare l'argomento dal punto di vista
665 di come il sistema gestisce la conclusione dei processi.
666
667 Abbiamo visto in \secref{sec:proc_conclusion} le tre modalità con cui un
668 programma viene terminato in maniera normale: la chiamata di \func{exit} (che
669 esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
670 dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
671 chiamata ad \func{\_exit} (che passa direttamente alle operazioni di
672 terminazione del processo da parte del kernel).
673
674 Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
675 modalità di conclusione anomala; queste sono in sostanza due: il programma può
676 chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
677 terminato da un segnale.  In realtà anche la prima modalità si riconduce alla
678 seconda, dato che \func{abort} si limita a generare il segnale
679 \macro{SIGABRT}.
680
681 Qualunque sia la modalità di conclusione di un processo, il kernel esegue
682 comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
683 memoria che stava usando, e così via; l'elenco completo delle operazioni
684 eseguite alla chiusura di un processo è il seguente:
685 \begin{itemize*}
686 \item tutti i file descriptor sono chiusi.
687 \item viene memorizzato lo stato di terminazione del processo.
688 \item ad ogni processo figlio viene assegnato un nuovo padre (in genere
689   \cmd{init}).
690 \item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi
691   \secref{sec:sig_sigchld}).
692 \item se il processo è un leader di sessione viene mandato un segnale di
693   \macro{SIGHUP} a tutti i processi in background e il terminale di
694   controllo viene disconnesso (vedi \secref{sec:sess_xxx}).
695 \item se la conclusione di un processo rende orfano un \textit{process
696     group} ciascun membro del gruppo viene bloccato, e poi gli vengono
697   inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}
698   (vedi \secref{sec:sess_ctrl_term}).
699 \end{itemize*}
700
701 Oltre queste operazioni è però necessario poter disporre di un meccanismo
702 ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
703 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
704 scelto consiste nel riportare lo stato di terminazione (il cosiddetto
705 \textit{termination status}) al processo padre.
706
707 Nel caso di conclusione normale, abbiamo visto in \secref{sec:proc_conclusion}
708 che lo stato di uscita del processo viene caratterizzato tramite il valore del
709 cosiddetto \textit{exit status}, cioè il valore passato alle funzioni
710 \func{exit} o \func{\_exit} (o dal valore di ritorno per \func{main}).  Ma se
711 il processo viene concluso in maniera anomala il programma non può specificare
712 nessun \textit{exit status}, ed è il kernel che deve generare autonomamente il
713 \textit{termination status} per indicare le ragioni della conclusione anomala.
714
715 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
716 quello che contraddistingue lo stato di chiusura del processo e viene
717 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
718 \secref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
719 il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
720 secondo.
721
722 La scelta di riportare al padre lo stato di terminazione dei figli, pur
723 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
724 alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
725 che sia così alla sua conclusione, dato che il padre potrebbe essere già
726 terminato (si potrebbe avere cioè quello che si chiama un processo
727 \textsl{orfano}). 
728
729 Questa complicazione viene superata facendo in modo che il processo orfano
730 venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
731 termina, il kernel controlla se è il padre di altri processi in esecuzione: in
732 caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
733 con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
734 avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
735 cui riportare il suo stato di terminazione.  Come verifica di questo
736 comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
737 ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
738
739 \footnotesize
740 \begin{verbatim}
741 [piccardi@selidor sources]$ ./forktest -c2 3
742 Process 1972: forking 3 child
743 Spawned 1 child, pid 1973 
744 Child 1 successfully executing
745 Go to next child 
746 Spawned 2 child, pid 1974 
747 Child 2 successfully executing
748 Go to next child 
749 Child 3 successfully executing
750 Spawned 3 child, pid 1975 
751 Go to next child 
752 [piccardi@selidor sources]$ Child 3, parent 1, exiting
753 Child 2, parent 1, exiting
754 Child 1, parent 1, exiting
755 \end{verbatim}
756 \normalsize
757 come si può notare in questo caso il processo padre si conclude prima dei
758 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
759 secondi dopo viene stampato a video anche l'output dei tre figli che
760 terminano, e come si può notare in questo caso, al contrario di quanto visto
761 in precedenza, essi riportano 1 come \acr{ppid}.
762
763 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
764 perché non è detto che il padre possa ricevere immediatamente lo stato di
765 terminazione, quindi il kernel deve comunque conservare una certa quantità di
766 informazioni riguardo ai processi che sta terminando.
767
768 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
769 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
770 dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di terminazione,
771 mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
772 processi che sono terminati, ma il cui stato di terminazione non è stato
773 ancora ricevuto dal padre sono chiamati \textit{zombie}, essi restano presenti
774 nella tabella dei processi ed in genere possono essere identificati
775 dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella colonna che ne
776 indica lo stato (vedi \tabref{tab:proc_proc_states}). Quando il padre
777 effettuerà la lettura dello stato di uscita anche questa informazione, non più
778 necessaria, verrà scartata e la terminazione potrà dirsi completamente
779 conclusa.
780
781 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
782 condizione: lanciamo il comando \cmd{forktest} in background, indicando al
783 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
784 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
785 otterremo:
786
787 \footnotesize
788 \begin{verbatim}
789 [piccardi@selidor sources]$ ps T
790   PID TTY      STAT   TIME COMMAND
791   419 pts/0    S      0:00 bash
792   568 pts/0    S      0:00 ./forktest -e10 3
793   569 pts/0    Z      0:00 [forktest <defunct>]
794   570 pts/0    Z      0:00 [forktest <defunct>]
795   571 pts/0    Z      0:00 [forktest <defunct>]
796   572 pts/0    R      0:00 ps T
797 \end{verbatim} %$
798 \normalsize 
799 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
800 terminazione, i tre processi figli sono ancora presenti pur essendosi
801 conclusi, con lo stato di zombie e l'indicazione che sono stati terminati.
802
803 La possibilità di avere degli zombie deve essere tenuta sempre presente quando
804 si scrive un programma che deve essere mantenuto in esecuzione a lungo e
805 creare molti figli. In questo caso si deve sempre avere cura di far leggere
806 l'eventuale stato di uscita di tutti i figli (in genere questo si fa
807 attraverso un apposito \textit{signal handler}, che chiama la funzione
808 \func{wait}, vedi \secref{sec:sig_sigchld} e \secref{sec:proc_wait}). Questa
809 operazione è necessaria perché anche se gli \textit{zombie} non consumano
810 risorse di memoria o processore, occupano comunque una voce nella tabella dei
811 processi, che a lungo andare potrebbe esaurirsi.
812
813 Si noti che quando un processo adottato da \cmd{init} termina, esso non
814 diviene uno \textit{zombie}; questo perché una delle funzioni di \cmd{init} è
815 appunto quella di chiamare la funzione \func{wait} per i processi cui fa da
816 padre, completandone la terminazione. Questo è quanto avviene anche quando,
817 come nel caso del precedente esempio con \cmd{forktest}, il padre termina con
818 dei figli in stato di zombie: alla sua terminazione infatti tutti i suoi figli
819 (compresi gli zombie) verranno adottati da \cmd{init}, il quale provvederà a
820 completarne la terminazione.
821
822 Si tenga presente infine che siccome gli zombie sono processi già usciti, non
823 c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità di
824 cancellarli dalla tabella dei processi è quella di terminare il processo che
825 li ha generati, in modo che \cmd{init} possa adottarli e provvedere a
826 concluderne la terminazione.
827
828
829 \subsection{Le funzioni \func{wait} e  \func{waitpid}}
830 \label{sec:proc_wait}
831
832 Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
833 consiste nella creazione di programmi di tipo server, in cui un processo
834 principale attende le richieste che vengono poi soddisfatte da una serie di
835 processi figli. Si è già sottolineato al paragrafo precedente come in questo
836 caso diventi necessario gestire esplicitamente la conclusione dei figli onde
837 evitare di riempire di \textit{zombie} la tabella dei processi; le funzioni
838 deputate a questo compito sono sostanzialmente due, \func{wait} e
839 \func{waitpid}. La prima, il cui prototipo è:
840 \begin{functions}
841 \headdecl{sys/types.h}
842 \headdecl{sys/wait.h}
843 \funcdecl{pid\_t wait(int *status)} 
844
845 Sospende il processo corrente finché un figlio non è uscito, o finché un
846 segnale termina il processo o chiama una funzione di gestione. 
847
848 \bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
849   e -1 in caso di errore; \var{errno} può assumere i valori:
850   \begin{errlist}
851   \item[\macro{EINTR}] la funzione è stata interrotta da un segnale.
852   \end{errlist}}
853 \end{functions}
854 \noindent
855 è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
856 processo figlio termina. Se un figlio è già terminato la funzione ritorna
857 immediatamente.
858
859 Al ritorno lo stato di terminazione del processo viene salvato nella
860 variabile puntata da \var{status} e tutte le informazioni relative al
861 processo (vedi \secref{sec:proc_termination}) vengono rilasciate.  Nel
862 caso un processo abbia più figli il valore di ritorno permette di
863 identificare qual'è quello che è uscito.
864
865 Questa funzione ha il difetto di essere poco flessibile, in quanto
866 ritorna all'uscita di un figlio qualunque. Nelle occasioni in cui è
867 necessario attendere la conclusione di un processo specifico occorre
868 predisporre un meccanismo che tenga conto dei processi già terminati, e
869 provveda a ripetere la chiamata alla funzione nel caso il processo
870 cercato sia ancora attivo.
871
872 Per questo motivo lo standard POSIX.1 ha introdotto la funzione \func{waitpid}
873 che effettua lo stesso servizio, ma dispone di una serie di funzionalità più
874 ampie, legate anche al controllo di sessione (si veda
875 \ref{sec:sess_job_control}).  Dato che è possibile ottenere lo stesso
876 comportamento di \func{wait} si consiglia di utilizzare sempre questa
877 funzione, il cui prototipo è:
878 \begin{functions}
879 \headdecl{sys/types.h}
880 \headdecl{sys/wait.h}
881 \funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)} 
882 Attende la conclusione di un processo figlio.
883
884 \bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
885   è stata specificata l'opzione \macro{WNOHANG} e il processo non è uscito e
886   -1 per un errore, nel qual caso \var{errno} assumerà i valori:
887   \begin{errlist}
888   \item[\macro{EINTR}] se non è stata specificata l'opzione \macro{WNOHANG} e
889     la funzione è stata interrotta da un segnale.
890   \item[\macro{ECHILD}] il processo specificato da \param{pid} non esiste o
891     non è figlio del processo chiamante.
892   \end{errlist}}
893 \end{functions}
894
895 Le differenze principali fra le due funzioni sono che \func{wait} si blocca
896 sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la
897 possibilità si specificare un'opzione \macro{WNOHANG} che ne previene il
898 blocco; inoltre \func{waitpid} può specificare quale processo attendere sulla
899 base del valore fornito dall'argomento \param{pid}, secondo lo
900 specchietto riportato in \tabref{tab:proc_waidpid_pid}:
901 \begin{table}[!htb]
902   \centering
903   \footnotesize
904   \begin{tabular}[c]{|c|c|p{8cm}|}
905     \hline
906     \textbf{Valore} & \textbf{Macro} &\textbf{Significato}\\
907     \hline
908     \hline
909     $<-1$& -- & attende per un figlio il cui \textit{process group} (vedi
910     \secref{sec:sess_proc_group}) è uguale al
911     valore assoluto di \var{pid}. \\
912     $-1$ & \macro{WAIT\_ANY} & attende per un figlio qualsiasi, usata in
913     questa maniera è equivalente a \func{wait}.\\ 
914     $0$  & \macro{WAIT\_MYPGRP} & attende per un figlio il cui \textit{process
915     group} è uguale a quello del processo chiamante. \\
916     $>0$ & -- &attende per un figlio il cui \acr{pid} è uguale al
917     valore di \var{pid}.\\
918     \hline
919   \end{tabular}
920   \caption{Significato dei valori del parametro \var{pid} della funzione
921     \func{waitpid}.}
922   \label{tab:proc_waidpid_pid}
923 \end{table}
924
925 Il comportamento di \func{waitpid} può inoltre essere modificato passando
926 delle opportune opzioni tramite l'argomento \param{option}. I valori possibili
927 sono il già citato \macro{WNOHANG}, che previene il blocco della funzione
928 quando il processo figlio non è terminato, e \macro{WUNTRACED}. Quest'ultimo
929 viene generalmente usato per il controllo di sessione, (trattato in
930 \secref{sec:sess_job_control}) in quanto permette di identificare i processi
931 bloccati. La funzione infatti in tal caso ritorna, restituendone il \acr{pid},
932 se c'è un processo figlio che è entrato in stato di sleep (vedi
933 \tabref{tab:proc_proc_states}) di cui non si è ancora letto lo stato (con
934 questa stessa opzione). Il valore dell'opzione deve essere specificato come
935 maschera binaria ottenuta con l'OR delle suddette costanti con zero. In Linux
936 sono previste altre opzioni non standard relative al comportamento con i
937 thread, che saranno trattate in \secref{sec:thread_xxx}.
938
939 La terminazione di un processo figlio è chiaramente un evento asincrono
940 rispetto all'esecuzione di un programma e può avvenire in un qualunque
941 momento. Per questo motivo, come accennato nella sezione precedente, una delle
942 azioni prese dal kernel alla conclusione di un processo è quella di mandare un
943 segnale di \macro{SIGCHLD} al padre. L'azione predefinita (si veda
944 \secref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
945 generazione costituisce il meccanismo di comunicazione asincrona con cui il
946 kernel avverte il processo padre che uno dei suoi figli è terminato.
947
948 In genere in un programma non si vuole essere forzati ad attendere la
949 conclusione di un processo per proseguire, specie se tutto questo serve solo
950 per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}),
951 per questo la modalità più usata per chiamare queste funzioni è quella di
952 utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
953 come gestire \macro{SIGCHLD} con i segnali in \secref{sec:sig_example}). In
954 questo caso infatti, dato che il segnale è generato dalla terminazione di un
955 figlio, avremo la certezza che la chiamata a \func{wait} non si bloccherà.
956
957 \begin{table}[!htb]
958   \centering
959   \footnotesize
960   \begin{tabular}[c]{|c|p{10cm}|}
961     \hline
962     \textbf{Macro} & \textbf{Descrizione}\\
963     \hline
964     \hline
965     \macro{WIFEXITED(s)}   & Condizione vera (valore non nullo) per un processo
966     figlio che sia terminato normalmente. \\
967     \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
968     stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit}
969     o come valore di ritorno di \func{main}). Può essere valutata solo se
970     \macro{WIFEXITED} ha restituito un valore non nullo.\\
971     \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
972     in maniera anomala a causa di un segnale che non è stato catturato (vedi
973     \secref{sec:sig_notification}).\\
974     \macro{WTERMSIG(s)}    & restituisce il numero del segnale che ha causato
975     la terminazione anomala del processo.  Può essere valutata solo se
976     \macro{WIFSIGNALED} ha restituito un valore non nullo.\\
977     \macro{WCOREDUMP(s)}   & Vera se il processo terminato ha generato un
978     file si \textit{core dump}. Può essere valutata solo se
979     \macro{WIFSIGNALED} ha restituito un valore non nullo.\footnote{questa
980     macro non è definita dallo standard POSIX.1, ma è presente come estensione
981     sia in Linux che in altri Unix.}\\
982     \macro{WIFSTOPPED(s)}  & Vera se il processo che ha causato il ritorno di
983     \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato
984     l'opzione \macro{WUNTRACED}. \\
985     \macro{WSTOPSIG(s)}    & restituisce il numero del segnale che ha bloccato
986     il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha
987     restituito un valore non nullo. \\
988     \hline
989   \end{tabular}
990   \caption{Descrizione delle varie macro di preprocessore utilizzabili per 
991     verificare lo stato di terminazione \var{s} di un processo.}
992   \label{tab:proc_status_macro}
993 \end{table}
994
995 Entrambe le funzioni di attesa restituiscono lo stato di terminazione del
996 processo tramite il puntatore \param{status} (se non interessa memorizzare lo
997 stato si può passare un puntatore nullo). Il valore restituito da entrambe le
998 funzioni dipende dall'implementazione, e tradizionalmente alcuni bit (in
999 genere 8) sono riservati per memorizzare lo stato di uscita, e altri per
1000 indicare il segnale che ha causato la terminazione (in caso di conclusione
1001 anomala), uno per indicare se è stato generato un core file, ecc.\footnote{le
1002   definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
1003   questo file non deve mai essere usato direttamente, esso viene incluso
1004   attraverso \file{<sys/wait.h>}.}
1005
1006 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
1007 analizzare lo stato di uscita. Esse sono definite sempre in
1008 \file{<sys/wait.h>} ed elencate in \tabref{tab:proc_status_macro} (si tenga
1009 presente che queste macro prendono come parametro la variabile di tipo
1010 \ctyp{int} puntata da \var{status}).
1011
1012 Si tenga conto che nel caso di conclusione anomala il valore restituito da
1013 \macro{WTERMSIG} può essere confrontato con le costanti definite in
1014 \file{signal.h} ed elencate in \tabref{tab:sig_signal_list}, e stampato usando
1015 le apposite funzioni trattate in \secref{sec:sig_strsignal}.
1016
1017
1018 \subsection{Le funzioni \func{wait3} e \func{wait4}}
1019 \label{sec:proc_wait4}
1020
1021 Linux, seguendo un'estensione di BSD, supporta altre due funzioni per la
1022 lettura dello stato di terminazione di un processo \func{wait3} e
1023 \func{wait4}, analoghe alle precedenti ma che prevedono un ulteriore
1024 parametro attraverso il quale il kernel può restituire al padre informazioni
1025 sulle risorse usate dal processo terminato e dai vari figli.  I prototipi di
1026 queste funzioni, che diventano accessibili definendo la costante
1027 \macro{\_USE\_BSD}, sono:
1028 \begin{functions}
1029   \headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
1030   \headdecl{sys/resource.h} 
1031   
1032   \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
1033     * rusage)}   
1034   È identica a \func{waitpid} sia per comportamento che per i valori dei
1035   parametri, ma restituisce in \param{rusage} un sommario delle risorse usate
1036   dal processo.
1037
1038   \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
1039   Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
1040   ormai deprecata in favore di \func{wait4}.
1041 \end{functions}
1042 \noindent 
1043 la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
1044 utilizzata anche dalla funzione \func{getrusage} (vedi
1045 \secref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
1046 processo; la sua definizione è riportata in \figref{fig:sys_rusage_struct}.
1047
1048
1049 \subsection{Le funzioni \func{exec}}
1050 \label{sec:proc_exec}
1051
1052 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1053 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1054 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1055 processo chiama una di queste funzioni esso viene completamente sostituito dal
1056 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
1057 creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo
1058 heap, i dati ed il testo del processo corrente con un nuovo programma letto da
1059 disco. 
1060
1061 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1062 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1063 (come mostrato in \figref{fig:proc_exec_relat}), sono tutte un front-end a
1064 \func{execve}. Il prototipo di quest'ultima è:
1065 \begin{prototype}{unistd.h}
1066 {int execve(const char *filename, char *const argv[], char *const envp[])}
1067   Esegue il programma contenuto nel file \param{filename}.
1068   
1069   \bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
1070     qual caso \var{errno} può assumere i valori:
1071   \begin{errlist}
1072   \item[\macro{EACCES}] il file non è eseguibile, oppure il filesystem è
1073     montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
1074   \item[\macro{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente non
1075     è root, e o il processo viene tracciato, o il filesystem è montato con
1076     l'opzione \cmd{nosuid}.
1077   \item[\macro{ENOEXEC}] il file è in un formato non eseguibile o non
1078     riconosciuto come tale, o compilato per un'altra architettura.
1079   \item[\macro{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1080     necessari per eseguirlo non esistono.
1081   \item[\macro{ETXTBSY}] L'eseguibile è aperto in scrittura da uno o più
1082     processi. 
1083   \item[\macro{EINVAL}] L'eseguibile ELF ha più di un segmento
1084     \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un
1085     interprete.
1086   \item[\macro{ELIBBAD}] Un interprete ELF non è in un formato
1087     riconoscibile.
1088   \end{errlist}
1089   ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO},
1090   \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}, \macro{ENOTDIR},
1091   \macro{ENFILE}, \macro{EMFILE}.}
1092 \end{prototype}
1093
1094 La funzione \func{exec} esegue il file o lo script indicato da
1095 \var{filename}, passandogli la lista di argomenti indicata da \var{argv}
1096 e come ambiente la lista di stringhe indicata da \var{envp}; entrambe le
1097 liste devono essere terminate da un puntatore nullo. I vettori degli
1098 argomenti e dell'ambiente possono essere acceduti dal nuovo programma
1099 quando la sua funzione \func{main} è dichiarata nella forma
1100 \code{main(int argc, char *argv[], char *envp[])}.
1101
1102 Le altre funzioni della famiglia servono per fornire all'utente una serie
1103 possibile di diverse interfacce per la creazione di un nuovo processo. I loro
1104 prototipi sono:
1105 \begin{functions}
1106 \headdecl{unistd.h}
1107 \funcdecl{int execl(const char *path, const char *arg, ...)} 
1108 \funcdecl{int execv(const char *path, char *const argv[])} 
1109 \funcdecl{int execle(const char *path, const char *arg, ..., char 
1110 * const envp[])} 
1111 \funcdecl{int execlp(const char *file, const char *arg, ...)} 
1112 \funcdecl{int execvp(const char *file, char *const argv[])} 
1113
1114 Sostituiscono l'immagine corrente del processo con quella indicata nel primo
1115 argomento. I parametri successivi consentono di specificare gli argomenti a
1116 linea di comando e l'ambiente ricevuti dal nuovo processo.
1117
1118 \bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1;
1119   nel qual caso \var{errno} assumerà i valori visti in precedenza per
1120   \func{execve}.}
1121 \end{functions}
1122
1123 Per capire meglio le differenze fra le funzioni della famiglia si può fare
1124 riferimento allo specchietto riportato in \ntab. La prima differenza riguarda
1125 le modalità di passaggio dei parametri che poi andranno a costituire gli
1126 argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
1127 dalla funzione \func{main} del programma chiamato). 
1128
1129 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
1130 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
1131 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
1132 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
1133 questo vettore \emph{deve} essere terminato da un puntatore nullo.
1134
1135 Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
1136 lista di puntatori, nella forma:
1137 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
1138   char *arg0, char *arg1,  ..., char *argn, NULL
1139 \end{lstlisting}
1140 che deve essere terminata da un puntatore nullo.  In entrambi i casi vale la
1141 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1142 per indicare il nome del file che contiene il programma che verrà eseguito.
1143
1144 \begin{table}[!htb]
1145   \footnotesize
1146   \centering
1147   \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1148     \hline
1149     \multicolumn{1}{|c|}{\textbf{Caratteristiche}} & 
1150     \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1151     \hline
1152     &\func{execl\ }&\func{execlp}&\func{execle}
1153     &\func{execv\ }& \func{execvp}& \func{execve} \\
1154     \hline
1155     \hline
1156     argomenti a lista    &$\bullet$&$\bullet$&$\bullet$&&& \\
1157     argomenti a vettore  &&&&$\bullet$&$\bullet$&$\bullet$\\
1158     \hline
1159     filename completo    &&$\bullet$&&&$\bullet$& \\ 
1160     ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\
1161     \hline
1162     ambiente a vettore   &&&$\bullet$&&&$\bullet$ \\
1163     uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1164     \hline
1165   \end{tabular}
1166   \caption{Confronto delle caratteristiche delle varie funzioni della 
1167     famiglia \func{exec}.}
1168   \label{tab:proc_exec_scheme}
1169 \end{table}
1170
1171 La seconda differenza fra le funzioni riguarda le modalità con cui si
1172 specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
1173 indicano le due funzioni che replicano il comportamento della shell nello
1174 specificare il comando da eseguire; quando il parametro \var{file} non
1175 contiene una \file{/} esso viene considerato come un nome di programma, e
1176 viene eseguita automaticamente una ricerca fra i file presenti nella lista di
1177 directory specificate dalla variabile di ambiente \var{PATH}. Il file che
1178 viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
1179 relativo a permessi di accesso insufficienti (cioè l'esecuzione della
1180 sottostante \func{execve} ritorna un \macro{EACCESS}), la ricerca viene
1181 proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
1182 non viene trovato nessun altro file viene finalmente restituito
1183 \macro{EACCESS}.
1184
1185 Le altre quattro funzioni si limitano invece a cercare di eseguire il file
1186 indicato dal parametro \var{path}, che viene interpretato come il
1187 \textit{pathname} del programma.
1188
1189 \begin{figure}[htb]
1190   \centering
1191   \includegraphics[width=15cm]{img/exec_rel}
1192   \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
1193   \label{fig:proc_exec_relat}
1194 \end{figure}
1195
1196 La terza differenza è come viene passata la lista delle variabili di ambiente.
1197 Con lo mnemonico \code{e} vengono indicate quelle funzioni che necessitano di
1198 un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti
1199 a riga di comando (terminato quindi da un \macro{NULL}), le altre usano il
1200 valore della variabile \var{environ} (vedi \secref{sec:proc_environ}) del
1201 processo di partenza per costruire l'ambiente.
1202
1203 Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
1204 \func{exec} assume anche una serie di altre proprietà del processo chiamante;
1205 la lista completa è la seguente:
1206 \begin{itemize*}
1207 \item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
1208   (\acr{ppid}).
1209 \item l'\textsl{userid reale}, il \textit{groupid reale} ed i \textsl{groupid
1210     supplementari} (vedi \secref{sec:proc_access_id}).
1211 \item il \textit{session id} (\acr{sid}) ed il \textit{process groupid}
1212   (\acr{pgid}), vedi \secref{sec:sess_proc_group}.
1213 \item il terminale di controllo (vedi \secref{sec:sess_ctrl_term}).
1214 \item il tempo restante ad un allarme (vedi \secref{sec:sig_alarm_abort}).
1215 \item la directory radice e la directory di lavoro corrente (vedi
1216   \secref{sec:file_work_dir}).
1217 \item la maschera di creazione dei file (\var{umask}, vedi
1218   \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
1219   \secref{sec:file_locking}).
1220 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
1221   \secref{sec:sig_sigmask}).
1222 \item i limiti sulle risorse (vedi \secref{sec:sys_resource_limit}).
1223 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
1224   \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:sys_cpu_times}).
1225 \end{itemize*}
1226
1227 Inoltre i segnali che sono stati impostati per essere ignorati nel processo
1228 chiamante mantengono la stessa impostazione pure nel nuovo programma, tutti
1229 gli altri segnali vengono impostati alla loro azione predefinita. Un caso
1230 speciale è il segnale \macro{SIGCHLD} che, quando impostato a
1231 \macro{SIG\_IGN}, può anche non essere reimpostato a \macro{SIG\_DFL} (si veda
1232 \secref{sec:sig_gen_beha}).
1233
1234 La gestione dei file aperti dipende dal valore che ha il flag di
1235 \textit{close-on-exec} (trattato in \secref{sec:file_fcntl}) per ciascun file
1236 descriptor. I file per cui è impostato vengono chiusi, tutti gli altri file
1237 restano aperti. Questo significa che il comportamento predefinito è che i file
1238 restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
1239 \func{fcntl} che imposti il suddetto flag.
1240
1241 Per le directory, lo standard POSIX.1 richiede che esse vengano chiuse
1242 attraverso una \func{exec}, in genere questo è fatto dalla funzione
1243 \func{opendir} (vedi \secref{sec:file_dir_read}) che effettua da sola
1244 l'impostazione del flag di \textit{close-on-exec} sulle directory che apre, in
1245 maniera trasparente all'utente.
1246
1247 Abbiamo detto che l'\textsl{userid reale} ed il \textsl{groupid reale} restano
1248 gli stessi all'esecuzione di \func{exec}; lo stesso vale per l'\textsl{userid
1249   effettivo} ed il \textsl{groupid effettivo} (il significato di questi
1250 identificatori è trattato in \secref{sec:proc_access_id}), tranne quando il
1251 file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} bit
1252 impostato, in questo caso l'\textsl{userid effettivo} ed il \textsl{groupid
1253   effettivo} vengono impostati rispettivamente all'utente o al gruppo cui il
1254 file appartiene (per i dettagli vedi \secref{sec:proc_perms}).
1255
1256 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1257 condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
1258 programma per caricare le librerie necessarie ed effettuare il link
1259 dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
1260 dinamiche viene usato l'interprete indicato nel segmento \macro{PT\_INTERP},
1261 in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
1262 \acr{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
1263 \acr{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
1264 una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
1265 deve esse un valido programma (binario, non un altro script) che verrà
1266 chiamato come se si fosse eseguito il comando \cmd{interpreter [arg]
1267   filename}.
1268
1269 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1270 basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
1271 processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
1272 \func{wait} si effettua e verifica la conclusione dei programmi. Tutte le
1273 altre funzioni sono ausiliarie e servono la lettura e l'impostazione dei vari
1274 parametri connessi ai processi.
1275
1276
1277
1278 \section{Il controllo di accesso}
1279 \label{sec:proc_perms}
1280
1281 In questa sezione esamineremo le problematiche relative al controllo di
1282 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
1283 usati, come questi possono essere modificati nella creazione e nel lancio di
1284 nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
1285 problematiche connesse ad una gestione accorta dei privilegi.
1286
1287
1288 \subsection{Gli identificatori del controllo di accesso}
1289 \label{sec:proc_access_id}
1290
1291 Come accennato in \secref{sec:intro_multiuser} il modello base\footnote{in
1292   realtà già esistono estensioni di questo modello base, che lo rendono più
1293   flessibile e controllabile, come le \textit{capabilities}, le ACL per i file
1294   o il \textit{Mandatory Access Control} di SELinux; inoltre basandosi sul
1295   lavoro effettuato con SELinux, a partire dal kernel 2.5.x, è iniziato lo
1296   sviluppo di una infrastruttura di sicurezza, il \textit{Linux Security
1297     Modules}, ol LSM, in grado di fornire diversi agganci a livello del kernel
1298   per modularizzare tutti i possibili controlli di accesso.} di sicurezza di
1299 un sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
1300 separazione fra l'amministratore (\textsl{root}, detto spesso anche
1301 \textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
1302 utenti, per i quali invece vengono effettuati i vari controlli di accesso.
1303
1304 %Benché il sistema sia piuttosto semplice (è basato su un solo livello di
1305 % separazione) il sistema permette una
1306 %notevole flessibilità, 
1307
1308 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1309 identificatori univoci, lo userid ed il groupid; questi servono al kernel per
1310 identificare uno specifico utente o un gruppo di utenti, per poi poter
1311 controllare che essi siano autorizzati a compiere le operazioni richieste.  Ad
1312 esempio in \secref{sec:file_access_control} vedremo come ad ogni file vengano
1313 associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
1314 appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
1315 kernel nella gestione dei permessi di accesso.
1316
1317 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1318 evidente che per poter implementare un controllo sulle operazioni occorre
1319 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1320 anche a ciascun processo dovrà essere associato ad un utente e ad un gruppo.
1321
1322 Un semplice controllo di una corrispondenza fra identificativi non garantisce
1323 però sufficiente flessibilità per tutti quei casi in cui è necessario poter
1324 disporre di privilegi diversi, o dover impersonare un altro utente per un
1325 limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
1326 prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
1327 rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
1328 \textsl{effettivi}). Nel caso di Linux si aggiungono poi altri due gruppi, il
1329 \textit{saved} (\textsl{salvati}) ed il \textit{filesystem} (\textsl{di
1330   filesystem}), secondo la situazione illustrata in \tabref{tab:proc_uid_gid}.
1331
1332 \begin{table}[htb]
1333   \footnotesize
1334   \centering
1335   \begin{tabular}[c]{|c|c|l|p{7.3cm}|}
1336     \hline
1337     \textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione} 
1338                                         & \textbf{Significato} \\ 
1339     \hline
1340     \hline
1341     \acr{uid}   & \textit{real} & \textsl{userid reale} 
1342                 & indica l'utente che ha lanciato il programma\\ 
1343     \acr{gid}   & '' &\textsl{groupid reale} 
1344                 & indica il gruppo principale dell'utente che ha lanciato 
1345                   il programma \\ 
1346     \hline
1347     \acr{euid}  & \textit{effective} &\textsl{userid effettivo} 
1348                 & indica l'utente usato nel controllo di accesso \\ 
1349     \acr{egid}  & '' & \textsl{groupid effettivo} 
1350                 & indica il gruppo usato nel controllo di accesso \\ 
1351     --          & -- & \textsl{groupid supplementari} 
1352                 & indicano gli ulteriori gruppi cui l'utente appartiene \\ 
1353     \hline
1354     --          & \textit{saved} & \textsl{userid salvato} 
1355                 & è una copia dell'\acr{euid} iniziale\\ 
1356     --          & '' & \textsl{groupid salvato} 
1357                 & è una copia dell'\acr{egid} iniziale \\ 
1358     \hline
1359     \acr{fsuid} & \textit{filesystem} &\textsl{userid di filesystem} 
1360                 & indica l'utente effettivo per l'accesso al filesystem \\ 
1361     \acr{fsgid} & '' & \textsl{groupid di filesystem} 
1362                 & indica il gruppo effettivo per l'accesso al filesystem  \\ 
1363     \hline
1364   \end{tabular}
1365   \caption{Identificatori di utente e gruppo associati a ciascun processo con
1366     indicazione dei suffissi usati dalle varie funzioni di manipolazione.}
1367   \label{tab:proc_uid_gid}
1368 \end{table}
1369
1370 Al primo gruppo appartengono l'\textsl{userid reale} ed il \textsl{groupid
1371   reale}: questi vengono impostati al login ai valori corrispondenti
1372 all'utente con cui si accede al sistema (e relativo gruppo principale).
1373 Servono per l'identificazione dell'utente e normalmente non vengono mai
1374 cambiati. In realtà vedremo (in \secref{sec:proc_setuid}) che è possibile
1375 modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
1376 questa possibilità è usata proprio dal programma \cmd{login} che, una volta
1377 completata la procedura di autenticazione, lancia una shell per la quale
1378 imposta questi identificatori ai valori corrispondenti all'utente che entra
1379 nel sistema.
1380
1381 Al secondo gruppo appartengono l'\textsl{userid effettivo} e l'\textsl{groupid
1382   effettivo} (a cui si aggiungono gli eventuali \textsl{groupid supplementari}
1383 dei gruppi dei quali l'utente fa parte).  Questi sono invece gli
1384 identificatori usati nella verifiche dei permessi del processo e per il
1385 controllo di accesso ai file (argomento affrontato in dettaglio in
1386 \secref{sec:file_perm_overview}).
1387
1388 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1389 \textit{real} tranne nel caso in cui, come accennato in
1390 \secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
1391 \acr{suid} o \acr{sgid} impostati (il significato di questi bit è affrontato
1392 in dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno
1393 impostati all'utente e al gruppo proprietari del file. Questo consente, per
1394 programmi in cui ci sia necessità, di dare a qualunque utente normale
1395 privilegi o permessi di un'altro (o dell'amministratore).
1396
1397 Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
1398 possono essere letti dal processo attraverso delle opportune funzioni, i cui
1399 prototipi sono i seguenti:
1400 \begin{functions}
1401   \headdecl{unistd.h}
1402   \headdecl{sys/types.h}  
1403   \funcdecl{uid\_t getuid(void)} Restituisce l'\textsl{userid reale} del
1404   processo corrente.
1405
1406   \funcdecl{uid\_t geteuid(void)} Restituisce l'\textsl{userid effettivo} del
1407   processo corrente.
1408
1409   \funcdecl{gid\_t getgid(void)} Restituisce il \textsl{groupid reale} del
1410   processo corrente.
1411   
1412   \funcdecl{gid\_t getegid(void)} Restituisce il \textsl{groupid effettivo}
1413   del processo corrente.
1414   
1415   \bodydesc{Queste funzioni non riportano condizioni di errore.}
1416 \end{functions}
1417
1418 In generale l'uso di privilegi superiori deve essere limitato il più
1419 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1420 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1421 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1422 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1423 servano di nuovo.
1424
1425 Questo in Linux viene fatto usando altri gli altri due gruppi di
1426 identificatori, il \textit{saved} ed il \textit{filesystem}. Il primo gruppo è
1427 lo stesso usato in SVr4, e previsto dallo standard POSIX quando è definita la
1428 costante \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la
1429   portabilità del programma su altri Unix è buona norma controllare sempre la
1430   disponibilità di queste funzioni controllando se questa costante è
1431   definita.} il secondo gruppo è specifico di Linux e viene usato per
1432 migliorare la sicurezza con NFS.
1433
1434 L'\textsl{userid salvato} ed il \textsl{groupid salvato} sono copie
1435 dell'\textsl{userid effettivo} e del \textsl{groupid effettivo} del processo
1436 padre, e vengono impostati dalla funzione \func{exec} all'avvio del processo,
1437 come copie dell'\textsl{userid effettivo} e del \textsl{groupid effettivo}
1438 dopo che questo sono stati impostati tenendo conto di eventuali \acr{suid} o
1439 \acr{sgid}.  Essi quindi consentono di tenere traccia di quale fossero utente
1440 e gruppo effettivi all'inizio dell'esecuzione di un nuovo programma.
1441
1442 L'\textsl{userid di filesystem} e il \textsl{groupid di filesystem} sono
1443 un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
1444 (torneremo sull'argomento in \secref{sec:proc_setfsuid}). Essi sono una
1445 replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
1446 quali si sostituiscono per tutte le operazioni di verifica dei permessi
1447 relativi ai file (trattate in \secref{sec:file_perm_overview}).  Ogni
1448 cambiamento effettuato sugli identificatori effettivi viene automaticamente
1449 riportato su di essi, per cui in condizioni normali si può tranquillamente
1450 ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
1451
1452
1453 \subsection{Le funzioni \func{setuid} e \func{setgid}}
1454 \label{sec:proc_setuid}
1455
1456 Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
1457 di appartenenza) ad un processo sono rispettivamente \func{setuid} e
1458 \func{setgid}; come accennato in \secref{sec:proc_access_id} in Linux esse
1459 seguono la semantica POSIX che prevede l'esistenza dell'\textit{userid
1460   salvato} e del \textit{groupid salvato}; i loro prototipi sono:
1461 \begin{functions}
1462 \headdecl{unistd.h}
1463 \headdecl{sys/types.h}
1464
1465 \funcdecl{int setuid(uid\_t uid)} Imposta l'\textsl{userid} del processo
1466 corrente.
1467
1468 \funcdecl{int setgid(gid\_t gid)} Imposta il \textsl{groupid} del processo
1469 corrente.
1470
1471 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1472   di fallimento: l'unico errore possibile è \macro{EPERM}.}
1473 \end{functions}
1474
1475 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1476 la prima; la seconda si comporta esattamente allo stesso modo facendo
1477 riferimento al \textsl{groupid} invece che all'\textsl{userid}.  Gli
1478 eventuali \textsl{groupid supplementari} non vengono modificati.
1479
1480 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1481 l'\textsl{userid effettivo} è zero (cioè è quello dell'amministratore di
1482 sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e
1483 \textit{saved}) vengono impostati al valore specificato da \var{uid},
1484 altrimenti viene impostato solo l'\textsl{userid effettivo}, e soltanto se il
1485 valore specificato corrisponde o all'\textsl{userid reale} o
1486 all'\textsl{userid salvato}. Negli altri casi viene segnalato un errore (con
1487 \macro{EPERM}).
1488
1489 Come accennato l'uso principale di queste funzioni è quello di poter
1490 consentire ad un programma con i bit \acr{suid} o \acr{sgid} impostati di
1491 riportare l'\textsl{userid effettivo} a quello dell'utente che ha lanciato il
1492 programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
1493 eventualmente tornare indietro.
1494
1495 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
1496 viene gestito l'accesso al file \file{/var/log/utmp}.  In questo file viene
1497 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1498 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1499 falsificare la registrazione. Per questo motivo questo file (e l'analogo
1500 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
1501 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
1502 esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
1503 crea terminali multipli su una console) appartengono a questo gruppo ed hanno
1504 il bit \acr{sgid} impostato.
1505
1506 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
1507 situazione degli identificatori è la seguente:
1508 \begin{eqnarray*}
1509   \label{eq:1}
1510   \textsl{groupid reale}      &=& \textrm{\acr{gid} (del chiamante)} \\
1511   \textsl{groupid effettivo}  &=& \textrm{\acr{utmp}} \\
1512   \textsl{groupid salvato}    &=& \textrm{\acr{utmp}}
1513 \end{eqnarray*}
1514 in questo modo, dato che il \textsl{groupid effettivo} è quello giusto, il
1515 programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo. A
1516 questo punto il programma può eseguire una \code{setgid(getgid())} per
1517 impostare il \textsl{groupid effettivo} a quello dell'utente (e dato che il
1518 \textsl{groupid reale} corrisponde la funzione avrà successo), in questo modo
1519 non sarà possibile lanciare dal terminale programmi che modificano detto file,
1520 in tal caso infatti la situazione degli identificatori sarebbe:
1521 \begin{eqnarray*}
1522   \label{eq:2}
1523   \textsl{groupid reale}      &=& \textrm{\acr{gid} (invariato)}  \\
1524   \textsl{groupid effettivo}  &=& \textrm{\acr{gid}} \\
1525   \textsl{groupid salvato}    &=& \textrm{\acr{utmp} (invariato)}
1526 \end{eqnarray*}
1527 e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
1528 \textsl{groupid effettivo}. All'uscita dal terminale, per poter di nuovo
1529 aggiornare lo stato di \file{/var/log/utmp} il programma eseguirà una
1530 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
1531 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
1532 in questo caso il valore richiesto corrisponde al \textsl{groupid salvato} la
1533 funzione avrà successo e riporterà la situazione a:
1534 \begin{eqnarray*}
1535   \label{eq:3}
1536   \textsl{groupid reale}      &=& \textrm{\acr{gid} (invariato)}  \\
1537   \textsl{groupid effettivo}  &=& \textrm{\acr{utmp}} \\
1538   \textsl{groupid salvato}    &=& \textrm{\acr{utmp} (invariato)}
1539 \end{eqnarray*}
1540 consentendo l'accesso a \file{/var/log/utmp}.
1541
1542 Occorre però tenere conto che tutto questo non è possibile con un processo con
1543 i privilegi di root, in tal caso infatti l'esecuzione una \func{setuid}
1544 comporta il cambiamento di tutti gli identificatori associati al processo,
1545 rendendo impossibile riguadagnare i privilegi di amministratore.  Questo
1546 comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea
1547 una nuova shell per l'utente; ma quando si vuole cambiare soltanto
1548 l'\textsl{userid effettivo} del processo per cedere i privilegi occorre
1549 ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
1550
1551
1552 \subsection{Le funzioni \func{setreuid} e \func{setresuid}}
1553 \label{sec:proc_setreuid}
1554
1555 Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino
1556   alla versione 4.3+BSD TODO, FIXME verificare e aggiornare la nota.} gli
1557 identificatori del gruppo \textit{saved}, le usa per poter scambiare fra di
1558 loro \textit{effective} e \textit{real}. I loro prototipi sono:
1559 \begin{functions}
1560 \headdecl{unistd.h}
1561 \headdecl{sys/types.h}
1562
1563 \funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Imposta l'\textsl{userid
1564   reale} e l'\textsl{userid effettivo} del processo corrente ai valori
1565 specificati da \var{ruid} e \var{euid}.
1566   
1567 \funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Imposta il \textsl{groupid
1568   reale} ed il \textsl{groupid effettivo} del processo corrente ai valori
1569 specificati da \var{rgid} e \var{egid}.
1570
1571 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1572   di fallimento: l'unico errore possibile è \macro{EPERM}.}
1573 \end{functions}
1574
1575 La due funzioni sono analoghe ed il loro comportamento è identico; quanto
1576 detto per la prima prima riguardo l'userid, si applica immediatamente alla
1577 seconda per il groupid. I processi non privilegiati possono impostare solo i
1578 valori del loro userid effettivo o reale; valori diversi comportano il
1579 fallimento della chiamata; l'amministratore invece può specificare un valore
1580 qualunque.  Specificando un argomento di valore -1 l'identificatore
1581 corrispondente verrà lasciato inalterato.
1582
1583 Con queste funzione si possono scambiare fra loro gli userid reale e
1584 effettivo, e pertanto è possibile implementare un comportamento simile a
1585 quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
1586 scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo
1587 scambio.
1588
1589 In questo caso però occorre porre molta attenzione quando si creano nuovi
1590 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
1591 questo caso infatti essi avranno un userid reale privilegiato, che dovrà
1592 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
1593 programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
1594 prima della \func{exec} per uniformare l'userid reale a quello effettivo) in
1595 caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio
1596 e riottenere privilegi non previsti.
1597
1598 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
1599 si pone per l'userid salvato: questa funzione deriva da un'implementazione che
1600 non ne prevede la presenza, e quindi non è possibile usarla per correggere la
1601 situazione come nel caso precedente. Per questo motivo in Linux tutte le volte
1602 che si imposta un qualunque valore diverso da quello dall'userid reale
1603 corrente, l'userid salvato viene automaticamente uniformato al valore
1604 dell'userid effettivo.
1605
1606
1607 \subsection{Le funzioni \func{seteuid} e \func{setegid}}
1608 \label{sec:proc_seteuid}
1609
1610 Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque
1611 supportate dalla maggior parte degli Unix) e vengono usate per cambiare gli
1612 identificatori del gruppo \textit{effective}; i loro prototipi sono:
1613 \begin{functions}
1614 \headdecl{unistd.h}
1615 \headdecl{sys/types.h}
1616
1617 \funcdecl{int seteuid(uid\_t uid)} Imposta l'userid effettivo del processo
1618 corrente a \var{uid}.
1619
1620 \funcdecl{int setegid(gid\_t gid)} Imposta il groupid effettivo del processo
1621 corrente a \var{gid}.
1622
1623 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1624   di fallimento: l'unico errore possibile è \macro{EPERM}.}
1625 \end{functions}
1626
1627 Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo
1628 la prima. Gli utenti normali possono impostare l'userid effettivo solo al
1629 valore dell'userid reale o dell'userid salvato, l'amministratore può
1630 specificare qualunque valore. Queste funzioni sono usate per permettere
1631 all'amministratore di impostare solo l'userid effettivo, dato che l'uso
1632 normale di \func{setuid} comporta l'impostazione di tutti gli identificatori.
1633  
1634
1635 \subsection{Le funzioni \func{setresuid} e \func{setresgid}}
1636 \label{sec:proc_setresuid}
1637
1638 Queste due funzioni sono un'estensione introdotta in Linux dal kernel 2.1.44,
1639 e permettono un completo controllo su tutti gli identificatori (\textit{real},
1640 \textit{effective} e \textit{saved}), i prototipi sono:
1641 \begin{functions}
1642 \headdecl{unistd.h}
1643 \headdecl{sys/types.h}
1644
1645 \funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Imposta
1646 l'userid reale, l'userid effettivo e l'userid salvato del processo corrente
1647 ai valori specificati rispettivamente da \var{ruid}, \var{euid} e \var{suid}.
1648   
1649 \funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Imposta il
1650 groupid reale, il groupid effettivo ed il groupid salvato del processo
1651 corrente ai valori specificati rispettivamente da \var{rgid}, \var{egid} e
1652 \var{sgid}.
1653
1654 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1655   di fallimento: l'unico errore possibile è \macro{EPERM}.}
1656 \end{functions}
1657
1658 Le due funzioni sono identiche, quanto detto per la prima riguardo gli userid
1659 si applica alla seconda per i groupid. I processi non privilegiati possono
1660 cambiare uno qualunque degli userid solo ad un valore corripondente o
1661 all'userid reale, o a quello effettivo o a quello salvato, l'amministratore
1662 può specificare i valori che vuole; un valore di -1 per un qualunque parametro
1663 lascia inalterato l'identificatore corrispondente.
1664
1665 Per queste funzioni esistono anche due controparti che permettono di leggere
1666 in blocco i vari identificatori: \func{getresuid} e \func{getresgid}; i loro
1667 prototipi sono: 
1668 \begin{functions}
1669 \headdecl{unistd.h}
1670 \headdecl{sys/types.h}
1671
1672 \funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge
1673 l'userid reale, l'userid effettivo e l'userid salvato del processo corrente.
1674   
1675 \funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il
1676 groupid reale, il groupid effettivo e il groupid salvato del processo
1677 corrente.
1678
1679 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
1680   fallimento: l'unico errore possibile è \macro{EFAULT} se gli indirizzi delle
1681   variabili di ritorno non sono validi.}
1682 \end{functions}
1683
1684 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
1685 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
1686 specificati come puntatori (è un'altro esempio di \textit{value result
1687   argument}). Si noti che queste funzioni sono le uniche in grado di leggere
1688 gli identificatori del gruppo \textit{saved}.
1689
1690
1691 \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
1692 \label{sec:proc_setfsuid}
1693
1694 Queste funzioni sono usate per impostare gli identificatori del gruppo
1695 \textit{filesystem} che usati da Linux per il controllo dell'accesso ai file.
1696 Come già accennato in \secref{sec:proc_access_id} Linux definisce questo
1697 ulteriore gruppo di identificatori, che di norma sono assolutamente
1698 equivalenti a quelli del gruppo \textit{effective}, dato che ogni cambiamento
1699 di questi ultimi viene immediatamente riportato su di essi.
1700
1701 C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
1702 identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
1703 ovviare ad un problema di sicurezza che si presenta quando si deve
1704 implementare un server NFS. Il server NFS infatti deve poter cambiare
1705 l'identificatore con cui accede ai file per assumere l'identità del singolo
1706 utente remoto, ma se questo viene fatto cambiando l'userid effettivo o
1707 l'userid reale il server si espone alla ricezione di eventuali segnali ostili
1708 da parte dell'utente di cui ha temporaneamente assunto l'identità.  Cambiando
1709 solo l'userid di filesystem si ottengono i privilegi necessari per accedere ai
1710 file, mantenendo quelli originari per quanto riguarda tutti gli altri
1711 controlli di accesso, così che l'utente non possa inviare segnali al server
1712 NFS.
1713
1714 Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid}
1715 e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
1716 usate se si intendono scrivere programmi portabili; i loro prototipi sono:
1717 \begin{functions}
1718 \headdecl{sys/fsuid.h}
1719
1720 \funcdecl{int setfsuid(uid\_t fsuid)} Imposta l'userid di filesystem del
1721 processo corrente a \var{fsuid}.
1722
1723 \funcdecl{int setfsgid(gid\_t fsgid)} Imposta il groupid di filesystem del
1724 processo corrente a \var{fsgid}.
1725
1726 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1727   di fallimento: l'unico errore possibile è \macro{EPERM}.}
1728 \end{functions}
1729 \noindent queste funzioni hanno successo solo se il processo chiamante ha i
1730 privilegi di amministratore o, per gli altri utenti, se il valore specificato
1731 coincide con uno dei di quelli del gruppo \textit{real}, \textit{effective} o
1732 \textit{saved}.
1733
1734
1735 \subsection{Le funzioni \func{setgroups} e \func{getgroups}}
1736 \label{sec:proc_setgroups}
1737
1738 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
1739 gruppi supplementari. Ogni processo può avere fino a \macro{NGROUPS\_MAX}
1740 gruppi supplementari in aggiunta al gruppo primario, questi vengono ereditati
1741 dal processo padre e possono essere cambiati con queste funzioni.
1742
1743 La funzione che permette di leggere i gruppi supplementari è \func{getgroups};
1744 questa funzione è definita nello standard POSIX ed il suo prototipo è:
1745 \begin{functions}
1746   \headdecl{sys/types.h}
1747   \headdecl{unistd.h}
1748   
1749   \funcdecl{int getgroups(int size, gid\_t list[])} Legge gli identificatori
1750   dei gruppi supplementari del processo sul vettore \param{list} di dimensione
1751   \param{size}.
1752   
1753   \bodydesc{La funzione restituisce il numero di gruppi letti in caso di
1754     successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
1755     i valori: 
1756     \begin{errlist}
1757     \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1758     \item[\macro{EINVAL}] il valore di \param{size} è diverso da zero ma
1759       minore del numero di gruppi supplementari del processo.
1760     \end{errlist}}
1761 \end{functions}
1762 \noindent non è specificato se la funzione inserisca o meno nella lista
1763 il groupid effettivo del processo. Se si specifica un valore di \param{size}
1764 uguale a 0 \param{list} non viene modificato, ma si ottiene il numero di
1765 gruppi supplementari.
1766
1767 Una seconda funzione, \func{getgrouplist}, può invece essere usata per
1768 ottenere tutti i gruppi a cui appartiene un utente; il suo prototipo è:
1769 \begin{functions}
1770   \headdecl{sys/types.h} 
1771   \headdecl{grp.h}
1772   
1773   \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups,
1774     int *ngroups)} Legge i gruppi supplementari dell'utente \param{user}.
1775   
1776   \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori,
1777     restituisce 0 in caso di successo e -1 in caso di fallimento.}
1778 \end{functions}
1779 \noindent la funzione esegue una scansione del database dei gruppi (si veda
1780 \secref{sec:sys_user_group}) e ritorna in \param{groups} la lista di quelli a
1781 cui l'utente appartiene. Si noti che \param{ngroups} è passato come puntatore
1782 perché qualora il valore specificato sia troppo piccolo la funzione ritorna
1783 -1, passando indietro il numero dei gruppi trovati.
1784
1785 Per impostare i gruppi supplementari di un processo ci sono due funzioni, che
1786 possono essere usate solo se si hanno i privilegi di amministratore. La prima
1787 delle due è \func{setgroups}, ed il suo prototipo è:
1788 \begin{functions}
1789   \headdecl{sys/types.h}
1790   \headdecl{grp.h}
1791   
1792   \funcdecl{int setgroups(size\_t size, gid\_t *list)} Imposta i gruppi
1793   supplementari del processo ai valori specificati in \param{list}.
1794
1795   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1796     fallimento, nel qual caso \var{errno} assumerà i valori:
1797     \begin{errlist}
1798     \item[\macro{EFAULT}] \param{list} non ha un indirizzo valido.
1799     \item[\macro{EPERM}] il processo non ha i privilegi di amministratore.
1800     \item[\macro{EINVAL}] il valore di \param{size} è maggiore del valore
1801     massimo (\macro{NGROUPS}, che per Linux è 32).
1802     \end{errlist}}
1803 \end{functions}
1804
1805 Se invece si vogliono impostare i gruppi supplementari del processo a quelli di
1806 un utente specifico, si può usare \func{initgroups} il cui prototipo è:
1807 \begin{functions}
1808   \headdecl{sys/types.h}
1809   \headdecl{grp.h}
1810
1811   \funcdecl{int initgroups(const char *user, gid\_t group)} Imposta i gruppi
1812   supplementari del processo a quelli di cui è membro l'utente \param{user},
1813   aggiungendo il gruppo addizionale \param{group}.
1814   
1815   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1816     fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
1817     \func{setgroups} più \macro{ENOMEM} quando non c'è memoria sufficiente per
1818     allocare lo spazio per informazioni dei gruppi.}
1819 \end{functions}
1820
1821 La funzione esegue la scansione del database dei gruppi (usualmente
1822 \file{/etc/groups}) cercando i gruppi di cui è membro \param{user} e
1823 costruendo una lista di gruppi supplementari a cui aggiunge \param{group}, che
1824 poi imposta usando \func{setgroups}.
1825 Si tenga presente che sia \func{setgroups} che \func{initgroups} non sono
1826 definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle
1827 quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
1828 \cmd{-ansi}.
1829
1830
1831 \section{La gestione della priorità di esecuzione}
1832 \label{sec:proc_priority}
1833
1834 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
1835 lo \textit{scheduler} assegna la CPU ai vari processi attivi. In particolare
1836 prenderemo in esame i vari meccanismi con cui viene gestita l'assegnazione del
1837 tempo di CPU, ed illustreremo le varie funzioni di gestione.
1838
1839
1840 \subsection{I meccanismi di \textit{scheduling}}
1841 \label{sec:proc_sched}
1842
1843 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
1844 il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
1845 ed oggetto di numerose ricerche; in generale essa dipende in maniera
1846 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
1847 cui non esiste un meccanismo che sia valido per tutti gli usi.
1848
1849 La caratteristica specifica di un sistema multitasking come Linux è quella del
1850 cosiddetto \textit{prehemptive multitasking}: questo significa che al
1851 contrario di altri sistemi (che usano invece il cosiddetto \textit{cooperative
1852   multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
1853 quando la CPU deve essere passata ad un altro processo. Come accennato in
1854 \secref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
1855 apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
1856 distribuire al meglio il tempo di CPU fra i vari processi.
1857
1858 La cosa è resa ancora più complicata dal fatto che con le architetture
1859 multi-processore si deve anche scegliere quale sia la CPU più opportuna da
1860 utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
1861   rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
1862   un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
1863   banale.}  Tutto questo comunque appartiene alle sottigliezze
1864 dell'implementazione del kernel; dal punto di vista dei programmi che girano
1865 in user space, anche quando si hanno più processori (e dei processi che sono
1866 eseguiti davvero in contemporanea), le politiche di scheduling riguardano
1867 semplicemente l'allocazione della risorsa \textsl{tempo di esecuzione}, la cui
1868 assegnazione sarà governata dai meccanismi di scelta delle priorità che
1869 restano gli stessi indipendentemente dal numero di processori.
1870
1871 Si tenga conto poi che i processi non devono solo eseguire del codice: ad
1872 esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
1873 venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
1874 tempo.  In tutti questi casi la CPU diventa disponibile ed è compito dello
1875 kernel provvedere a mettere in esecuzione un altro processo.
1876
1877 Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
1878 processo, in Linux un processo può trovarsi in uno degli stati riportati in
1879 \tabref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
1880 \textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
1881 sia la sua priorità, un processo non potrà mai essere messo in esecuzione
1882 fintanto che esso si trova in uno qualunque degli altri stati.
1883
1884 \begin{table}[htb]
1885   \centering
1886   \begin{tabular}[c]{|p{2.8cm}|c|p{10cm}|}
1887     \hline
1888     \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
1889     \hline
1890     \hline
1891     \textbf{Runnable} & \texttt{R} & Il processo è in esecuzione o è pronto ad
1892     essere eseguito (cioè è in attesa che gli venga assegnata la CPU).   \\
1893     \textbf{Sleep} & \texttt{S} & Il processo processo è in attesa di un
1894     risposta dal sistema, ma può essere interrotto da un segnale. \\
1895     \textbf{Uninterrutible Sleep} & \texttt{D} & Il  processo è in
1896     attesa di un risposta dal sistema (in genere per I/O), e non può essere
1897     interrotto in nessuna circostanza. \\
1898     \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
1899     \macro{SIGSTOP}, o è tracciato.\\
1900     \textbf{Zombie} & \texttt{Z} & Il processo è terminato ma il suo stato di
1901     terminazione non è ancora stato letto dal padre. \\
1902     \hline
1903   \end{tabular}
1904   \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
1905     \texttt{STAT} si è riportata la corrispondente lettera usata dal comando 
1906     \cmd{ps} nell'omonimo campo.}
1907   \label{tab:proc_proc_states}
1908 \end{table}
1909
1910 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
1911 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
1912 dello scopo del programma non è detto neanche che sia la più importante (molti
1913 programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
1914 non è affatto detto che dare ad un programma la massima priorità di esecuzione
1915 abbia risultati significativi in termini di prestazioni.
1916
1917 Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
1918 \secref{sec:proc_sched_stand}) è sempre stato basato su delle \textsl{priorità
1919   dinamiche}, in modo da assicurare che tutti i processi, anche i meno
1920 importanti, possano ricevere un po' di tempo di CPU. In sostanza quando un
1921 processo ottiene la CPU la sua priorità viene diminuita. In questo modo alla
1922 fine, anche un processo con priorità iniziale molto bassa, finisce per avere
1923 una priorità sufficiente per essere eseguito.
1924
1925 Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
1926   assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
1927 alla normale priorità dinamica), per tenere conto dei sistemi
1928 real-time,\footnote{per sistema real-time si intende un sistema in grado di
1929   eseguire operazioni in un tempo ben determinato; in genere si tende a
1930   distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
1931   esecuzione di un programma siano determinabili con certezza assoluta (come
1932   nel caso di meccanismi di controllo di macchine, dove uno sforamento dei
1933   tempi avrebbe conseguenze disastrose), e \textit{soft-real-time} in cui un
1934   occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
1935 processi che devono essere eseguiti in un determinato momento non debbano
1936 aspettare la conclusione di altri che non hanno questa necessità.
1937
1938 Il concetto di priorità assoluta dice che quando due processi si contendono
1939 l'esecuzione, vince sempre quello con la priorità assoluta più alta, anche
1940 quando l'altro è in esecuzione (grazie al \textit{prehemptive scheduling}).
1941 Ovviamente questo avviene solo per i processi che sono pronti per essere
1942 eseguiti (cioè nello stato \textit{runnable}).  La priorità assoluta viene in
1943 genere indicata con un numero intero, ed un valore più alto comporta una
1944 priorità maggiore. Su questa politica di scheduling torneremo in
1945 \secref{sec:proc_real_time}.
1946
1947 In generale quello che succede in tutti gli Unix moderni è che ai processi
1948 normali viene sempre data una priorità assoluta pari a zero, e la decisione di
1949 assegnazione della CPU è fatta solo con il meccanismo tradizionale della
1950 priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
1951 assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
1952 priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
1953 bisogno della CPU.
1954
1955
1956 \subsection{Il meccanismo di \textit{scheduling} standard}
1957 \label{sec:proc_sched_stand}
1958
1959 A meno che non si abbiano esigenze specifiche, l'unico meccanismo di
1960 scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
1961 solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
1962 nella programmazione.
1963
1964 Come accennato in Linux tutti i processi ordinari hanno la stessa priorità
1965 assoluta. Quello che determina quale, fra tutti i processi in attesa di
1966 esecuzione, sarà eseguito per primo, è la priorità dinamica, che è chiamata
1967 così proprio perché varia nel corso dell'esecuzione di un processo. Oltre a
1968 questo la priorità dinamica determina quanto a lungo un processo continuerà ad
1969 essere eseguito, e quando un processo potrà subentrare ad un altro
1970 nell'esecuzione.
1971
1972 Il meccanismo usato da Linux è piuttosto semplice, ad ogni processo è
1973 assegnata una \textit{time-slice}, cioè in intervallo di tempo (letteralmente
1974 una fetta) per il quale esso deve essere eseguito. Il valore della
1975 \textit{time-slice} è controllato dalla cosiddetta \textit{nice} (o
1976 \textit{niceness}) del processo.  Essa è contenuta nel campo \var{nice} di
1977 \var{task\_struct}; tutti i processi vengono creati con lo stesso valore, ed
1978 essa specifica il valore della durata iniziale della \textit{time-slice} che
1979 viene assegnato ad un altro campo della struttura (\var{counter}) quando il
1980 processo viene eseguito per la prima volta e diminuito progressivamente ad
1981 ogni interruzione del timer.
1982
1983 Quando lo scheduler viene eseguito scandisce la coda dei processi in stato
1984 \textit{runnable} associando, sulla base del valore di \var{counter}, un peso
1985 a ciascun processo in attesa di esecuzione,\footnote{il calcolo del peso in
1986   realtà è un po' più complicato, ad esempio nei sistemi multiprocessore viene
1987   favorito un processo che è eseguito sulla stessa CPU, e a parità del valore
1988   di \var{counter} viene favorito chi ha una priorità più elevata.} chi ha il
1989 peso più alto verrà posto in esecuzione, ed il precedente processo sarà
1990 spostato in fondo alla coda.  Dato che ad ogni interruzione del timer il
1991 valore di \var{counter} del processo corrente viene diminuito, questo assicura
1992 che anche i processi con priorità più bassa verranno messi in esecuzione.
1993
1994 La priorità di un processo è così controllata attraverso il valore di
1995 \var{nice}, che stabilisce la durata della \textit{time-slice}; per il
1996 meccanismo appena descritto infatti un valore più lungo infatti assicura una
1997 maggiore attribuzione di CPU.  L'origine del nome di questo parametro sta nel
1998 fatto che in genere esso viene generalmente usato per diminuire la priorità di
1999 un processo, come misura di cortesia nei confronti degli altri.
2000 I processi infatti vengono creati dal sistema con lo stesso valore di
2001 \var{nice} (nullo) e nessuno è privilegiato rispetto agli altri; il valore può
2002 essere modificato solo attraverso la funzione \func{nice}, il cui prototipo è:
2003 \begin{prototype}{unistd.h}
2004 {int nice(int inc)}
2005   Aumenta il valore di \var{nice} per il processo corrente.
2006   
2007   \bodydesc{La funzione ritorna zero in caso di successo e -1 in caso di
2008     errore, nel qual caso \var{errno} può assumere i valori:
2009   \begin{errlist}
2010   \item[\macro{EPERM}] un processo senza i privilegi di amministratore ha
2011     specificato un valore di \param{inc} negativo.
2012   \end{errlist}}
2013 \end{prototype}
2014
2015 L'argomento \param{inc} indica l'incremento del valore di \var{nice}:
2016 quest'ultimo può assumere valori compresi fra \macro{PRIO\_MIN} e
2017 \macro{PRIO\_MAX} (che nel caso di Linux sono $-19$ e $20$), ma per
2018 \param{inc} si può specificare un valore qualunque, positivo o negativo, ed il
2019 sistema provvederà a troncare il risultato nell'intervallo consentito. Valori
2020 positivi comportano maggiore \textit{cortesia} e cioè una diminuzione della
2021 priorità, ogni utente può solo innalzare il valore di un suo processo. Solo
2022 l'amministratore può specificare valori negativi che permettono di aumentare
2023 la priorità di un processo.
2024
2025 In SUSv2 la funzione ritorna il nuovo valore di \var{nice}; Linux non segue
2026 questa convenzione, e per leggere il nuovo valore occorre invece usare la
2027 funzione \func{getpriority}, derivata da BSD, il cui prototipo è:
2028 \begin{prototype}{sys/resource.h}
2029 {int getpriority(int which, int who)}
2030   
2031 Restituisce il valore di \var{nice} per l'insieme dei processi specificati.
2032
2033   \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2034     errore, nel qual caso \var{errno} può assumere i valori:
2035   \begin{errlist}
2036   \item[\macro{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2037   \param{which} e \param{who}.
2038   \item[\macro{EINVAL}] il valore di \param{which} non è valido.
2039   \end{errlist}}
2040 \end{prototype}
2041 \noindent (in vecchie versioni può essere necessario includere anche
2042 \file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
2043 librerie, ma è comunque utile per portabilità).
2044
2045 La funzione permette di leggere la priorità di un processo, di un gruppo di
2046 processi (vedi \secref{sec:sess_proc_group}) o di un utente, a seconda del
2047 valore di \param{which}, secondo la legenda di \tabref{tab:proc_getpriority},
2048 specificando un corrispondente valore per \param{who}; un valore nullo di
2049 quest'ultimo indica il processo, il gruppo di processi o l'utente correnti.
2050
2051 \begin{table}[htb]
2052   \centering
2053   \footnotesize
2054   \begin{tabular}[c]{|c|c|l|}
2055     \hline
2056     \param{which} & \param{who} & \textbf{Significato} \\
2057     \hline
2058     \hline
2059     \macro{PRIO\_PROCESS} & \type{pid\_t} &  processo  \\
2060     \macro{PRIO\_PRGR}    & \type{pid\_t} &  process group  \\
2061     \macro{PRIO\_USER}    & \type{uid\_t} &  utente \\
2062     \hline
2063   \end{tabular}
2064   \caption{Legenda del valore dell'argomento \param{which} e del tipo
2065     dell'argomento \param{who} delle funzioni \func{getpriority} e
2066     \func{setpriority} per le tre possibili scelte.}
2067   \label{tab:proc_getpriority}
2068 \end{table}
2069
2070 La funzione restituisce la priorità più alta (cioè il valore più basso) fra
2071 quelle dei processi specificati; dato che -1 è un valore possibile, per poter
2072 rilevare una condizione di errore è necessario cancellare sempre \var{errno}
2073 prima della chiamata alla funzione, per verificare che essa resti uguale a
2074 zero.  
2075
2076 Analoga a \func{getpriority} la funzione \func{setpriority} permette di
2077 impostare la priorità di uno o più processi; il suo prototipo è:
2078 \begin{prototype}{sys/resource.h}
2079 {int setpriority(int which, int who, int prio)}  
2080   Imposta la priorità per l'insieme dei processi specificati.
2081
2082   \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2083     errore, nel qual caso \var{errno} può assumere i valori:
2084   \begin{errlist}
2085   \item[\macro{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2086   \param{which} e \param{who}.
2087   \item[\macro{EINVAL}] il valore di \param{which} non è valido.
2088   \item[\macro{EPERM}] un processo senza i privilegi di amministratore ha
2089     specificato un valore di \param{inc} negativo.
2090   \item[\macro{EACCESS}] un processo senza i privilegi di amministratore ha
2091     cercato di modificare la priorità di un processo di un altro utente.
2092   \end{errlist}}
2093 \end{prototype}
2094
2095 La funzione imposta la priorità al valore specificato da \param{prio} per
2096 tutti i processi indicati dagli argomenti \param{which} e \param{who}.  La
2097 gestione dei permessi dipende dalle varie implementazioni; in Linux, secondo
2098 le specifiche dello standard SUSv3, e come avviene per tutti i sistemi che
2099 derivano da SYSV, è richiesto che l'userid reale o effettivo del processo
2100 chiamante corrispondano al real user id (e solo quello) del processo di cui si
2101 vuole cambiare la priorità; per i sistemi derivati da BSD invece (SunOS,
2102 Ultrix, *BSD) la corrispondenza può essere anche con l'userid effettivo.
2103
2104
2105
2106 \subsection{Il meccanismo di \textit{scheduling real-time}}
2107 \label{sec:proc_real_time}
2108
2109 Come spiegato in \secref{sec:proc_sched} lo standard POSIX.1b ha introdotto le
2110 priorità assolute per permettere la gestione di processi real-time. In realtà
2111 nel caso di Linux non si tratta di un vero hard real-time, in quanto in
2112 presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
2113 processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
2114   siano installate le patch di RTLinux o RTAI, con i quali è possibile
2115   ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
2116   interrupt vengono intercettati dall'interfaccia real-time, e gestiti
2117   direttamente qualora ci sia la necessità di avere un processo con priorità
2118   più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
2119 page fault\index{page fault} si possono avere ritardi non previsti. Se
2120 l'ultimo problema può essere aggirato attraverso l'uso delle funzioni di
2121 controllo della memoria virtuale (vedi \secref{sec:proc_mem_lock}), il primo
2122 non è superabile e può comportare ritardi non prevedibili riguardo ai tempi di
2123 esecuzione di qualunque processo.
2124
2125 In ogni caso occorre usare le priorità assolute con molta attenzione: se si dà
2126 ad un processo una priorità assoluta e questo finisce in un loop infinito,
2127 nessun altro processo potrà essere eseguito, ed esso sarà mantenuto in
2128 esecuzione permanentemente assorbendo tutta la CPU e senza nessuna possibilità
2129 di riottenere l'accesso al sistema. Per questo motivo è sempre opportuno,
2130 quando si lavora con processi che usano priorità assolute, tenere attiva una
2131 shell cui si sia assegnata la massima priorità assoluta, in modo da poter
2132 essere comunque in grado di rientrare nel sistema.
2133
2134 Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
2135 esecuzione prima di ogni processo normale. In caso di più processi sarà
2136 eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
2137 processi con la stessa priorità assoluta questi vengono tenuti in una coda
2138 tocca al kernel decidere quale deve essere eseguito. 
2139
2140
2141
2142 Il meccanismo con cui vengono gestiti questi processi dipende dalla politica
2143 di scheduling che si è scelto; lo standard ne prevede due:
2144 \begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
2145 \item[\textit{FIFO}] il processo viene eseguito fintanto che non cede
2146   volontariamente la CPU, si blocca, finisce o viene interrotto da un processo
2147   a priorità più alta.
2148 \item[\textit{Round Robin}] ciascun processo viene eseguito a turno per un
2149   certo periodo di tempo (una \textit{time slice}). Solo i processi con la
2150   stessa priorità ed in stato \textit{runnable} entrano nel circolo.
2151 \end{basedescript}
2152
2153 La funzione per impostare le politiche di scheduling (sia real-time che
2154 ordinarie) ed i relativi parametri è \func{sched\_setscheduler}; il suo
2155 prototipo è:
2156 \begin{prototype}{sched.h}
2157 {int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)}
2158   Imposta priorità e politica di scheduling per il processo \param{pid}.
2159
2160   \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2161     errore, nel qual caso \var{errno} può assumere i valori:
2162     \begin{errlist}
2163     \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2164     \item[\macro{EINVAL}] il valore di \param{policy} non esiste o il relativo
2165       valore di \param{p} non è valido.
2166     \item[\macro{EPERM}] il processo non ha i privilegi per attivare la
2167       politica richiesta (vale solo per \macro{SCHED\_FIFO} e
2168       \macro{SCHED\_RR}).
2169   \end{errlist}}
2170 \end{prototype}
2171
2172 La funzione esegue l'impostazione per il processo specificato; un valore nullo
2173 di \param{pid} esegue l'impostazione per il processo corrente, solo un
2174 processo con i privilegi di amministratore può impostare delle priorità
2175 assolute diverse da zero. La politica di scheduling è specificata
2176 dall'argomento \param{policy} i cui possibili valori sono riportati in
2177 \tabref{tab:proc_sched_policy}; un valore negativo per \param{policy} mantiene
2178 la politica di scheduling corrente.
2179
2180 \begin{table}[htb]
2181   \centering
2182   \footnotesize
2183   \begin{tabular}[c]{|c|l|}
2184     \hline
2185     \textbf{Policy}  & \textbf{Significato} \\
2186     \hline
2187     \hline
2188     \macro{SCHED\_FIFO} & Scheduling real-time con politica \textit{FIFO} \\
2189     \macro{SCHED\_RR}   & Scheduling real-time con politica \textit{Round
2190     Robin} \\
2191     \macro{SCHED\_OTHER}& Scheduling ordinario\\
2192     \hline
2193   \end{tabular}
2194   \caption{Valori dell'argomento \param{policy}  per la funzione
2195     \func{sched\_setscheduler}. }
2196   \label{tab:proc_sched_policy}
2197 \end{table}
2198
2199 Il valore della priorità è passato attraverso la struttura \var{sched\_param}
2200 (riportata in \figref{fig:sig_sched_param}), il cui solo campo attualmente
2201 definito è \var{sched\_priority}, che nel caso delle priorità assolute deve
2202 essere specificato nell'intervallo fra un valore massimo ed uno minimo, che
2203 nel caso sono rispettivamente 1 e 99 (il valore zero è legale, ma indica i
2204 processi normali).
2205
2206 \begin{figure}[!htb]
2207   \footnotesize \centering
2208   \begin{minipage}[c]{15cm}
2209     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
2210 struct sched_param {
2211     int sched_priority;
2212 };
2213     \end{lstlisting}
2214   \end{minipage} 
2215   \normalsize 
2216   \caption{La struttura \var{sched\_param}.} 
2217   \label{fig:sig_sched_param}
2218 \end{figure}
2219
2220
2221
2222 Lo standard POSIX.1b prevede comunque che i due valori della massima e minima
2223 priorità statica possano essere ottenuti, per ciascuna delle politiche di
2224 scheduling realtime, tramite le due funzioni \func{sched\_get\_priority\_max}
2225 e \func{sched\_get\_priority\_min}, i cui prototipi sono:
2226 \begin{functions}
2227   \headdecl{sched.h}
2228   
2229   \funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore
2230   massimo della priorità statica per la politica di scheduling \param{policy}.
2231
2232   
2233   \funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo
2234   della priorità statica per la politica di scheduling \param{policy}.
2235   
2236   \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
2237     e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2238     \begin{errlist}
2239     \item[\macro{EINVAL}] il valore di \param{policy} è invalido.
2240   \end{errlist}}
2241 \end{functions}
2242
2243
2244 I processi con politica di scheduling \macro{SCHED\_OTHER} devono specificare
2245 un valore nullo (altrimenti si avrà un errore \macro{EINVAL}), questo valore
2246 infatti non ha niente a che vedere con la priorità dinamica determinata dal
2247 valore di \var{nice}, che deve essere impostato con le funzioni viste in
2248 precedenza.
2249
2250 Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
2251 esegue sempre il primo della lista, mentre un nuovo processo che torna in
2252 stato \textit{runnable} viene sempre inserito in coda alla lista. Se la
2253 politica scelta è \macro{SCHED\_FIFO} quando il processo viene eseguito viene
2254 automaticamente rimesso in coda alla lista, e la sua esecuzione continua
2255 fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
2256 volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
2257 sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
2258 nel caso che esso sia stato interrotto da un processo a priorità più alta.
2259
2260 La priorità assoluta può essere riletta indietro dalla funzione
2261 \func{sched\_getscheduler}, il cui prototipo è:
2262 \begin{prototype}{sched.h}
2263 {int sched\_getscheduler(pid\_t pid)}
2264   Legge la politica di scheduling per il processo \param{pid}.
2265   
2266   \bodydesc{La funzione ritorna la politica di scheduling in caso di successo
2267     e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2268     \begin{errlist}
2269     \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2270     \item[\macro{EINVAL}] il valore di \param{pid} è negativo.
2271   \end{errlist}}
2272 \end{prototype}
2273
2274 La funzione restituisce il valore (secondo la quanto elencato in
2275 \tabref{tab:proc_sched_policy}) della politica di scheduling per il processo
2276 specificato; se \param{pid} è nullo viene restituito quello del processo
2277 chiamante.
2278
2279 Se si intende operare solo sulla priorità assoluta di un processo si possono
2280 usare le funzioni \func{sched\_setparam} e \func{sched\_getparam}, i cui
2281 prototipi sono:
2282   
2283 \begin{functions}
2284   \headdecl{sched.h}
2285
2286   \funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *p)}
2287   Imposta la priorità assoluta del processo \param{pid}.
2288
2289
2290   \funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *p)}
2291   Legge la priorità assoluta del processo \param{pid}.
2292
2293   \bodydesc{La funzione ritorna la priorità  in caso di successo
2294     e -1 in caso di errore, nel qual caso \var{errno} può assumere i valori:
2295     \begin{errlist}
2296     \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2297     \item[\macro{EINVAL}] il valore di \param{pid} è negativo.
2298   \end{errlist}}
2299 \end{functions}
2300
2301 L'uso di \func{sched\_setparam} che è del tutto equivalente a
2302 \func{sched\_setscheduler} con \param{priority} uguale a -1. Come per
2303 \func{sched\_setscheduler} specificando 0 come valore di \param{pid} si opera
2304 sul processo corrente. La disponibilità di entrambe le funzioni può essere
2305 verificata controllando la macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è
2306 definita nell'header \macro{sched.h}.
2307
2308 L'ultima funzione che permette di leggere le informazioni relative ai processi
2309 real-time è \func{sched\_rr\_get\_interval}, che permette di ottenere la
2310 lunghezza della \textit{time slice} usata dalla politica \textit{round robin};
2311 il suo prototipo è:
2312 \begin{prototype}{sched.h}
2313   {int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in
2314   \param{tp} la durata della \textit{time slice} per il processo \param{pid}.
2315   
2316   \bodydesc{La funzione ritorna 0in caso di successo e -1 in caso di errore,
2317     nel qual caso \var{errno} può assumere i valori:
2318     \begin{errlist}
2319     \item[\macro{ESRCH}] il processo \param{pid} non esiste.
2320     \item[\macro{ENOSYS}] la system call non è stata implementata.
2321   \end{errlist}}
2322 \end{prototype}
2323
2324 La funzione restituisce il valore dell'intervallo di tempo usato per la
2325 politica \textit{round robin} in una struttura \var{timespec}, (la cui
2326 definizione si può trovare in \figref{fig:sys_timeval_struct}).
2327
2328
2329 Come accennato ogni processo che usa lo scheduling real-time può rilasciare
2330 volontariamente la CPU; questo viene fatto attraverso la funzione
2331 \func{sched\_yield}, il cui prototipo è:
2332 \begin{prototype}{sched.h}
2333   {int sched\_yield(void)} 
2334   
2335   Rilascia volontariamente l'esecuzione.
2336   
2337   \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
2338     nel qual caso \var{errno} viene impostata opportunamente.}
2339 \end{prototype}
2340
2341 La funzione fa si che il processo rilasci la CPU, in modo da essere rimesso in
2342 coda alla lista dei processi da eseguire, e permettere l'esecuzione di un
2343 altro processo; se però il processo è l'unico ad essere presente sulla coda
2344 l'esecuzione non sarà interrotta. In genere usano questa funzione i processi
2345 in modalità \textit{fifo}, per permettere l'esecuzione degli altri processi
2346 con pari priorità quando la sezione più urgente è finita.
2347
2348
2349 \section{Problematiche di programmazione multitasking}
2350 \label{sec:proc_multi_prog}
2351
2352 Benché i processi siano strutturati in modo da apparire il più possibile come
2353 indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
2354 occorre tenere conto di una serie di problematiche che normalmente non
2355 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
2356 programma alla volta.
2357
2358 Pur essendo questo argomento di carattere generale, ci è parso opportuno
2359 introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
2360 in capitoli successivi, in questa sezione conclusiva del capitolo in cui
2361 abbiamo affrontato la gestione dei processi.
2362
2363
2364 \subsection{Le operazioni atomiche}
2365 \label{sec:proc_atom_oper}
2366
2367 La nozione di \textsl{operazione atomica} deriva dal significato greco della
2368 parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
2369 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
2370 che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
2371 di interruzione in una fase intermedia.
2372
2373 In un ambiente multitasking il concetto è essenziale, dato che un processo può
2374 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
2375 altro processo o dalla ricezione di un segnale; occorre pertanto essere
2376 accorti nei confronti delle possibili 
2377 \textit{race condition}\index{race condition} (vedi
2378 \secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in
2379 cui non erano ancora state completate.
2380
2381 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
2382 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
2383 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
2384 \capref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
2385 \secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
2386 funzioni di libreria per compiere le operazioni necessarie è garanzia
2387 sufficiente di atomicità in quanto le system call con cui esse sono realizzate
2388 non possono essere interrotte (o subire interferenze pericolose) da altri
2389 processi.
2390
2391 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
2392 stesso processo, e pure alcune system call, possono essere interrotti in
2393 qualunque momento, e le operazioni di un eventuale \textit{signal handler}
2394 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
2395 il solo accesso o l'assegnazione di una variabile possono non essere più
2396 operazioni atomiche (torneremo su questi aspetti in
2397 \secref{sec:sig_control}).
2398
2399 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
2400 il cui accesso è assicurato essere atomico.  In pratica comunque si può
2401 assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
2402 \ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
2403 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
2404 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
2405 le strutture. In tutti questi casi è anche opportuno marcare come
2406 \ctyp{volatile} le variabili che possono essere interessate ad accesso
2407 condiviso, onde evitare problemi con le ottimizzazioni del codice.
2408
2409
2410
2411 \subsection{Le \textit{race condition}\index{race condition} e i 
2412   \textit{deadlock}}
2413 \label{sec:proc_race_cond}
2414
2415 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
2416 diversi operano su una risorsa comune, ed in cui il risultato viene a
2417 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
2418 tipico è quello di un'operazione che viene eseguita da un processo in più
2419 passi, e può essere compromessa dall'intervento di un altro processo che
2420 accede alla stessa risorsa quando ancora non tutti i passi sono stati
2421 completati.
2422
2423 Dato che in un sistema multitasking ogni processo può essere interrotto in
2424 qualunque momento per farne subentrare un'altro in esecuzione, niente può
2425 assicurare un preciso ordine di esecuzione fra processi diversi o che una
2426 sezione di un programma possa essere eseguita senza interruzioni da parte di
2427 altri. Queste situazioni comportano pertanto errori estremamente subdoli e
2428 difficili da tracciare, in quanto nella maggior parte dei casi tutto
2429 funzionerà regolarmente, e solo occasionalmente si avranno degli errori. 
2430
2431 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
2432 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
2433 gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
2434 \textit{race condition} si hanno quando diversi processi accedono allo stesso
2435 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
2436 condivisa. In questi casi, se non si dispone della possibilità di eseguire
2437 atomicamente le operazioni necessarie, occorre che quelle parti di codice in
2438 cui si compiono le operazioni sulle risorse condivise (le cosiddette
2439 \textsl{sezioni critiche}\index{sezioni critiche}) del programma, siano
2440 opportunamente protette da meccanismi di sincronizzazione (torneremo su queste
2441 problematiche di questo tipo in \capref{cha:IPC}).
2442
2443 Un caso particolare di \textit{race condition} sono poi i cosiddetti
2444 \textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
2445 completo di un servizio, e non il fallimento di una singola operazione.
2446 L'esempio tipico di una situazione che può condurre ad un \textit{deadlock} è
2447 quello in cui un flag di ``occupazione'' viene rilasciato da un evento
2448 asincrono (come un segnale o un altro processo) fra il momento in cui lo si è
2449 controllato (trovandolo occupato) e la successiva operazione di attesa per lo
2450 sblocco. In questo caso, dato che l'evento di sblocco del flag è avvenuto
2451 senza che ce ne accorgessimo proprio fra il controllo e la messa in attesa,
2452 quest'ultima diventerà perpetua (da cui il nome di \textit{deadlock}).
2453
2454 In tutti questi casi è di fondamentale importanza il concetto di atomicità
2455 visto in \secref{sec:proc_atom_oper}; questi problemi infatti possono essere
2456 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
2457 eseguire in maniera atomica le operazioni necessarie.
2458
2459
2460 \subsection{Le funzioni rientranti}
2461 \label{sec:proc_reentrant}
2462
2463 Si dice \textsl{rientrante} una funzione che può essere interrotta in
2464 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
2465 un altro thread di esecuzione senza che questo comporti nessun problema
2466 nell'esecuzione della stessa. La problematica è comune nella programmazione
2467 multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare
2468 delle funzioni all'interno dei manipolatori dei segnali.
2469
2470 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
2471 queste infatti vengono allocate nello stack, e un'altra invocazione non fa
2472 altro che allocarne un'altra copia. Una funzione può non essere rientrante
2473 quando opera su memoria che non è nello stack.  Ad esempio una funzione non è
2474 mai rientrante se usa una variabile globale o statica.
2475
2476 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
2477 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
2478 ogni volta e ritornato indietro la funzione può essere rientrante, se invece
2479 esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
2480 potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
2481 Allo stesso modo una funzione può non essere rientrante se usa e modifica un
2482 oggetto che le viene fornito dal chiamante: due chiamate possono interferire
2483 se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
2484 parte del programmatore.
2485
2486 In genere le funzioni di libreria non sono rientranti, molte di esse ad
2487 esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
2488 disposizione due macro di compilatore, \macro{\_REENTRANT} e
2489 \macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
2490 varie funzioni di libreria, che sono identificate aggiungendo il suffisso
2491 \code{\_r} al nome della versione normale.
2492
2493
2494
2495 %%% Local Variables: 
2496 %%% mode: latex
2497 %%% TeX-master: "gapil"
2498 %%% End: