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