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