Correzioni per execve e setuid.
[gapil.git] / prochand.tex
1 %% prochand.tex
2 %%
3 %% Copyright (C) 2000-2018 by 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
12 \chapter{La gestione dei processi}
13 \label{cha:process_handling}
14
15 Come accennato nell'introduzione in un sistema unix-like tutte le operazioni
16 vengono svolte tramite opportuni processi.  In sostanza questi ultimi vengono
17 a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
18
19 Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come
20 unità a se stante, in questo esamineremo il funzionamento dei processi
21 all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
22 della terminazione dei processi, della gestione dei loro attributi e
23 privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione
24 finale introdurremo alcune problematiche generiche della programmazione in
25 ambiente multitasking.
26
27
28 \section{Le funzioni di base della gestione dei processi}
29 \label{sec:proc_handling}
30
31 In questa sezione tratteremo le problematiche della gestione dei processi
32 all'interno del sistema, illustrandone tutti i dettagli.  Inizieremo con una
33 panoramica dell'architettura dei processi, tratteremo poi le funzioni
34 elementari che permettono di leggerne gli identificatori, per poi passare alla
35 spiegazione delle funzioni base che si usano per la creazione e la
36 terminazione dei processi, e per la messa in esecuzione degli altri programmi.
37
38
39 \subsection{L'architettura della gestione dei processi}
40 \label{sec:proc_hierarchy}
41
42 A differenza di quanto avviene in altri sistemi, ad esempio nel VMS, dove la
43 generazione di nuovi processi è un'operazione privilegiata, una delle
44 caratteristiche fondanti di Unix, che esamineremo in dettaglio più avanti, è
45 che qualunque processo può a sua volta generarne altri. Ogni processo è
46 identificato presso il sistema da un numero univoco, il cosiddetto
47 \textit{Process ID}, o più brevemente \ids{PID}, assegnato in forma
48 progressiva (vedi sez.~\ref{sec:proc_pid}) quando il processo viene creato.
49
50 Una seconda caratteristica di un sistema unix-like è che la generazione di un
51 processo è un'operazione separata rispetto al lancio di un programma. In
52 genere la sequenza è sempre quella di creare un nuovo processo, il quale
53 eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
54 quello che fa la shell quando mette in esecuzione il programma che gli
55 indichiamo nella linea di comando.
56
57 Una terza caratteristica del sistema è che ogni processo è sempre stato
58 generato da un altro processo, il processo generato viene chiamato
59 \textit{processo figlio} (\textit{child process}) mentre quello che lo ha
60 generato viene chiamato \textsl{processo padre} (\textit{parent
61   process}). Questo vale per tutti i processi, con una sola eccezione; dato
62 che ci deve essere un punto di partenza esiste un processo iniziale (che
63 normalmente è \cmd{/sbin/init}), che come accennato in
64 sez.~\ref{sec:intro_kern_and_sys} viene lanciato dal kernel alla conclusione
65 della fase di avvio. Essendo questo il primo processo lanciato dal sistema ha
66 sempre \ids{PID} uguale a 1 e non è figlio di nessun altro processo.
67
68 Ovviamente \cmd{init} è un processo particolare che in genere si occupa di
69 lanciare tutti gli altri processi necessari al funzionamento del sistema,
70 inoltre \cmd{init} è essenziale per svolgere una serie di compiti
71 amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
72 essi in sez.~\ref{sec:proc_termination}) e non può mai essere terminato. La
73 struttura del sistema comunque consente di lanciare al posto di \cmd{init}
74 qualunque altro programma, e in casi di emergenza (ad esempio se il file di
75 \cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
76 posto.\footnote{la cosa si fa passando la riga \cmd{init=/bin/sh} come
77   parametro di avvio del kernel, l'argomento è di natura sistemistica e
78   trattato in sez.~5.3 di \cite{AGL}.}
79
80 \begin{figure}[!htb]
81   \footnotesize
82 \begin{Console}
83 [piccardi@gont piccardi]$ \textbf{pstree -n} 
84 init-+-keventd
85      |-kapm-idled
86      |-kreiserfsd
87      |-portmap
88      |-syslogd
89      |-klogd
90      |-named
91      |-rpc.statd
92      |-gpm
93      |-inetd
94      |-junkbuster
95      |-master-+-qmgr
96      |        `-pickup
97      |-sshd
98      |-xfs
99      |-cron
100      |-bash---startx---xinit-+-XFree86
101      |                       `-WindowMaker-+-ssh-agent
102      |                                     |-wmtime
103      |                                     |-wmmon
104      |                                     |-wmmount
105      |                                     |-wmppp
106      |                                     |-wmcube
107      |                                     |-wmmixer
108      |                                     |-wmgtemp
109      |                                     |-wterm---bash---pstree
110      |                                     `-wterm---bash-+-emacs
111      |                                                    `-man---pager
112      |-5*[getty]
113      |-snort
114      `-wwwoffled
115 \end{Console}
116 %$
117   \caption{L'albero dei processi, così come riportato dal comando
118     \cmd{pstree}.}
119   \label{fig:proc_tree}
120 \end{figure}
121
122 Dato che tutti i processi attivi nel sistema sono comunque generati da
123 \cmd{init} o da uno dei suoi figli si possono classificare i processi con la
124 relazione padre/figlio in un'organizzazione gerarchica ad albero. In
125 fig.~\ref{fig:proc_tree} si è mostrato il risultato del comando \cmd{pstree}
126 che permette di visualizzare questa struttura, alla cui base c'è \cmd{init}
127 che è progenitore di tutti gli altri processi.\footnote{in realtà questo non è
128   del tutto vero, in Linux, specialmente nelle versioni più recenti del
129   kernel, ci sono alcuni processi speciali (come \cmd{keventd}, \cmd{kswapd},
130   ecc.) che pur comparendo nei comandi come figli di \cmd{init}, o con
131   \ids{PID} successivi ad uno, sono in realtà processi interni al kernel e che
132   non rientrano in questa classificazione.}
133
134 \itindbeg{process~table}
135
136 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
137 \textit{process table}. Per ciascun processo viene mantenuta una voce in
138 questa tabella, costituita da una struttura \kstruct{task\_struct}, che
139 contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
140 usate a questo scopo sono dichiarate nell'\textit{header file}
141 \file{linux/sched.h}, ed in fig.~\ref{fig:proc_task_struct} si è riportato uno
142 schema semplificato che mostra la struttura delle principali informazioni
143 contenute nella \texttt{task\_struct}, che in seguito incontreremo a più
144 riprese.
145
146 \begin{figure}[!htb]
147   \centering \includegraphics[width=14cm]{img/task_struct}
148   \caption{Schema semplificato dell'architettura delle strutture (
149     \kstructd{task\_struct}, \kstructd{fs\_struct}, \kstructd{file\_struct})
150     usate dal kernel nella gestione dei processi.}
151   \label{fig:proc_task_struct}
152 \end{figure}
153
154 \itindend{process~table}
155
156 % TODO la task_struct è cambiata per qualche dettaglio vedi anche
157 % http://www.ibm.com/developerworks/linux/library/l-linux-process-management/
158 % TODO completare la parte su quando viene chiamato lo scheduler.
159
160 \itindbeg{scheduler}
161
162 Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \textit{scheduler} che
163 decide quale processo mettere in esecuzione; esso viene eseguito in occasione
164 di dell'invocazione di ogni \textit{system call} ed per ogni interrupt
165 dall'hardware oltre che in una serie di altre occasioni, e può essere anche
166 attivato esplicitamente. Il timer di sistema provvede comunque a che esso sia
167 invocato periodicamente, generando un interrupt periodico secondo una
168 frequenza predeterminata, specificata dalla costante \const{HZ} del kernel
169 (torneremo su questo argomento in sez.~\ref{sec:sys_unix_time}), che assicura
170 che lo \textit{scheduler} venga comunque eseguito ad intervalli regolari e
171 possa prendere le sue decisioni.
172
173 A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo
174 completamente diverso, detto \textit{tickless}, in cui non c'è più una
175 interruzione periodica con frequenza prefissata, ma ad ogni chiamata del timer
176 viene programmata l'interruzione successiva sulla base di una stima; in questo
177 modo si evita di dover eseguire un migliaio di interruzioni al secondo anche
178 su macchine che non stanno facendo nulla, con un forte risparmio nell'uso
179 dell'energia da parte del processore che può essere messo in stato di
180 sospensione anche per lunghi periodi di tempo.
181
182 Ma, indipendentemente dalle motivazioni per cui questo avviene, ogni volta che
183 viene eseguito lo \textit{scheduler} effettua il calcolo delle priorità dei
184 vari processi attivi (torneremo su questo in sez.~\ref{sec:proc_priority}) e
185 stabilisce quale di essi debba essere posto in esecuzione fino alla successiva
186 invocazione.
187
188 \itindend{scheduler}
189
190 \subsection{Gli identificatori dei processi}
191 \label{sec:proc_pid}
192
193 \itindbeg{Process~ID~(PID)}
194
195 Come accennato nella sezione precedente ogni processo viene identificato dal
196 sistema da un numero identificativo univoco, il \textit{process ID} o
197 \ids{PID}. Questo è un tipo di dato standard, \type{pid\_t}, che in genere è un
198 intero con segno (nel caso di Linux e della \acr{glibc} il tipo usato è
199 \ctyp{int}).
200
201 Il \ids{PID} viene assegnato in forma progressiva ogni volta che un nuovo
202 processo viene creato,\footnote{in genere viene assegnato il numero successivo
203   a quello usato per l'ultimo processo creato, a meno che questo numero non
204   sia già utilizzato per un altro \ids{PID}, \acr{pgid} o \acr{sid} (vedi
205   sez.~\ref{sec:sess_proc_group}).} fino ad un limite che, essendo il
206 tradizionalmente il \ids{PID} un numero positivo memorizzato in un intero a 16
207 bit, arriva ad un massimo di 32768.  Oltre questo valore l'assegnazione
208 riparte dal numero più basso disponibile a partire da un minimo di
209 300,\footnote{questi valori, fino al kernel 2.4.x, erano definiti dalla macro
210   \constd{PID\_MAX} nei file \file{threads.h} e \file{fork.c} dei sorgenti del
211   kernel, con il 2.6.x e la nuova interfaccia per i \textit{thread} anche il
212   meccanismo di allocazione dei \ids{PID} è stato modificato ed il valore
213   massimo è impostabile attraverso il file \sysctlfiled{kernel/pid\_max} e di
214   default vale 32768.} che serve a riservare i \ids{PID} più bassi ai processi
215 eseguiti direttamente dal kernel.  Per questo motivo, come visto in
216 sez.~\ref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha sempre il
217 \ids{PID} uguale a uno.
218
219 \itindbeg{Parent~Process~ID~(PPID)} 
220
221 Tutti i processi inoltre memorizzano anche il \ids{PID} del genitore da cui
222 sono stati creati, questo viene chiamato in genere \ids{PPID} (da
223 \textit{Parent Process ID}).  Questi due identificativi possono essere
224 ottenuti usando le due funzioni di sistema \funcd{getpid} e \funcd{getppid}, i
225 cui prototipi sono:
226
227 \begin{funcproto}{ 
228 \fhead{sys/types.h}
229 \fhead{unistd.h}
230 \fdecl{pid\_t getpid(void)}
231 \fdesc{Restituisce il \ids{PID} del processo corrente..} 
232 \fdecl{pid\_t getppid(void)}
233 \fdesc{Restituisce il \ids{PID} del padre del processo corrente.} 
234 }
235 {Entrambe le funzioni non riportano condizioni di errore.}   
236 \end{funcproto}
237
238 \noindent esempi dell'uso di queste funzioni sono riportati in
239 fig.~\ref{fig:proc_fork_code}, nel programma \file{fork\_test.c}.
240
241 Il fatto che il \ids{PID} sia un numero univoco per il sistema lo rende un
242 candidato per generare ulteriori indicatori associati al processo di cui
243 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
244 funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
245 \ids{PID} per generare un \textit{pathname} univoco, che non potrà essere
246 replicato da un altro processo che usi la stessa funzione. Questo utilizzo
247 però può risultare pericoloso, un \ids{PID} infatti è univoco solo fintanto
248 che un processo è attivo, una volta terminato esso potrà essere riutilizzato
249 da un processo completamente diverso, e di questo bisogna essere ben
250 consapevoli.
251
252 Tutti i processi figli dello stesso processo padre sono detti
253 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
254   sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
255 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
256 cap.~\ref{cha:session}, dove esamineremo gli altri identificativi associati ad
257 un processo e le varie relazioni fra processi utilizzate per definire una
258 sessione.
259
260 Oltre al \ids{PID} e al \ids{PPID}, e a quelli che vedremo in
261 sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione, ad ogni
262 processo vengono associati degli ulteriori identificatori ed in particolare
263 quelli che vengono usati per il controllo di accesso.  Questi servono per
264 determinare se un processo può eseguire o meno le operazioni richieste, a
265 seconda dei privilegi e dell'identità di chi lo ha posto in esecuzione;
266 l'argomento è complesso e sarà affrontato in dettaglio in
267 sez.~\ref{sec:proc_perms}.
268
269 \itindend{Process~ID~(PID)}
270 \itindend{Parent~Process~ID~(PPID)} 
271
272 \subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
273 \label{sec:proc_fork}
274
275 La funzione di sistema \func{fork} è la funzione fondamentale della gestione
276 dei processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
277 processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
278   \textit{system call} usata da Linux per creare nuovi processi è \func{clone}
279   (vedi \ref{sec:process_clone}), anche perché a partire dalla \acr{glibc}
280   2.3.3 non viene più usata la \textit{system call} originale, ma la stessa
281   \func{fork} viene implementata tramite \func{clone}, cosa che consente una
282   migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
283 centrale tutte le volte che si devono scrivere programmi che usano il
284 multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei
285   \textit{thread}\unavref{ che tratteremo al cap.~\ref{cha:threads}}, è in
286   parte minore, ma \func{fork} resta comunque la funzione principale per la
287   creazione di processi.} Il prototipo di \funcd{fork} è:
288
289 \begin{funcproto}{ 
290 \fhead{unistd.h}
291 \fdecl{pid\_t fork(void)}
292 \fdesc{Crea un nuovo processo.} 
293 }
294
295 {La funzione ritorna in caso di successo il \ids{PID} del figlio nel padre e
296   $0$ nel figlio mentre ritorna $-1$ nel padre, senza creare il figlio, per un
297   errore, al caso \var{errno} assumerà uno dei valori:
298   \begin{errlist}
299   \item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro
300     processo (per allocare la tabella delle pagine e le strutture del task) o
301     si è esaurito il numero di processi disponibili.
302   \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
303     strutture necessarie al kernel per creare il nuovo processo.
304   \end{errlist}}
305 \end{funcproto}
306
307 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
308 il processo figlio continuano ad essere eseguiti normalmente, a partire
309 dall'istruzione successiva alla \func{fork}. Il processo figlio è una copia
310 del padre, e riceve una copia dei segmenti di testo, dati e dello
311 \textit{stack} (vedi sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo
312 stesso codice del padre. Si tenga presente però che la memoria è copiata e non
313 condivisa, pertanto padre e figlio vedranno variabili diverse e le eventuali
314 modifiche saranno totalmente indipendenti.
315
316 \itindbeg{copy~on~write}
317
318 Per quanto riguarda la gestione della memoria, in generale il segmento di
319 testo, che è identico per i due processi, è condiviso e tenuto in sola lettura
320 per il padre e per i figli. Per gli altri segmenti Linux utilizza la tecnica
321 del \textit{copy on write}. Questa tecnica comporta che una pagina di memoria
322 viene effettivamente copiata per il nuovo processo solo quando ci viene
323 effettuata sopra una scrittura, e si ha quindi una reale differenza fra padre
324 e figlio.  In questo modo si rende molto più efficiente il meccanismo della
325 creazione di un nuovo processo, non essendo più necessaria la copia di tutto
326 lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di memoria
327 che sono state modificate, e solo al momento della modifica stessa.
328
329 \itindend{copy~on~write}
330
331 La differenza che si ha nei due processi è che nel processo padre il valore di
332 ritorno della funzione \func{fork} è il \ids{PID} del processo figlio, mentre
333 nel figlio è zero; in questo modo il programma può identificare se viene
334 eseguito dal padre o dal figlio.  Si noti come la funzione \func{fork} ritorni
335 due volte, una nel padre e una nel figlio.
336
337 La scelta di questi valori di ritorno non è casuale, un processo infatti può
338 avere più figli, ed il valore di ritorno di \func{fork} è l'unico che gli
339 permette di identificare qual è quello appena creato. Al contrario un figlio
340 ha sempre un solo padre il cui \ids{PID}, come spiegato in
341 sez.~\ref{sec:proc_pid}, può sempre essere ottenuto con \func{getppid}; per
342 questo si ritorna un valore nullo, che non è il \ids{PID} di nessun processo.
343
344 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni: o ci
345 sono già troppi processi nel sistema, il che di solito è sintomo che
346 qualcos'altro non sta andando per il verso giusto, o si è ecceduto il limite
347 sul numero totale di processi permessi all'utente, argomento che tratteremo in
348 dettaglio in sez.~\ref{sec:sys_resource_limit}.
349
350 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
351 quella in cui all'interno di un programma si creano processi figli cui viene
352 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
353 ne esegue un'altra. È il caso tipico dei programmi server (il modello
354 \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}) in cui il
355 padre riceve ed accetta le richieste da parte dei programmi client, per
356 ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
357 le risposte associate al servizio.
358
359 La seconda modalità è quella in cui il processo vuole eseguire un altro
360 programma; questo è ad esempio il caso della shell. In questo caso il processo
361 crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
362 cui parleremo in sez.~\ref{sec:proc_exec}) subito dopo la \func{fork}.
363
364 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
365 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
366 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
367 scelto di mantenere questa separazione, dato che, come per la prima modalità
368 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
369 aver bisogno di eseguire una \func{exec}. 
370
371 Inoltre, anche nel caso della seconda modalità d'uso, avere le due funzioni
372 separate permette al figlio di cambiare alcune caratteristiche del processo
373 (maschera dei segnali, redirezione dell'output, utente per conto del cui viene
374 eseguito, e molto altro su cui torneremo in seguito) prima della \func{exec},
375 rendendo così relativamente facile intervenire sulle le modalità di esecuzione
376 del nuovo programma.
377
378 \begin{figure}[!htb]
379   \footnotesize \centering
380   \begin{minipage}[c]{\codesamplewidth}
381   \includecodesample{listati/fork_test.c}
382   \end{minipage}
383   \normalsize
384   \caption{Esempio di codice per la creazione di nuovi processi (da
385     \file{fork\_test.c}).}
386   \label{fig:proc_fork_code}
387 \end{figure}
388
389 In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
390 di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
391 dell'uso della funzione \func{fork}. Il programma crea un numero di figli
392 specificato da linea di comando, e prende anche alcune opzioni per indicare
393 degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
394 \func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
395 descrizione delle opzioni). Il codice completo, compresa la parte che gestisce
396 le opzioni a riga di comando, è disponibile nel file \file{fork\_test.c},
397 distribuito insieme agli altri sorgenti degli esempi della guida su
398 \url{http://gapil.gnulinux.it}.
399
400 Decifrato il numero di figli da creare, il ciclo principale del programma
401 (\texttt{\small 24-40}) esegue in successione la creazione dei processi figli
402 controllando il successo della chiamata a \func{fork} (\texttt{\small
403   25-29}); ciascun figlio (\texttt{\small 31-34}) si limita a stampare il
404 suo numero di successione, eventualmente attendere il numero di secondi
405 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
406 (\texttt{\small 36-38}) stampa un messaggio di creazione, eventualmente
407 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
408 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
409 periodo di attesa.
410
411 Se eseguiamo il comando, che è preceduto dall'istruzione \code{export
412   LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche, senza
413 specificare attese (come si può notare in (\texttt{\small 17-19}) i valori
414 predefiniti specificano di non attendere), otterremo come risultato sul
415 terminale:
416 \begin{Console}
417 [piccardi@selidor sources]$ \textbf{export LD_LIBRARY_PATH=./; ./forktest 3}
418 Process 1963: forking 3 child
419 Spawned 1 child, pid 1964 
420 Child 1 successfully executing
421 Child 1, parent 1963, exiting
422 Go to next child 
423 Spawned 2 child, pid 1965 
424 Child 2 successfully executing
425 Child 2, parent 1963, exiting
426 Go to next child 
427 Child 3 successfully executing
428 Child 3, parent 1963, exiting
429 Spawned 3 child, pid 1966 
430 Go to next child 
431 \end{Console}
432 %$
433
434 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
435 si può dire quale processo fra il padre ed il figlio venga eseguito per primo
436 dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei
437 primi due cicli sia stato eseguito per primo il padre (con la stampa del
438 \ids{PID} del nuovo processo) per poi passare all'esecuzione del figlio
439 (completata con i due avvisi di esecuzione ed uscita), e tornare
440 all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
441 mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
442 e poi il padre.
443
444 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
445 \textit{scheduling} usato dal kernel, dalla particolare situazione in cui si
446 trova la macchina al momento della chiamata, risultando del tutto
447 impredicibile.  Eseguendo più volte il programma di prova e producendo un
448 numero diverso di figli, si sono ottenute situazioni completamente diverse,
449 compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
450 prima che uno dei figli venisse messo in esecuzione.
451
452 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
453 istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
454 essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
455 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
456 rischio di incorrere nelle cosiddette \textit{race condition} (vedi
457 sez.~\ref{sec:proc_race_cond}).
458
459 In realtà con l'introduzione dei kernel della serie 2.6 lo \textit{scheduler}
460 è stato modificato per eseguire sempre per primo il figlio.\footnote{i
461   risultati precedenti infatti sono stati ottenuti usando un kernel della
462   serie 2.4.}  Questa è una ottimizzazione adottata per evitare che il padre,
463 effettuando per primo una operazione di scrittura in memoria, attivasse il
464 meccanismo del \textit{copy on write}, operazione inutile quando il figlio
465 viene creato solo per eseguire una \func{exec} per lanciare un altro programma
466 che scarta completamente lo spazio degli indirizzi e rende superflua la copia
467 della memoria modificata dal padre. Eseguendo sempre per primo il figlio la
468 \func{exec} verrebbe effettuata subito, con la certezza di utilizzare il
469 \textit{copy on write} solo quando necessario.
470
471 Con il kernel 2.6.32 però il comportamento è stato nuovamente cambiato,
472 stavolta facendo eseguire per primo sempre il padre. Si è realizzato infatti
473 che l'eventualità prospettata per la scelta precedente era comunque poco
474 probabile, mentre l'esecuzione immediata del padre presenta sempre il
475 vantaggio di poter utilizzare immediatamente tutti i dati che sono nella cache
476 della CPU e nell'unità di gestione della memoria virtuale, senza doverli
477 invalidare, cosa che per i processori moderni, che hanno linee di cache
478 interne molto profonde, avrebbe un forte impatto sulle prestazioni.
479
480 Allora anche se quanto detto in precedenza si verifica nel comportamento
481 effettivo dei programmi soltanto per i kernel fino alla serie 2.4, per
482 mantenere la portabilità con altri kernel unix-like e con i diversi
483 comportamenti adottati dalle Linux nella sua evoluzione, è comunque opportuno
484 non fare nessuna assunzione sull'ordine di esecuzione di padre e figlio dopo
485 la chiamata a \func{fork}.
486
487 Si noti infine come dopo la \func{fork}, essendo i segmenti di memoria
488 utilizzati dai singoli processi completamente indipendenti, le modifiche delle
489 variabili nei processi figli, come l'incremento di \var{i} in (\texttt{\small
490   31}), sono visibili solo a loro, (ogni processo vede solo la propria copia
491 della memoria), e non hanno alcun effetto sul valore che le stesse variabili
492 hanno nel processo padre ed in eventuali altri processi figli che eseguano lo
493 stesso codice.
494
495 Un secondo aspetto molto importante nella creazione dei processi figli è
496 quello dell'interazione dei vari processi con i file. Ne parleremo qui anche
497 se buona parte dei concetti relativi ai file verranno trattati più avanti
498 (principalmente in sez.~\ref{sec:file_unix_interface}). Per illustrare meglio
499 quello che avviene si può redirigere su un file l'output del programma di
500 test, quello che otterremo è:
501 \begin{Console}
502 [piccardi@selidor sources]$ \textbf{./forktest 3 > output}
503 [piccardi@selidor sources]$ \textbf{cat output}
504 Process 1967: forking 3 child
505 Child 1 successfully executing
506 Child 1, parent 1967, exiting
507 Test for forking 3 child
508 Spawned 1 child, pid 1968 
509 Go to next child 
510 Child 2 successfully executing
511 Child 2, parent 1967, exiting
512 Test for forking 3 child
513 Spawned 1 child, pid 1968 
514 Go to next child 
515 Spawned 2 child, pid 1969 
516 Go to next child 
517 Child 3 successfully executing
518 Child 3, parent 1967, exiting
519 Test for forking 3 child
520 Spawned 1 child, pid 1968 
521 Go to next child 
522 Spawned 2 child, pid 1969 
523 Go to next child 
524 Spawned 3 child, pid 1970 
525 Go to next child 
526 \end{Console}
527 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
528
529 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
530 in gran dettaglio in sez.~\ref{sec:file_unix_interface} per l'interfaccia
531 nativa Unix ed in sez.~\ref{sec:files_std_interface} per la standardizzazione
532 adottata nelle librerie del linguaggio C, valida per qualunque sistema
533 operativo.
534
535 Qui basta accennare che si sono usate le funzioni standard della libreria del
536 C che prevedono l'output bufferizzato. Il punto è che questa bufferizzazione
537 (che tratteremo in dettaglio in sez.~\ref{sec:file_buffering}) varia a seconda
538 che si tratti di un file su disco, in cui il buffer viene scaricato su disco
539 solo quando necessario, o di un terminale, in cui il buffer viene scaricato ad
540 ogni carattere di ``a capo''.
541
542 Nel primo esempio allora avevamo che, essendovi un a capo nella stringa
543 stampata, ad ogni chiamata a \func{printf} il buffer veniva scaricato, per cui
544 le singole righe comparivano a video subito dopo l'esecuzione della
545 \func{printf}. Ma con la redirezione su file la scrittura non avviene più alla
546 fine di ogni riga e l'output resta nel buffer. 
547
548 Dato che ogni figlio riceve una copia della memoria del padre, esso riceverà
549 anche quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte
550 dal padre fino allora. Così quando il buffer viene scritto su disco all'uscita
551 del figlio, troveremo nel file anche tutto quello che il processo padre aveva
552 scritto prima della sua creazione. E alla fine del file (dato che in questo
553 caso il padre esce per ultimo) troveremo anche l'output completo del padre.
554
555 L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
556 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
557 solo processi diversi possono scrivere in contemporanea sullo stesso file
558 (l'argomento dell'accesso concorrente ai file è trattato in dettaglio in
559 sez.~\ref{sec:file_shared_access}), ma anche che, a differenza di quanto
560 avviene per le variabili in memoria, la posizione corrente sul file è
561 condivisa fra il padre e tutti i processi figli.
562
563 Quello che succede è che quando lo \textit{standard output}\footnote{si chiama
564   così il file su cui di default un programma scrive i suoi dati in uscita,
565   tratteremo l'argomento in dettaglio in sez.~\ref{sec:file_fd}.} del padre
566 viene rediretto come si è fatto nell'esempio, lo stesso avviene anche per
567 tutti i figli. La funzione \func{fork} infatti ha la caratteristica di
568 duplicare nei processi figli tutti i \textit{file descriptor} (vedi
569 sez.~\ref{sec:file_fd}) dei file aperti nel processo padre (allo stesso modo
570 in cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}). Ciò
571 fa si che padre e figli condividano le stesse voci della \textit{file table}
572 (tratteremo in dettaglio questi termini in sez.~\ref{sec:file_fd} e
573 sez.~\ref{sec:file_shared_access}) fra le quali c'è anche la posizione
574 corrente nel file.
575
576 Quando un processo scrive su un file la posizione corrente viene aggiornata
577 sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
578 \textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
579 casi come quello appena mostrato in cui diversi figli scrivono sullo stesso
580 file usato dal padre, che una scrittura eseguita in un secondo tempo da un
581 processo vada a sovrapporsi a quelle precedenti: l'output potrà risultare
582 mescolato, ma non ci saranno parti perdute per via di una sovrascrittura.
583
584 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
585 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
586 scrivono sullo stesso file. Un caso tipico di questo comportamento è la shell
587 quando lancia un programma.  In questo modo, anche se lo standard output viene
588 rediretto, il padre potrà sempre continuare a scrivere in coda a quanto
589 scritto dal figlio in maniera automatica; se così non fosse ottenere questo
590 comportamento sarebbe estremamente complesso, necessitando di una qualche
591 forma di comunicazione fra i due processi per far riprendere al padre la
592 scrittura al punto giusto.
593
594 In generale comunque non è buona norma far scrivere più processi sullo stesso
595 file senza una qualche forma di sincronizzazione in quanto, come visto anche
596 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
597 una sequenza impredicibile. Per questo le modalità con cui in genere si usano
598 i file dopo una \func{fork} sono sostanzialmente due:
599 \begin{enumerate*}
600 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
601   è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
602   della posizione corrente dopo eventuali operazioni di lettura e scrittura
603   effettuate dal figlio è automatica.
604 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
605   ciascuno dei due processi deve chiudere i file che non gli servono una volta
606   che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
607 \end{enumerate*}
608
609 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
610 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
611 comune dopo l'esecuzione di una \func{fork} è la seguente:
612 \begin{itemize*}
613 \item i file aperti e gli eventuali flag di \textit{close-on-exec} impostati
614   (vedi sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl_ioctl});
615 \item gli identificatori per il controllo di accesso: l'\textsl{user-ID
616     reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
617   \textsl{group-ID effettivo} ed i \textsl{group-ID supplementari} (vedi
618   sez.~\ref{sec:proc_access_id});
619 \item gli identificatori per il controllo di sessione: il \textit{process
620     group-ID} e il \textit{session id} ed il terminale di controllo (vedi
621   sez.~\ref{sec:sess_proc_group});
622 \item la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la
623   directory radice (vedi sez.~\ref{sec:file_chroot});
624 \item la maschera dei permessi di creazione dei file (vedi
625   sez.~\ref{sec:file_perm_management});
626 \item la maschera dei segnali bloccati (vedi
627   sez.~\ref{sec:sig_sigmask}) e le azioni installate (vedi
628   sez.~\ref{sec:sig_gen_beha});
629 \item i segmenti di memoria condivisa agganciati al processo (vedi
630   sez.~\ref{sec:ipc_sysv_shm});
631 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
632 \item il valori di \textit{nice}, le priorità \textit{real-time} e le affinità
633   di processore (vedi sez.~\ref{sec:proc_sched_stand},
634   sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
635 \item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
636 \item l'insieme dei descrittori associati alle code di messaggi POSIX (vedi
637   sez.~\ref{sec:ipc_posix_mq}) che vengono copiate come i \textit{file
638     descriptor}, questo significa che entrambi condivideranno gli stessi flag.
639 \end{itemize*}
640
641 Oltre a quelle relative ad un diverso spazio degli indirizzi (e una memoria
642 totalmente indipendente) le differenze fra padre e figlio dopo l'esecuzione di
643 una \func{fork} invece sono:\footnote{a parte le ultime quattro, relative a
644   funzionalità specifiche di Linux, le altre sono esplicitamente menzionate
645   dallo standard POSIX.1-2001.}
646 \begin{itemize*}
647 \item il valore di ritorno di \func{fork};
648 \item il \ids{PID} (\textit{process id}), quello del figlio viene assegnato ad
649   un nuovo valore univoco;
650 \item il \ids{PPID} (\textit{parent process id}), quello del figlio viene
651   impostato al \ids{PID} del padre;
652 \item i valori dei tempi di esecuzione (vedi sez.~\ref{sec:sys_cpu_times}) e
653   delle risorse usate (vedi sez.~\ref{sec:sys_resource_use}), che nel figlio
654   sono posti a zero;
655 \item i \textit{lock} sui file (vedi sez.~\ref{sec:file_locking}) e sulla
656   memoria (vedi sez.~\ref{sec:proc_mem_lock}), che non vengono ereditati dal
657   figlio;
658 \item gli allarmi, i timer (vedi sez.~\ref{sec:sig_alarm_abort}) ed i segnali
659   pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che per il figlio vengono
660   cancellati.
661 \item le operazioni di I/O asincrono in corso (vedi
662   sez.~\ref{sec:file_asyncronous_io}) che non vengono ereditate dal figlio;
663 \item gli aggiustamenti fatti dal padre ai semafori con \func{semop} (vedi
664   sez.~\ref{sec:ipc_sysv_sem}).
665 \item le notifiche sui cambiamenti delle directory con \textit{dnotify} (vedi
666   sez.~\ref{sec:sig_notification}), che non vengono ereditate dal figlio;
667 \item le mappature di memoria marcate come \const{MADV\_DONTFORK} (vedi
668   sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;
669 \item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:process_prctl}) che
670   notifica al figlio la terminazione del padre viene cancellata se presente
671   nel padre;
672 \item il segnale di terminazione del figlio è sempre \signal{SIGCHLD} anche
673   qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}). 
674 \end{itemize*}
675
676 Una seconda funzione storica usata per la creazione di un nuovo processo è
677 \funcm{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
678 semantica e gli stessi errori; la sola differenza è che non viene creata la
679 tabella delle pagine né la struttura dei task per il nuovo processo. Il
680 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
681 \func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
682 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
683 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
684
685 Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
686 \func{fork} comportava anche la copia completa del segmento dati del processo
687 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
688 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
689 venne introdotta in BSD per migliorare le prestazioni.
690
691 Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è
692 assolutamente trascurabile, e l'uso di questa funzione, che resta un caso
693 speciale della \textit{system call} \func{clone} (che tratteremo in dettaglio
694 in sez.~\ref{sec:process_clone}) è deprecato; per questo eviteremo di
695 trattarla ulteriormente.
696
697
698 \subsection{La conclusione di un processo}
699 \label{sec:proc_termination}
700
701 In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
702 chiudere un programma, ma dall'interno del programma stesso. Avendo a che fare
703 con un sistema \textit{multitasking} resta da affrontare l'argomento dal punto
704 di vista di come il sistema gestisce la conclusione dei processi.
705
706 Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
707 programma viene terminato in maniera normale: la chiamata di \func{exit}, che
708 esegue le funzioni registrate per l'uscita e chiude gli \textit{stream} e poi
709 esegue \func{\_exit}, il ritorno dalla funzione \code{main} equivalente alla
710 chiamata di \func{exit}, e la chiamata diretta a \func{\_exit}, che passa
711 direttamente alle operazioni di terminazione del processo da parte del kernel.
712
713 Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
714 modalità di conclusione anomala. Queste sono in sostanza due: il programma può
715 chiamare la funzione \func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}) per
716 invocare una chiusura anomala, o essere terminato da un segnale (torneremo sui
717 segnali in cap.~\ref{cha:signals}).  In realtà anche la prima modalità si
718 riconduce alla seconda, dato che \func{abort} si limita a generare il segnale
719 \signal{SIGABRT}.
720
721 Qualunque sia la modalità di conclusione di un processo, il kernel esegue
722 comunque una serie di operazioni di terminazione: chiude tutti i file aperti,
723 rilascia la memoria che stava usando, e così via; l'elenco completo delle
724 operazioni eseguite alla chiusura di un processo è il seguente:
725 \begin{itemize*}
726 \item tutti i \textit{file descriptor} (vedi sez.~\ref{sec:file_fd}) sono
727   chiusi;
728 \item viene memorizzato lo stato di terminazione del processo;
729 \item ad ogni processo figlio viene assegnato un nuovo padre (in genere
730   \cmd{init});
731 \item viene inviato il segnale \signal{SIGCHLD} al processo padre (vedi
732   sez.~\ref{sec:sig_sigchld});
733 \item se il processo è un leader di sessione ed il suo terminale di controllo
734   è quello della sessione viene mandato un segnale di \signal{SIGHUP} a tutti i
735   processi del gruppo di \textit{foreground} e il terminale di controllo viene
736   disconnesso (vedi sez.~\ref{sec:sess_ctrl_term});
737 \item se la conclusione di un processo rende orfano un \textit{process
738     group} ciascun membro del gruppo viene bloccato, e poi gli vengono
739   inviati in successione i segnali \signal{SIGHUP} e \signal{SIGCONT}
740   (vedi ancora sez.~\ref{sec:sess_ctrl_term}).
741 \end{itemize*}
742
743 \itindbeg{termination~status} 
744
745 Oltre queste operazioni è però necessario poter disporre di un meccanismo
746 ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
747 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
748 scelto consiste nel riportare lo \textsl{stato di terminazione} (il cosiddetto
749 \textit{termination status}) al processo padre.
750
751 Nel caso di conclusione normale, abbiamo visto in
752 sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
753 caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
754 valore passato come argomento alle funzioni \func{exit} o \func{\_exit} o il
755 valore di ritorno per \code{main}.  Ma se il processo viene concluso in
756 maniera anomala il programma non può specificare nessun \textit{exit status},
757 ed è il kernel che deve generare autonomamente il \textit{termination status}
758 per indicare le ragioni della conclusione anomala.
759
760 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
761 quello che contraddistingue lo stato di chiusura del processo e viene
762 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
763 sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione
764 normale il kernel usa il primo (nel codice eseguito da \func{\_exit}) per
765 produrre il secondo.
766
767 La scelta di riportare al padre lo stato di terminazione dei figli, pur
768 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
769 alla sua creazione è scontato che ogni nuovo processo abbia un padre, non è
770 detto che sia così alla sua conclusione, dato che il padre potrebbe essere già
771 terminato; si potrebbe avere cioè quello che si chiama un processo
772 \textsl{orfano}.
773
774 Questa complicazione viene superata facendo in modo che il processo orfano
775 venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \ids{PID}
776 1,\footnote{anche se, come vedremo in sez.~\ref{sec:process_prctl}, a partire
777   dal kernel 3.4 è diventato possibile delegare questo compito anche ad un
778   altro processo.} cioè quello lanciato direttamente dal kernel all'avvio, che
779 sta alla base dell'albero dei processi visto in sez.~\ref{sec:proc_hierarchy}
780 e che anche per questo motivo ha un ruolo essenziale nel sistema e non può mai
781 terminare.\footnote{almeno non senza un blocco completo del sistema, in caso
782   di terminazione o di non esecuzione di \cmd{init} infatti il kernel si
783   blocca con un cosiddetto \textit{kernel panic}, dato che questo è un errore
784   fatale.}
785
786 Come già accennato quando un processo termina, il kernel controlla se è il
787 padre di altri processi in esecuzione: in caso positivo allora il \ids{PPID}
788 di tutti questi processi verrà sostituito dal kernel con il \ids{PID} di
789 \cmd{init}, cioè con 1. In questo modo ogni processo avrà sempre un padre (nel
790 caso possiamo parlare di un padre \textsl{adottivo}) cui riportare il suo
791 stato di terminazione.  
792
793 Come verifica di questo comportamento possiamo eseguire il nostro programma
794 \cmd{forktest} imponendo a ciascun processo figlio due secondi di attesa prima
795 di uscire, il risultato è:
796 \begin{Console}
797 [piccardi@selidor sources]$ \textbf{./forktest -c2 3}
798 Process 1972: forking 3 child
799 Spawned 1 child, pid 1973 
800 Child 1 successfully executing
801 Go to next child 
802 Spawned 2 child, pid 1974 
803 Child 2 successfully executing
804 Go to next child 
805 Child 3 successfully executing
806 Spawned 3 child, pid 1975 
807 Go to next child 
808
809 [piccardi@selidor sources]$ Child 3, parent 1, exiting
810 Child 2, parent 1, exiting
811 Child 1, parent 1, exiting
812 \end{Console}
813 come si può notare in questo caso il processo padre si conclude prima dei
814 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
815 secondi dopo viene stampato a video anche l'output dei tre figli che
816 terminano, e come si può notare in questo caso, al contrario di quanto visto
817 in precedenza, essi riportano 1 come \ids{PPID}.
818
819 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
820 perché non è detto che il padre sia in esecuzione e possa ricevere
821 immediatamente lo stato di terminazione, quindi il kernel deve comunque
822 conservare una certa quantità di informazioni riguardo ai processi che sta
823 terminando.
824
825 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
826 memorizzando alcuni dati essenziali, come il \ids{PID}, i tempi di CPU usati
827 dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
828 mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. 
829
830 \itindbeg{zombie}
831
832 I processi che sono terminati, ma il cui stato di terminazione non è stato
833 ancora ricevuto dal padre sono chiamati \textit{zombie}, essi restano presenti
834 nella tabella dei processi ed in genere possono essere identificati
835 dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella colonna che ne
836 indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando il padre
837 effettuerà la lettura dello stato di terminazione anche questa informazione,
838 non più necessaria, verrà scartata ed il processo potrà considerarsi
839 completamente concluso.
840
841 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
842 condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi
843 sez.~\ref{sec:sess_job_control}), indicando al processo padre di aspettare 10
844 secondi prima di uscire. In questo caso, usando \cmd{ps} sullo stesso
845 terminale (prima dello scadere dei 10 secondi) otterremo:
846 \begin{Console}
847 [piccardi@selidor sources]$ \textbf{ps T}
848   PID TTY      STAT   TIME COMMAND
849   419 pts/0    S      0:00 bash
850   568 pts/0    S      0:00 ./forktest -e10 3
851   569 pts/0    Z      0:00 [forktest <defunct>]
852   570 pts/0    Z      0:00 [forktest <defunct>]
853   571 pts/0    Z      0:00 [forktest <defunct>]
854   572 pts/0    R      0:00 ps T
855 \end{Console}
856 %$
857 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
858 terminazione, i tre processi figli sono ancora presenti pur essendosi
859 conclusi, con lo stato di \textit{zombie} e l'indicazione che sono terminati
860 (la scritta \texttt{defunct}).
861
862 La possibilità di avere degli \textit{zombie} deve essere tenuta sempre
863 presente quando si scrive un programma che deve essere mantenuto in esecuzione
864 a lungo e creare molti processi figli. In questo caso si deve sempre avere
865 cura di far leggere al programma l'eventuale stato di uscita di tutti i
866 figli. Una modalità comune di farlo è attraverso l'utilizzo di un apposito
867 \textit{signal handler} che chiami la funzione \func{wait}, (vedi
868 sez.~\ref{sec:proc_wait}), ne esamineremo in dettaglio un esempio
869 (fig.~\ref{fig:sig_sigchld_handl}) in sez.~\ref{sec:sig_sigchld}.
870
871 La lettura degli stati di uscita è necessaria perché anche se gli
872 \textit{zombie} non consumano risorse di memoria o processore, occupano
873 comunque una voce nella tabella dei processi e se li si lasciano accumulare a
874 lungo quest'ultima potrebbe esaurirsi, con la conseguente impossibilità di
875 lanciare nuovi processi.
876
877 Si noti tuttavia che quando un processo adottato da \cmd{init} termina, non
878 diviene mai uno \textit{zombie}. Questo perché una delle funzioni di
879 \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i processi
880 a cui fa da padre, completandone la terminazione. Questo è quanto avviene
881 anche quando, come nel caso del precedente esempio con \cmd{forktest}, il
882 padre termina con dei figli in stato di \textit{zombie}. Questi scompaiono
883 quando, alla terminazione del padre dopo i secondi programmati, tutti figli
884 che avevamo generato, e che erano diventati \textit{zombie}, vengono adottati
885 da \cmd{init}, il quale provvede a completarne la terminazione.
886
887 Si tenga presente infine che siccome gli \textit{zombie} sono processi già
888 terminati, non c'è modo di eliminarli con il comando \cmd{kill} o inviandogli
889 un qualunque segnale di terminazione (l'argomento è trattato in
890 sez.~\ref{sec:sig_termination}). Qualora ci si trovi in questa situazione
891 l'unica possibilità di cancellarli dalla tabella dei processi è quella di
892 terminare il processo che li ha generati e che non sta facendo il suo lavoro,
893 in modo che \cmd{init} possa adottarli e concluderne correttamente la
894 terminazione.
895
896 Si tenga anche presente che la presenza di \textit{zombie} nella tabella dei
897 processi non è sempre indice di un qualche malfunzionamento, in una macchina
898 con molto carico infatti può esservi una presenza temporanea dovuta al fatto
899 che il processo padre ancora non ha avuto il tempo di gestirli. 
900
901 \itindend{zombie}
902
903
904 \subsection{Le funzioni di attesa e ricezione degli stati di uscita}
905 \label{sec:proc_wait}
906
907 Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
908 consiste nella creazione di programmi di tipo server, in cui un processo
909 principale attende le richieste che vengono poi soddisfatte da una serie di
910 processi figli. 
911
912 Si è già sottolineato al paragrafo precedente come in questo caso diventi
913 necessario gestire esplicitamente la conclusione dei figli onde evitare di
914 riempire di \textit{zombie} la tabella dei processi. Tratteremo in questa
915 sezione le funzioni di sistema deputate a questo compito; la prima è
916 \funcd{wait} ed il suo prototipo è:
917
918 \begin{funcproto}{ 
919 \fhead{sys/types.h}
920 \fhead{sys/wait.h}
921 \fdecl{pid\_t wait(int *status)}
922 \fdesc{Attende la terminazione di un processo.} 
923 }
924 {La funzione ritorna il \ids{PID} del figlio in caso di successo e $-1$ per un
925   errore, nel qual caso \var{errno} assumerà uno dei valori:
926   \begin{errlist}
927   \item[\errcode{ECHILD}] il processo non ha nessun figlio di cui attendere
928     uno stato di terminazione.
929   \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
930   \end{errlist}}
931 \end{funcproto}
932
933 Questa funzione è presente fin dalle prime versioni di Unix ed è quella usata
934 tradizionalmente per attendere la terminazione dei figli. La funzione sospende
935 l'esecuzione del processo corrente e ritorna non appena un qualunque processo
936 figlio termina. Se un figlio è già terminato prima della sua chiamata la
937 funzione ritorna immediatamente, se più processi figli sono già terminati
938 occorrerà continuare a chiamare la funzione più volte fintanto che non si è
939 recuperato lo stato di terminazione di tutti quanti.
940
941 Al ritorno della funzione lo stato di terminazione del figlio viene salvato
942 (come \textit{value result argument}) nella variabile puntata
943 da \param{status} e tutte le risorse del kernel relative al processo (vedi
944 sez.~\ref{sec:proc_termination}) vengono rilasciate.  Nel caso un processo
945 abbia più figli il valore di ritorno della funzione sarà impostato al
946 \ids{PID} del processo di cui si è ricevuto lo stato di terminazione, cosa che
947 permette di identificare qual è il figlio che è terminato.
948
949 \itindend{termination~status}
950
951 Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
952 all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
953 necessario attendere la conclusione di uno specifico processo fra tutti quelli
954 esistenti occorre predisporre un meccanismo che tenga conto di tutti processi
955 che sono terminati, e provveda a ripetere la chiamata alla funzione nel caso
956 il processo cercato non risulti fra questi. Se infatti il processo cercato è
957 già terminato e se è già ricevuto lo stato di uscita senza registrarlo, la
958 funzione non ha modo di accorgersene, e si continuerà a chiamarla senza
959 accorgersi che quanto interessava è già accaduto.
960
961 Per questo motivo lo standard POSIX.1 ha introdotto una seconda funzione che
962 effettua lo stesso servizio, ma dispone di una serie di funzionalità più
963 ampie, legate anche al controllo di sessione (si veda
964 sez.~\ref{sec:sess_job_control}).  Dato che è possibile ottenere lo stesso
965 comportamento di \func{wait}\footnote{in effetti il codice
966   \code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
967     \&status, 0)}.} si consiglia di utilizzare sempre questa nuova funzione di
968 sistema, \funcd{waitpid}, il cui prototipo è:
969
970 \begin{funcproto}{ 
971 \fhead{sys/types.h}
972 \fhead{sys/wait.h}
973 \fdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
974 \fdesc{Attende il cambiamento di stato di un processo figlio.} 
975 }
976 {La funzione ritorna il \ids{PID} del processo che ha cambiato stato in caso
977   di successo, o 0 se è stata specificata l'opzione \const{WNOHANG} e il
978   processo non è uscito e $-1$ per un errore, nel qual caso \var{errno}
979   assumerà uno dei valori:
980   \begin{errlist}
981   \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
982     non è figlio del processo chiamante.
983   \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
984     la funzione è stata interrotta da un segnale.
985   \item[\errcode{EINVAL}] si è specificato un valore non valido per
986     l'argomento \param{options}.
987   \end{errlist}}
988 \end{funcproto}
989
990 La prima differenza fra le due funzioni è che con \func{waitpid} si può
991 specificare in maniera flessibile quale processo attendere, sulla base del
992 valore fornito dall'argomento \param{pid}. Questo può assumere diversi valori,
993 secondo lo specchietto riportato in tab.~\ref{tab:proc_waidpid_pid}, dove si
994 sono riportate anche le costanti definite per indicare alcuni di essi.
995
996 \begin{table}[!htb]
997   \centering
998   \footnotesize
999   \begin{tabular}[c]{|c|c|p{8cm}|}
1000     \hline
1001     \textbf{Valore} & \textbf{Costante} &\textbf{Significato}\\
1002     \hline
1003     \hline
1004     $<-1$& --               & Attende per un figlio il cui \textit{process
1005                               group} (vedi sez.~\ref{sec:sess_proc_group}) è
1006                               uguale al valore assoluto di \param{pid}.\\ 
1007     $-1$&\constd{WAIT\_ANY}  & Attende per un figlio qualsiasi, usata in
1008                                questa maniera senza specificare nessuna opzione
1009                                è equivalente a \func{wait}.\\ 
1010     $ 0$&\constd{WAIT\_MYPGRP}&Attende per un figlio il cui \textit{process
1011                                group} (vedi sez.~\ref{sec:sess_proc_group}) è
1012                                 uguale a quello del processo chiamante.\\ 
1013     $>0$& --                & Attende per un figlio il cui \ids{PID} è uguale
1014                               al valore di \param{pid}.\\
1015     \hline
1016   \end{tabular}
1017   \caption{Significato dei valori dell'argomento \param{pid} della funzione
1018     \func{waitpid}.}
1019   \label{tab:proc_waidpid_pid}
1020 \end{table}
1021
1022 Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
1023 funzione delle opportune opzioni tramite l'argomento \param{options}; questo
1024 deve essere specificato come maschera binaria delle costanti riportati nella
1025 prima parte in tab.~\ref{tab:proc_waitpid_options} che possono essere
1026 combinate fra loro con un OR aritmetico. Nella seconda parte della stessa
1027 tabella si sono riportati anche alcune opzioni non standard specifiche di
1028 Linux, che consentono un controllo più dettagliato per i processi creati con
1029 la \textit{system call} generica \func{clone} (vedi
1030 sez.~\ref{sec:process_clone}) e che vengono usati principalmente per la
1031 gestione della terminazione dei \textit{thread}\unavref{ (vedi
1032 sez.~\ref{sec:thread_xxx})}.
1033
1034 \begin{table}[!htb]
1035   \centering
1036   \footnotesize
1037   \begin{tabular}[c]{|l|p{8cm}|}
1038     \hline
1039     \textbf{Costante} & \textbf{Descrizione}\\
1040     \hline
1041     \hline
1042     \const{WNOHANG}   & La funzione ritorna immediatamente anche se non è
1043                         terminato nessun processo figlio.\\
1044     \const{WUNTRACED} & Ritorna anche quando un processo figlio è stato
1045                         fermato.\\ 
1046     \const{WCONTINUED}& Ritorna anche quando un processo figlio che era stato
1047                         fermato ha ripreso l'esecuzione (dal kernel 2.6.10).\\
1048     \hline
1049     \constd{\_\_WCLONE}& Attende solo per i figli creati con \func{clone} 
1050                         (vedi sez.~\ref{sec:process_clone}), vale a dire
1051                         processi che non emettono nessun segnale 
1052                         o emettono un segnale diverso da \signal{SIGCHLD} alla
1053                         terminazione, il default è attendere soltanto i
1054                         processi figli ordinari ignorando quelli creati da
1055                         \func{clone}.\\
1056     \constd{\_\_WALL}  & Attende per qualunque figlio, sia ordinario che creato
1057                         con \func{clone}, se specificata con
1058                         \const{\_\_WCLONE} quest'ultima viene ignorata. \\
1059     \constd{\_\_WNOTHREAD}& Non attende per i figli di altri \textit{thread}
1060                         dello stesso \textit{thread group}, questo era il
1061                         comportamento di default del kernel 2.4 che non
1062                         supportava la possibilità, divenuta il default a
1063                         partire dal 2.6, di attendere un qualunque figlio
1064                         appartenente allo stesso \textit{thread group}. \\
1065     \hline
1066   \end{tabular}
1067   \caption{Costanti che identificano i bit dell'argomento \param{options}
1068     della funzione \func{waitpid}.} 
1069   \label{tab:proc_waitpid_options}
1070 \end{table}
1071
1072 \constbeg{WNOHANG}
1073
1074 L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della
1075 funzione qualora nessun figlio sia uscito o non si siano verificate le altre
1076 condizioni per l'uscita della funzione. in tal caso. In tal caso la funzione,
1077 invece di restituire il \ids{PID} del processo (che è sempre un intero
1078 positivo) ritornerà un valore nullo.
1079
1080 \constend{WNOHANG}
1081 \constbeg{WUNTRACED}
1082 \constbeg{WCONTINUED}
1083
1084 Le altre due opzioni, \const{WUNTRACED} e \const{WCONTINUED}, consentono
1085 rispettivamente di tracciare non la terminazione di un processo, ma il fatto
1086 che esso sia stato fermato, o fatto ripartire, e sono utilizzate per la
1087 gestione del controllo di sessione (vedi sez.~\ref{sec:sess_job_control}).
1088
1089 Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \ids{PID},
1090 quando un processo figlio entra nello stato \textit{stopped}\footnote{in
1091   realtà viene notificato soltanto il caso in cui il processo è stato fermato
1092   da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in
1093   cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace}\unavref{
1094     (vedi sez.~\ref{sec:process_ptrace})}.} (vedi
1095 tab.~\ref{tab:proc_proc_states}), mentre con \const{WCONTINUED} la funzione
1096 ritorna quando un processo in stato \textit{stopped} riprende l'esecuzione per
1097 la ricezione del segnale \signal{SIGCONT} (l'uso di questi segnali per il
1098 controllo di sessione è trattato in sez.~\ref{sec:sess_ctrl_term}).
1099
1100 \constend{WUNTRACED}
1101 \constend{WCONTINUED}
1102
1103 La terminazione di un processo figlio (così come gli altri eventi osservabili
1104 con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
1105 di un programma e può avvenire in un qualunque momento. Per questo motivo,
1106 come accennato nella sezione precedente, una delle azioni prese dal kernel
1107 alla conclusione di un processo è quella di mandare un segnale di
1108 \signal{SIGCHLD} al padre. L'azione predefinita per questo segnale (si veda
1109 sez.~\ref{sec:sig_base}) è di essere ignorato, ma la sua generazione
1110 costituisce il meccanismo di comunicazione asincrona con cui il kernel avverte
1111 il processo padre che uno dei suoi figli è terminato.
1112
1113 Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4
1114 al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello
1115 standard POSIX.1-2001 e come da esso richiesto se \signal{SIGCHLD} viene
1116 ignorato, o se si imposta il flag di \const{SA\_NOCLDSTOP} nella ricezione
1117 dello stesso (si veda sez.~\ref{sec:sig_sigaction}) i processi figli che
1118 terminano non diventano \textit{zombie} e sia \func{wait} che \func{waitpid}
1119 si bloccano fintanto che tutti i processi figli non sono terminati, dopo di
1120 che falliscono con un errore di \errcode{ENOCHLD}.\footnote{questo è anche il
1121   motivo per cui le opzioni \const{WUNTRACED} e \const{WCONTINUED} sono
1122   utilizzabili soltanto qualora non si sia impostato il flag di
1123   \const{SA\_NOCLDSTOP} per il segnale \signal{SIGCHLD}.}
1124
1125 Con i kernel della serie 2.4 e tutti i kernel delle serie precedenti entrambe
1126 le funzioni di attesa ignorano questa prescrizione e si comportano sempre
1127 nello stesso modo,\footnote{lo standard POSIX.1 originale infatti lascia
1128   indefinito il comportamento di queste funzioni quando \signal{SIGCHLD} viene
1129   ignorato.} indipendentemente dal fatto \signal{SIGCHLD} sia ignorato o meno:
1130 attendono la terminazione di un processo figlio e ritornano il relativo
1131 \ids{PID} e lo stato di terminazione nell'argomento \param{status}.
1132
1133 In generale in un programma non si vuole essere forzati ad attendere la
1134 conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
1135 questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente
1136 la presenza di \textit{zombie}).  Per questo la modalità più comune di
1137 chiamare queste funzioni è quella di utilizzarle all'interno di un
1138 \textit{signal handler} (vedremo un esempio di come gestire \signal{SIGCHLD}
1139 con i segnali in sez.~\ref{sec:sig_example}). In questo caso infatti, dato che
1140 il segnale è generato dalla terminazione di un figlio, avremo la certezza che
1141 la chiamata a \func{waitpid} non si bloccherà.
1142
1143 Come accennato sia \func{wait} che \func{waitpid} restituiscono lo stato di
1144 terminazione del processo tramite il puntatore \param{status}, e se non
1145 interessa memorizzarlo si può passare un puntatore nullo. Il valore restituito
1146 da entrambe le funzioni dipende dall'implementazione, ma tradizionalmente gli
1147 8 bit meno significativi sono riservati per memorizzare lo stato di uscita del
1148 processo, e gli altri per indicare il segnale che ha causato la terminazione
1149 (in caso di conclusione anomala), uno per indicare se è stato generato un
1150 \textit{core dump} (vedi sez.~\ref{sec:sig_standard}), ecc.\footnote{le
1151   definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
1152   questo file non deve mai essere usato direttamente, esso viene incluso
1153   attraverso \file{<sys/wait.h>}.}
1154
1155 \begin{table}[!htb]
1156   \centering
1157   \footnotesize
1158   \begin{tabular}[c]{|l|p{10cm}|}
1159     \hline
1160     \textbf{Macro} & \textbf{Descrizione}\\
1161     \hline
1162     \hline
1163     \macrod{WIFEXITED}\texttt{(s)}   & Condizione vera (valore non nullo) per
1164                                       un processo figlio che sia terminato
1165                                       normalmente. \\ 
1166     \macrod{WEXITSTATUS}\texttt{(s)} & Restituisce gli otto bit meno
1167                                       significativi dello stato di uscita del
1168                                       processo (passato attraverso
1169                                       \func{\_exit}, \func{exit} o come valore
1170                                       di ritorno di \code{main}); può essere
1171                                       valutata solo se \val{WIFEXITED} ha
1172                                       restituito un valore non nullo.\\ 
1173     \macrod{WIFSIGNALED}\texttt{(s)} & Condizione vera se il processo figlio è
1174                                       terminato in maniera anomala a causa di
1175                                       un segnale che non è stato catturato
1176                                       (vedi sez.~\ref{sec:sig_notification}).\\ 
1177     \macrod{WTERMSIG}\texttt{(s)}    & Restituisce il numero del segnale che ha
1178                                       causato la terminazione anomala del
1179                                       processo; può essere valutata solo se
1180                                       \val{WIFSIGNALED} ha restituito un
1181                                       valore non nullo.\\
1182     \macrod{WCOREDUMP}\texttt{(s)}   & Vera se il processo terminato ha
1183                                       generato un file di 
1184                                       \textit{core dump}; può essere valutata
1185                                       solo se \val{WIFSIGNALED} ha restituito
1186                                       un valore non nullo.\footnotemark \\
1187     \macrod{WIFSTOPPED}\texttt{(s)}  & Vera se il processo che ha causato il
1188                                       ritorno di \func{waitpid} è bloccato;
1189                                       l'uso è possibile solo con
1190                                       \func{waitpid} avendo specificato
1191                                       l'opzione \const{WUNTRACED}.\\
1192     \macrod{WSTOPSIG}\texttt{(s)}    & Restituisce il numero del segnale che ha
1193                                       bloccato il processo; può essere
1194                                       valutata solo se \val{WIFSTOPPED} ha
1195                                       restituito un valore non nullo. \\ 
1196     \macrod{WIFCONTINUED}\texttt{(s)}& Vera se il processo che ha causato il
1197                                       ritorno è stato riavviato da un
1198                                       \signal{SIGCONT} (disponibile solo a
1199                                       partire dal kernel 2.6.10).\\
1200     \hline
1201   \end{tabular}
1202   \caption{Descrizione delle varie macro di preprocessore utilizzabili per 
1203     verificare lo stato di terminazione \var{s} di un processo.}
1204   \label{tab:proc_status_macro}
1205 \end{table}
1206
1207 \footnotetext{questa macro non è definita dallo standard POSIX.1-2001, ma è
1208   presente come estensione sia in Linux che in altri Unix, deve essere
1209   pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un
1210   blocco \texttt{\#ifdef WCOREDUMP ... \#endif}.}
1211
1212 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
1213 analizzare lo stato di uscita. Esse sono definite sempre in
1214 \file{<sys/wait.h>} ed elencate in tab.~\ref{tab:proc_status_macro}. Si tenga
1215 presente che queste macro prevedono che gli si passi come parametro la
1216 variabile di tipo \ctyp{int} puntata dall'argomento \param{status} restituito
1217 da \func{wait} o \func{waitpid}.
1218
1219 Si tenga conto che nel caso di conclusione anomala il valore restituito da
1220 \val{WTERMSIG} può essere confrontato con le costanti che identificano i
1221 segnali definite in \headfile{signal.h} ed elencate in
1222 tab.~\ref{tab:sig_signal_list}, e stampato usando le apposite funzioni
1223 trattate in sez.~\ref{sec:sig_strsignal}.
1224
1225 A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è
1226 stata introdotta una nuova funzione di attesa che consente di avere un
1227 controllo molto più preciso sui possibili cambiamenti di stato dei processi
1228 figli e più dettagli sullo stato di uscita; la funzione di sistema è
1229 \funcd{waitid} ed il suo prototipo è:
1230
1231 \begin{funcproto}{ 
1232 \fhead{sys/types.h}
1233 \fhead{sys/wait.h}
1234 \fdecl{int waitid(idtype\_t idtype, id\_t id, siginfo\_t *infop, int options)}
1235 \fdesc{Attende il cambiamento di stato di un processo figlio.} 
1236 }
1237 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1238   caso \var{errno} assumerà uno dei valori:
1239   \begin{errlist}
1240   \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
1241     non è figlio del processo chiamante.
1242   \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
1243     la funzione è stata interrotta da un segnale.
1244   \item[\errcode{EINVAL}] si è specificato un valore non valido per
1245     l'argomento \param{options}.
1246   \end{errlist}}
1247 \end{funcproto}
1248
1249 La funzione prevede che si specifichi quali processi si intendono osservare
1250 usando i due argomenti \param{idtype} ed \param{id}; il primo indica se ci si
1251 vuole porre in attesa su un singolo processo, un gruppo di processi o un
1252 processo qualsiasi, e deve essere specificato secondo uno dei valori di
1253 tab.~\ref{tab:proc_waitid_idtype}; il secondo indica, a seconda del valore del
1254 primo, quale processo o quale gruppo di processi selezionare.
1255
1256 \begin{table}[!htb]
1257   \centering
1258   \footnotesize
1259   \begin{tabular}[c]{|l|p{8cm}|}
1260     \hline
1261     \textbf{Valore} & \textbf{Descrizione}\\
1262     \hline
1263     \hline
1264     \constd{P\_PID} & Indica la richiesta di attendere per un processo figlio
1265                       il cui \ids{PID} corrisponda al valore dell'argomento
1266                       \param{id}.\\
1267     \constd{P\_PGID}& Indica la richiesta di attendere per un processo figlio
1268                       appartenente al \textit{process group} (vedi
1269                       sez.~\ref{sec:sess_proc_group}) il cui \acr{pgid}
1270                       corrisponda al valore dell'argomento \param{id}.\\
1271     \constd{P\_ALL} & Indica la richiesta di attendere per un processo figlio
1272                       generico, il valore dell'argomento \param{id} viene
1273                       ignorato.\\
1274     \hline
1275   \end{tabular}
1276   \caption{Costanti per i valori dell'argomento \param{idtype} della funzione
1277     \func{waitid}.}
1278   \label{tab:proc_waitid_idtype}
1279 \end{table}
1280
1281 Come per \func{waitpid} anche il comportamento di \func{waitid} è
1282 controllato dall'argomento \param{options}, da specificare come maschera
1283 binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
1284 alcuni di questi siano identici come significato ed effetto ai precedenti di
1285 tab.~\ref{tab:proc_waitpid_options}, ci sono delle differenze significative:
1286 in questo caso si dovrà specificare esplicitamente l'attesa della terminazione
1287 di un processo impostando l'opzione \const{WEXITED}, mentre il precedente
1288 \const{WUNTRACED} è sostituito da \const{WSTOPPED}.  Infine è stata aggiunta
1289 l'opzione \const{WNOWAIT} che consente una lettura dello stato mantenendo il
1290 processo in attesa di ricezione, così che una successiva chiamata possa di
1291 nuovo riceverne lo stato.
1292
1293 \begin{table}[!htb]
1294   \centering
1295   \footnotesize
1296   \begin{tabular}[c]{|l|p{8cm}|}
1297     \hline
1298     \textbf{Valore} & \textbf{Descrizione}\\
1299     \hline
1300     \hline
1301     \constd{WEXITED}   & Ritorna quando un processo figlio è terminato.\\
1302     \constd{WNOHANG}   & Ritorna immediatamente anche se non c'è niente da
1303                          notificare.\\ 
1304     \constd{WSTOPPED}  & Ritorna quando un processo figlio è stato fermato.\\
1305     \const{WCONTINUED} & Ritorna quando un processo figlio che era stato
1306                          fermato ha ripreso l'esecuzione.\\
1307     \constd{WNOWAIT}   & Lascia il processo ancora in attesa di ricezione, così
1308                          che una successiva chiamata possa di nuovo riceverne
1309                          lo stato.\\
1310     \hline
1311   \end{tabular}
1312   \caption{Costanti che identificano i bit dell'argomento \param{options}
1313     della funzione \func{waitid}.} 
1314   \label{tab:proc_waitid_options}
1315 \end{table}
1316
1317 La funzione \func{waitid} restituisce un valore nullo in caso di successo, e
1318 $-1$ in caso di errore; viene restituito un valore nullo anche se è stata
1319 specificata l'opzione \const{WNOHANG} e la funzione è ritornata immediatamente
1320 senza che nessun figlio sia terminato. Pertanto per verificare il motivo del
1321 ritorno della funzione occorre analizzare le informazioni che essa
1322 restituisce; queste, al contrario delle precedenti \func{wait} e
1323 \func{waitpid} che usavano un semplice valore numerico, sono ritornate in una
1324 struttura di tipo \struct{siginfo\_t} (vedi fig.~\ref{fig:sig_siginfo_t})
1325 all'indirizzo puntato dall'argomento \param{infop}.
1326
1327 Tratteremo nei dettagli la struttura \struct{siginfo\_t} ed il significato dei
1328 suoi vari campi in sez.~\ref{sec:sig_sigaction}, per quanto ci interessa qui
1329 basta dire che al ritorno di \func{waitid} verranno avvalorati i seguenti
1330 campi:
1331 \begin{basedescript}{\desclabelwidth{1.8cm}}
1332 \item[\var{si\_pid}] con il \ids{PID} del figlio.
1333 \item[\var{si\_uid}] con l'\textsl{user-ID reale} (vedi
1334   sez.~\ref{sec:proc_perms}) del figlio.
1335 \item[\var{si\_signo}] con \signal{SIGCHLD}.
1336 \item[\var{si\_status}] con lo stato di uscita del figlio o con il segnale che
1337   lo ha terminato, fermato o riavviato.
1338 \item[\var{si\_code}] con uno fra \const{CLD\_EXITED}, \const{CLD\_KILLED},
1339   \const{CLD\_STOPPED}, \const{CLD\_CONTINUED}, \const{CLD\_TRAPPED} e
1340   \const{CLD\_DUMPED} a indicare la ragione del ritorno della funzione, il cui
1341   significato è, nell'ordine: uscita normale, terminazione da segnale,
1342   processo fermato, processo riavviato, processo terminato in
1343   \textit{core dump} (vedi sez.~\ref{sec:sig_standard}).
1344 \end{basedescript}
1345
1346 Infine Linux, seguendo un'estensione di BSD, supporta altre due funzioni per
1347 la lettura dello stato di terminazione di un processo, analoghe alle
1348 precedenti ma che prevedono un ulteriore argomento attraverso il quale il
1349 kernel può restituire al padre informazioni sulle risorse (vedi
1350 sez.~\ref{sec:sys_res_limits}) usate dal processo terminato e dai vari figli.
1351 Le due funzioni di sistema sono \funcd{wait3} e \funcd{wait4}, che diventano
1352 accessibili definendo la macro \macro{\_USE\_BSD}, i loro prototipi sono:
1353
1354 \begin{funcproto}{ 
1355 \fhead{sys/types.h}
1356 \fhead{sys/times.h}
1357 \fhead{sys/resource.h}
1358 \fhead{sys/wait.h}
1359 \fdecl{int wait3(int *status, int options, struct rusage *rusage)}
1360 \fdecl{int wait4(pid\_t pid, int *status, int options, struct rusage *rusage)}
1361 \fdesc{Attende il cambiamento di stato di un processo figlio, riportando l'uso
1362   delle risorse.} 
1363 }
1364 {La funzione ha gli stessi valori di ritorno e codici di errore di
1365   \func{waitpid}. }
1366 \end{funcproto}
1367
1368 La funzione \func{wait4} è identica \func{waitpid} sia nel comportamento che
1369 per i valori dei primi tre argomenti, ma in più restituisce nell'argomento
1370 aggiuntivo \param{rusage} un sommario delle risorse usate dal processo. Questo
1371 argomento è una struttura di tipo \struct{rusage} definita in
1372 \headfile{sys/resource.h}, che viene utilizzata anche dalla funzione
1373 \func{getrusage} per ottenere le risorse di sistema usate da un processo. La
1374 sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct} e ne
1375 tratteremo in dettaglio il significato sez.~\ref{sec:sys_resource_use}. La
1376 funzione \func{wait3} è semplicemente un caso particolare di (e con Linux
1377 viene realizzata con la stessa \textit{system call}), ed è equivalente a
1378 chiamare \code{wait4(-1, \&status, opt, rusage)}, per questo motivo è ormai
1379 deprecata in favore di \func{wait4}.
1380
1381
1382
1383 \subsection{La famiglia delle funzioni \func{exec} per l'esecuzione dei
1384   programmi}
1385 \label{sec:proc_exec}
1386
1387 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1388 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1389 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1390 processo chiama una di queste funzioni esso viene completamente sostituito dal
1391 nuovo programma, il \ids{PID} del processo non cambia, dato che non viene
1392 creato un nuovo processo, la funzione semplicemente rimpiazza lo
1393 \textit{stack}, i dati ed il testo del processo corrente con un nuovo
1394 programma letto da disco, eseguendo il \textit{link-loader} con gli effetti
1395 illustrati in sez.~\ref{sec:proc_main}.
1396
1397 \begin{figure}[!htb]
1398   \centering \includegraphics[width=8cm]{img/exec_rel}
1399   \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
1400   \label{fig:proc_exec_relat}
1401 \end{figure}
1402
1403 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1404 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1405 (come mostrato in fig.~\ref{fig:proc_exec_relat}), tutte queste funzioni sono
1406 tutte varianti che consentono di invocare in modi diversi, semplificando il
1407 passaggio degli argomenti, la funzione di sistema \funcd{execve}, il cui
1408 prototipo è:
1409
1410 \begin{funcproto}{
1411 \fhead{unistd.h}
1412 \fdecl{int execve(const char *filename, char *const argv[], char *const envp[])}
1413 \fdesc{Esegue un programma.} 
1414 }
1415 {La funzione ritorna solo in caso di errore, restituendo $-1$, nel qual
1416  caso \var{errno} assumerà uno dei valori:
1417 \begin{errlist}
1418   \item[\errcode{EACCES}] il file o l'interprete non file ordinari, o non sono
1419     eseguibili, o il file è su un filesystem montato con l'opzione
1420     \cmd{noexec}, o manca  il permesso di attraversamento di una delle
1421     directory del \textit{pathname}.
1422   \item[\errcode{EAGAIN}] dopo un cambio di \ids{UID} si è ancora  sopra il
1423     numero massimo di processi consentiti per l'utente (dal kernel 3.1, per i
1424     dettagli vedi sez.~\ref{sec:proc_setuid}).
1425   \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
1426     \const{PT\_INTERP}, cioè chiede di essere eseguito da più di un
1427     interprete.
1428   \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
1429     riconoscibile.
1430   \item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1431     necessari per eseguirlo non esistono.
1432   \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
1433     riconosciuto come tale, o compilato per un'altra architettura.
1434   \item[\errcode{EPERM}] il file ha i bit \acr{suid} o \acr{sgid} e l'utente
1435     non è root, ed il processo viene tracciato, oppure il filesystem è montato
1436     con l'opzione \cmd{nosuid}. 
1437   \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
1438     processi. 
1439   \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
1440   \end{errlist}
1441   ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{EISDIR}, \errval{ELOOP},
1442   \errval{EMFILE}, \errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOMEM},
1443   \errval{ENOTDIR} nel loro significato generico.  }
1444 \end{funcproto}
1445
1446 La funzione \func{execve} esegue il programma o lo script indicato dal
1447 \textit{pathname} \param{filename}, passandogli la lista di argomenti indicata
1448 da \param{argv} e come ambiente la lista di stringhe indicata
1449 da \param{envp}. Entrambe le liste devono essere terminate da un puntatore
1450 nullo. I vettori degli argomenti e dell'ambiente possono essere acceduti dal
1451 nuovo programma quando la sua funzione \code{main} è dichiarata nella forma
1452 \code{main(int argc, char *argv[], char *envp[])}. Si tenga presente per il
1453 passaggio degli argomenti e dell'ambiente esistono comunque dei limiti, su cui
1454 torneremo in sez.~\ref{sec:sys_res_limits}).
1455 % TODO aggiungere la parte sul numero massimo di argomenti, da man execve
1456
1457 In caso di successo la funzione non ritorna, in quanto al posto del programma
1458 chiamante viene eseguito il nuovo programma indicato da \param{filename}. Se
1459 il processo corrente è tracciato con \func{ptrace}\unavref{ (vedi
1460 sez.~\ref{sec:process_ptrace})} in caso di successo viene emesso il segnale
1461 \signal{SIGTRAP}.
1462
1463 Le altre funzioni della famiglia (\funcd{execl}, \funcd{execv},
1464 \funcd{execle}, \funcd{execlp}, \funcd{execvp}) servono per fornire all'utente
1465 una serie di possibili diverse interfacce nelle modalità di passaggio degli
1466 argomenti all'esecuzione del nuovo programma. I loro prototipi sono:
1467
1468 \begin{funcproto}{ 
1469 \fhead{unistd.h}
1470 \fdecl{int execl(const char *path, const char *arg, ...)}
1471 \fdecl{int execv(const char *path, char *const argv[])}
1472 \fdecl{int execle(const char *path, const char *arg, ..., char * const envp[])}
1473 \fdecl{int execlp(const char *file, const char *arg, ...)}
1474 \fdecl{int execvp(const char *file, char *const argv[])}
1475 \fdesc{Eseguono un programma.} 
1476 }
1477 {Le funzioni ritornano solo in caso di errore, restituendo $-1$, i codici di
1478   errore sono gli stessi di \func{execve}.
1479 }
1480 \end{funcproto}
1481
1482 Tutte le funzioni mettono in esecuzione nel processo corrente il programma
1483 indicati nel primo argomento. Gli argomenti successivi consentono di
1484 specificare gli argomenti e l'ambiente che saranno ricevuti dal nuovo
1485 processo. Per capire meglio le differenze fra le funzioni della famiglia si può
1486 fare riferimento allo specchietto riportato in
1487 tab.~\ref{tab:proc_exec_scheme}. La relazione fra le funzioni è invece
1488 illustrata in fig.~\ref{fig:proc_exec_relat}.
1489
1490 \begin{table}[!htb]
1491   \footnotesize
1492   \centering
1493   \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1494     \hline
1495     \multicolumn{1}{|c|}{\textbf{Caratteristiche}} & 
1496     \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1497     \hline
1498     &\func{execl}\texttt{ }&\func{execlp}&\func{execle}
1499     &\func{execv}\texttt{ }& \func{execvp}& \func{execve} \\
1500     \hline
1501     \hline
1502     argomenti a lista    &$\bullet$&$\bullet$&$\bullet$&&& \\
1503     argomenti a vettore  &&&&$\bullet$&$\bullet$&$\bullet$\\
1504     \hline
1505     filename completo     &$\bullet$&&$\bullet$&$\bullet$&&$\bullet$\\ 
1506     ricerca su \var{PATH} &&$\bullet$&&&$\bullet$& \\
1507     \hline
1508     ambiente a vettore   &&&$\bullet$&&&$\bullet$ \\
1509     uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1510     \hline
1511   \end{tabular}
1512   \caption{Confronto delle caratteristiche delle varie funzioni della 
1513     famiglia \func{exec}.}
1514   \label{tab:proc_exec_scheme}
1515 \end{table}
1516
1517 La prima differenza fra le funzioni riguarda le modalità di passaggio dei
1518 valori che poi andranno a costituire gli argomenti a linea di comando (cioè i
1519 valori di \param{argv} e \param{argc} visti dalla funzione \code{main} del
1520 programma chiamato). Queste modalità sono due e sono riassunte dagli mnemonici
1521 ``\texttt{v}'' e ``\texttt{l}'' che stanno rispettivamente per \textit{vector}
1522 e \textit{list}.
1523
1524 Nel primo caso gli argomenti sono passati tramite il vettore di puntatori
1525 \var{argv[]} a stringhe terminate con zero che costituiranno gli argomenti a
1526 riga di comando, questo vettore \emph{deve} essere terminato da un puntatore
1527 nullo. Nel secondo caso le stringhe degli argomenti sono passate alla funzione
1528 come lista di puntatori, nella forma:
1529 \includecodesnip{listati/char_list.c}
1530 che deve essere terminata da un puntatore nullo.  In entrambi i casi vale la
1531 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1532 per indicare il nome del file che contiene il programma che verrà eseguito.
1533
1534 La seconda differenza fra le funzioni riguarda le modalità con cui si
1535 specifica il programma che si vuole eseguire. Con lo mnemonico ``\texttt{p}''
1536 si indicano le due funzioni che replicano il comportamento della shell nello
1537 specificare il comando da eseguire; quando l'argomento \param{file} non
1538 contiene una ``\texttt{/}'' esso viene considerato come un nome di programma,
1539 e viene eseguita automaticamente una ricerca fra i file presenti nella lista
1540 di directory specificate dalla variabile di ambiente \envvar{PATH}. Il file
1541 che viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
1542 relativo a permessi di accesso insufficienti (cioè l'esecuzione della
1543 sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
1544 proseguita nelle eventuali ulteriori directory indicate in \envvar{PATH}; solo
1545 se non viene trovato nessun altro file viene finalmente restituito
1546 \errcode{EACCES}.  Le altre quattro funzioni si limitano invece a cercare di
1547 eseguire il file indicato dall'argomento \param{path}, che viene interpretato
1548 come il \textit{pathname} del programma.
1549
1550 La terza differenza è come viene passata la lista delle variabili di ambiente.
1551 Con lo mnemonico ``\texttt{e}'' vengono indicate quelle funzioni che
1552 necessitano di un vettore di parametri \var{envp[]} analogo a quello usato per
1553 gli argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre
1554 usano il valore della variabile \var{environ} (vedi
1555 sez.~\ref{sec:proc_environ}) del processo di partenza per costruire
1556 l'ambiente.
1557
1558 Oltre a mantenere lo stesso \ids{PID}, il nuovo programma fatto partire da una
1559 delle funzioni della famiglia \func{exec} mantiene la gran parte delle
1560 proprietà del processo chiamante; una lista delle più significative è la
1561 seguente:
1562 \begin{itemize*}
1563 \item il \textit{process id} (\ids{PID}) ed il \textit{parent process id}
1564   (\ids{PPID});
1565 \item l'\textsl{user-ID reale}, il \textsl{group-ID reale} ed i
1566   \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
1567 \item la directory radice (vedi sez.~\ref{sec:file_chroot}) e la directory di
1568   lavoro corrente (vedi sez.~\ref{sec:file_work_dir});
1569 \item la maschera di creazione dei file (\textit{umask}, vedi
1570   sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
1571   sez.~\ref{sec:file_locking});
1572 \item il valori di \textit{nice}, le priorità real-time e le affinità di
1573   processore (vedi sez.~\ref{sec:proc_sched_stand};
1574   sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
1575 \item il \textit{session ID} (\acr{sid}) ed il \textit{process group ID}
1576   (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group};
1577 \item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term});
1578 \item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
1579 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
1580 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime};
1581   \var{tms\_cutime}, \var{tms\_ustime} (vedi sez.~\ref{sec:sys_cpu_times});
1582 \item la maschera dei segnali (si veda sez.~\ref{sec:sig_sigmask});
1583 \item l'insieme dei segnali pendenti (vedi sez.~\ref{sec:sig_gen_beha}).
1584 \end{itemize*}
1585
1586 Una serie di proprietà del processo originale, che non avrebbe senso mantenere
1587 in un programma che esegue un codice completamente diverso in uno spazio di
1588 indirizzi totalmente indipendente e ricreato da zero, vengono perse con
1589 l'esecuzione di una \func{exec}. Lo standard POSIX.1-2001 prevede che le
1590 seguenti proprietà non vengano preservate:
1591 \begin{itemize*}
1592 \item gli eventuali stack alternativi per i segnali (vedi
1593   sez.~\ref{sec:sig_specific_features});
1594 \item i \textit{directory stream} (vedi sez.~\ref{sec:file_dir_read}), che
1595   vengono chiusi;
1596 \item le mappature dei file in memoria (vedi sez.~\ref{sec:file_memory_map});
1597 \item i segmenti di memoria condivisa SysV (vedi sez.~\ref{sec:ipc_sysv_shm})
1598   e POSIX (vedi sez.~\ref{sec:ipc_posix_shm});
1599 \item i \textit{memory lock} (vedi sez.~\ref{sec:proc_mem_lock});
1600 \item le funzioni registrate all'uscita (vedi sez.~\ref{sec:proc_atexit});
1601 \item i semafori e le code di messaggi POSIX (vedi
1602   sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq});
1603 \item i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}).
1604 \end{itemize*}
1605
1606 Inoltre i segnali che sono stati impostati per essere ignorati nel processo
1607 chiamante mantengono la stessa impostazione pure nel nuovo programma, ma tutti
1608 gli altri segnali, ed in particolare quelli per i quali è stato installato un
1609 gestore vengono impostati alla loro azione predefinita (vedi
1610 sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \signal{SIGCHLD}
1611 che, quando impostato a \const{SIG\_IGN}, potrebbe anche essere reimpostato a
1612 \const{SIG\_DFL}. Lo standard POSIX.1-2001 prevede che questo comportamento
1613 sia deciso dalla singola implementazione, quella di Linux è di non modificare
1614 l'impostazione precedente.
1615
1616 Oltre alle precedenti, che sono completamente generali e disponibili anche su
1617 altri sistemi unix-like, esistono altre proprietà dei processi, attinenti alle
1618 caratteristiche specifiche di Linux, che non vengono preservate
1619 nell'esecuzione della funzione \func{exec}, queste sono:
1620 \begin{itemize*}
1621 \item le operazioni di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io})
1622   pendenti vengono cancellate;
1623 \item le \textit{capabilities} vengono modificate come
1624   illustrato in sez.~\ref{sec:proc_capabilities};
1625 \item tutti i \textit{thread} tranne il chiamante\unavref{ (vedi
1626     sez.~\ref{sec:thread_xxx})} vengono cancellati e tutti gli oggetti ad essi
1627   relativi\unavref{ (vedi sez.~\ref{sec:thread_xxx})} sono rimossi;
1628 \item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi
1629   sez.~\ref{sec:process_prctl}) a meno che il programma da eseguire non sia
1630   \acr{suid} o \acr{sgid} (vedi sez.~\ref{sec:proc_access_id} e
1631   sez.~\ref{sec:file_special_perm});
1632 \item il flag \const{PR\_SET\_KEEPCAPS} di \func{prctl} (vedi
1633   sez.~\ref{sec:process_prctl}) viene cancellato;
1634 \item il nome del processo viene impostato al nome del file contenente il
1635   programma messo in esecuzione;
1636 \item il segnale di terminazione viene reimpostato a \signal{SIGCHLD};
1637 \item l'ambiente viene reinizializzato impostando le variabili attinenti alla
1638   localizzazione al valore di default POSIX. 
1639 \end{itemize*}
1640
1641 \itindbeg{close-on-exec}
1642
1643 La gestione dei file aperti nel passaggio al nuovo programma lanciato con
1644 \func{exec} dipende dal valore che ha il flag di \textit{close-on-exec} (vedi
1645 sez.~\ref{sec:file_fcntl_ioctl}) per ciascun \textit{file descriptor}. I file
1646 per cui è impostato vengono chiusi, tutti gli altri file restano
1647 aperti. Questo significa che il comportamento predefinito è che i file restano
1648 aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
1649 \func{fcntl} che imposti il suddetto flag.  Per le directory, lo standard
1650 POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec}, in genere
1651 questo è fatto dalla funzione \func{opendir} (vedi
1652 sez.~\ref{sec:file_dir_read}) che effettua da sola l'impostazione del flag di
1653 \textit{close-on-exec} sulle directory che apre, in maniera trasparente
1654 all'utente.
1655
1656 \itindend{close-on-exec}
1657
1658 Il comportamento della funzione in relazione agli identificatori relativi al
1659 controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms},
1660 qui è sufficiente anticipare (si faccia riferimento a
1661 sez.~\ref{sec:proc_access_id} per la definizione di questi identificatori)
1662 come l'\textsl{user-ID reale} ed il \textsl{group-ID reale} restano sempre gli
1663 stessi, mentre l'\textsl{user-ID salvato} ed il \textsl{group-ID salvato}
1664 vengono impostati rispettivamente all'\textsl{user-ID effettivo} ed il
1665 \textsl{group-ID effettivo}. Questi ultimi normalmente non vengono modificati,
1666 a meno che il file di cui viene chiesta l'esecuzione non abbia o il \acr{suid}
1667 bit o lo \acr{sgid} bit impostato (vedi sez.~\ref{sec:file_special_perm}), in
1668 questo caso l'\textsl{user-ID effettivo} ed il \textsl{group-ID effettivo}
1669 vengono impostati rispettivamente all'utente o al gruppo cui il file
1670 appartiene.
1671
1672 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1673 condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
1674 del programma per caricare le librerie necessarie ed effettuare il link
1675 dell'eseguibile; il formato è ormai in completo disuso, per cui è molto
1676 probabile che non il relativo supporto non sia disponibile. Se il programma è
1677 in formato ELF per caricare le librerie dinamiche viene usato l'interprete
1678 indicato nel segmento \constd{PT\_INTERP} previsto dal formato stesso, in
1679 genere questo è \sysfiled{/lib/ld-linux.so.1} per programmi collegati con la
1680 \acr{libc5}, e \sysfiled{/lib/ld-linux.so.2} per programmi collegati con la
1681 \acr{glibc}.
1682
1683 Infine nel caso il programma che si vuole eseguire sia uno script e non un
1684 binario, questo deve essere un file di testo che deve iniziare con una linea
1685 nella forma:
1686 \begin{Example}
1687 #!/path/to/interpreter [argomenti]
1688 \end{Example}
1689 dove l'interprete indicato deve essere un eseguibile binario e non un altro
1690 script, che verrà chiamato come se si fosse eseguito il comando
1691 \cmd{interpreter [argomenti] filename}. 
1692
1693 Si tenga presente che con Linux quanto viene scritto come \texttt{argomenti}
1694 viene passato all'interprete come un unico argomento con una unica stringa di
1695 lunghezza massima di 127 caratteri e se questa dimensione viene ecceduta la
1696 stringa viene troncata; altri Unix hanno dimensioni massime diverse, e diversi
1697 comportamenti, ad esempio FreeBSD esegue la scansione della riga e la divide
1698 nei vari argomenti e se è troppo lunga restituisce un errore di
1699 \errval{ENAMETOOLONG}; una comparazione dei vari comportamenti sui diversi
1700 sistemi unix-like si trova su
1701 \url{http://www.in-ulm.de/~mascheck/various/shebang/}.
1702
1703 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1704 basata la gestione tradizionale dei processi in Unix: con \func{fork} si crea
1705 un nuovo processo, con \func{exec} si lancia un nuovo programma, con
1706 \func{exit} e \func{wait} si effettua e verifica la conclusione dei
1707 processi. Tutte le altre funzioni sono ausiliarie e servono per la lettura e
1708 l'impostazione dei vari parametri connessi ai processi.
1709
1710
1711
1712 \section{Il controllo di accesso}
1713 \label{sec:proc_perms}
1714
1715 In questa sezione esamineremo le problematiche relative al controllo di
1716 accesso dal punto di vista dei processi; vedremo quali sono gli identificatori
1717 usati, come questi possono essere modificati nella creazione e nel lancio di
1718 nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
1719 problematiche connesse ad una gestione accorta dei privilegi.
1720
1721
1722 \subsection{Gli identificatori del controllo di accesso}
1723 \label{sec:proc_access_id}
1724
1725 Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in
1726   realtà già esistono estensioni di questo modello base, che lo rendono più
1727   flessibile e controllabile, come le \textit{capabilities} illustrate in
1728   sez.~\ref{sec:proc_capabilities}, le ACL per i file (vedi
1729   sez.~\ref{sec:file_ACL}) o il \textit{Mandatory Access Control} di
1730   \textit{SELinux}; inoltre basandosi sul lavoro effettuato con
1731   \textit{SELinux}, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
1732   infrastruttura di sicurezza, i \textit{Linux Security Modules}, o LSM, in
1733   grado di fornire diversi agganci a livello del kernel per modularizzare
1734   tutti i possibili controlli di accesso, cosa che ha permesso di realizzare
1735   diverse alternative a \textit{SELinux}.} 
1736 di sicurezza di un sistema unix-like è fondato sui concetti di utente e
1737 gruppo, e sulla separazione fra l'amministratore (\textsl{root}, detto spesso
1738 anche \textit{superuser}) che non è sottoposto a restrizioni, ed il resto
1739 degli utenti, per i quali invece vengono effettuati i vari controlli di
1740 accesso.
1741
1742 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1743 identificatori univoci, lo \itindex{User~ID~(UID)} \textsl{User-ID}
1744 (abbreviato in \ids{UID}) ed il \itindex{Group~ID~(GID)} \textsl{Group-ID}
1745 (abbreviato in \ids{GID}). Questi servono al kernel per identificare uno
1746 specifico utente o un gruppo di utenti, per poi poter controllare che essi
1747 siano autorizzati a compiere le operazioni richieste.  Ad esempio in
1748 sez.~\ref{sec:file_access_control} vedremo come ad ogni file vengano associati
1749 un utente ed un gruppo (i suoi \textsl{proprietari}, indicati appunto tramite
1750 un \ids{UID} ed un \ids{GID}) che vengono controllati dal kernel nella
1751 gestione dei permessi di accesso.
1752
1753 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1754 evidente che per poter implementare un controllo sulle operazioni occorre
1755 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1756 anche a ciascun processo dovrà essere associato un utente e un gruppo.
1757
1758 Un semplice controllo di una corrispondenza fra identificativi non garantisce
1759 però sufficiente flessibilità per tutti quei casi in cui è necessario poter
1760 disporre di privilegi diversi, o dover impersonare un altro utente per un
1761 limitato insieme di operazioni. Per questo motivo in generale tutti i sistemi
1762 unix-like prevedono che i processi abbiano almeno due gruppi di
1763 identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}
1764 (cioè \textsl{reali} ed \textsl{effettivi}). Nel caso di Linux si aggiungono
1765 poi altri due gruppi, il \textit{saved} (\textsl{salvati}) ed il
1766 \textit{filesystem} (\textsl{di filesystem}), secondo la situazione illustrata
1767 in tab.~\ref{tab:proc_uid_gid}.
1768
1769 \begin{table}[htb]
1770   \footnotesize
1771   \centering
1772   \begin{tabular}[c]{|c|c|l|p{7cm}|}
1773     \hline
1774     \textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione} 
1775                                         & \textbf{Significato} \\ 
1776     \hline
1777     \hline
1778     \texttt{uid} & \textit{real} & \textsl{user-ID reale} 
1779                  & Indica l'utente che ha lanciato il programma.\\ 
1780     \texttt{gid} & '' &\textsl{group-ID reale} 
1781                  & Indica il gruppo principale dell'utente che ha lanciato 
1782                    il programma.\\ 
1783     \hline
1784     \texttt{euid}& \textit{effective} &\textsl{user-ID effettivo} 
1785                  & Indica l'utente usato nel controllo di accesso.\\ 
1786     \texttt{egid}& '' & \textsl{group-ID effettivo} 
1787                  & Indica il gruppo usato nel controllo di accesso.\\ 
1788     --           & -- & \textsl{group-ID supplementari} 
1789                  & Indicano gli ulteriori gruppi cui l'utente appartiene.\\ 
1790     \hline
1791     --           & \textit{saved} & \textsl{user-ID salvato} 
1792                  & Mantiene una copia dell'\acr{euid} iniziale.\\ 
1793     --           & '' & \textsl{group-ID salvato} 
1794                  & Mantiene una copia dell'\acr{egid} iniziale.\\ 
1795     \hline
1796     \texttt{fsuid}& \textit{filesystem} &\textsl{user-ID di filesystem} 
1797                  & Indica l'utente effettivo per l'accesso al filesystem. \\ 
1798     \texttt{fsgid}& '' & \textsl{group-ID di filesystem} 
1799                  & Indica il gruppo effettivo per l'accesso al filesystem.\\ 
1800     \hline
1801   \end{tabular}
1802   \caption{Identificatori di utente e gruppo associati a ciascun processo con
1803     indicazione dei suffissi usati dalle varie funzioni di manipolazione.}
1804   \label{tab:proc_uid_gid}
1805 \end{table}
1806
1807 Al primo gruppo appartengono l'\ids{UID} \textsl{reale} ed il \ids{GID}
1808 \textsl{reale}: questi vengono impostati al login ai valori corrispondenti
1809 all'utente con cui si accede al sistema (e relativo gruppo principale).
1810 Servono per l'identificazione dell'utente e normalmente non vengono mai
1811 cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
1812 modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
1813 questa possibilità è usata proprio dal programma \cmd{login} che, una volta
1814 completata la procedura di autenticazione, lancia una shell per la quale
1815 imposta questi identificatori ai valori corrispondenti all'utente che entra
1816 nel sistema.
1817
1818 Al secondo gruppo appartengono l'\ids{UID} \textsl{effettivo} e il \ids{GID}
1819 \textsl{effettivo}, a cui si aggiungono gli eventuali \ids{GID}
1820 \textsl{supplementari} dei gruppi dei quali l'utente fa parte.  Questi sono
1821 invece gli identificatori usati nelle verifiche dei permessi del processo e
1822 per il controllo di accesso ai file (argomento affrontato in dettaglio in
1823 sez.~\ref{sec:file_perm_overview}).
1824
1825 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1826 \textit{real} tranne nel caso in cui, come accennato in
1827 sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
1828 bit \acr{suid} o \acr{sgid} impostati (il significato di questi bit è
1829 affrontato in dettaglio in sez.~\ref{sec:file_special_perm}). In questo caso
1830 essi saranno impostati all'utente e al gruppo proprietari del file. Questo
1831 consente, per programmi in cui ci sia questa necessità, di dare a qualunque
1832 utente i privilegi o i permessi di un altro, compreso l'amministratore.
1833
1834 Come nel caso del \ids{PID} e del \ids{PPID}, anche tutti questi
1835 identificatori possono essere ottenuti da un programma attraverso altrettante
1836 funzioni di sistema dedicate alla loro lettura, queste sono \funcd{getuid},
1837 \funcd{geteuid}, \funcd{getgid} e \funcd{getegid}, ed i loro prototipi sono:
1838
1839 \begin{funcproto}{ 
1840 \fhead{unistd.h}
1841 \fhead{sys/types.h}
1842 \fdecl{uid\_t getuid(void)}
1843 \fdesc{Legge l'\ids{UID} reale del processo corrente.} 
1844 \fdecl{uid\_t geteuid(void)}
1845 \fdesc{Legge l'\ids{UID} effettivo del processo corrente.} 
1846 \fdecl{gid\_t getgid(void)}
1847 \fdesc{Legge il \ids{GID} reale del processo corrente.} 
1848 \fdecl{gid\_t getegid(void)}
1849 \fdesc{Legge il \ids{GID} effettivo del processo corrente.}
1850 }
1851 {Le funzioni ritornano i rispettivi identificativi del processo corrente, e
1852   non sono previste condizioni di errore.}
1853 \end{funcproto}
1854
1855 In generale l'uso di privilegi superiori, ottenibile con un \ids{UID}
1856 \textsl{effettivo} diverso da quello reale, deve essere limitato il più
1857 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1858 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1859 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1860 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1861 servano di nuovo.
1862
1863 Questo in Linux viene fatto usando altri due gruppi di identificatori, il
1864 \textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
1865 SVr4, e previsto dallo standard POSIX quando è definita
1866 \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
1867   del programma su altri Unix è buona norma controllare sempre la
1868   disponibilità di queste funzioni controllando se questa costante è
1869   definita.} il secondo gruppo è specifico di Linux e viene usato per
1870 migliorare la sicurezza con NFS (il \textit{Network File System}, protocollo
1871 che consente di accedere ai file via rete).
1872
1873 L'\ids{UID} \textsl{salvato} ed il \ids{GID} \textsl{salvato} sono copie
1874 dell'\ids{UID} \textsl{effettivo} e del \ids{GID} \textsl{effettivo} del
1875 processo padre, e vengono impostati dalla funzione \func{exec} all'avvio del
1876 processo, come copie dell'\ids{UID} \textsl{effettivo} e del \ids{GID}
1877 \textsl{effettivo} dopo che questi sono stati impostati tenendo conto di
1878 eventuali permessi \acr{suid} o \acr{sgid} (su cui torneremo in
1879 sez.~\ref{sec:file_special_perm}).  Essi quindi consentono di tenere traccia
1880 di quale fossero utente e gruppo effettivi all'inizio dell'esecuzione di un
1881 nuovo programma.
1882
1883 L'\ids{UID} \textsl{di filesystem} e il \ids{GID} \textsl{di filesystem} sono
1884 un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
1885 (torneremo sull'argomento in sez.~\ref{sec:proc_setuid}). Essi sono una
1886 replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
1887 quali si sostituiscono per tutte le operazioni di verifica dei permessi
1888 relativi ai file (trattate in sez.~\ref{sec:file_perm_overview}).  Ogni
1889 cambiamento effettuato sugli identificatori effettivi viene automaticamente
1890 riportato su di essi, per cui in condizioni normali si può tranquillamente
1891 ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
1892
1893
1894 \subsection{Le funzioni di gestione degli identificatori dei processi}
1895 \label{sec:proc_setuid}
1896
1897 Le funzioni di sistema più comuni che vengono usate per cambiare identità
1898 (cioè utente e gruppo di appartenenza) ad un processo, e che come accennato in
1899 sez.~\ref{sec:proc_access_id} seguono la semantica POSIX che prevede
1900 l'esistenza dell'\ids{UID} salvato e del \ids{GID} salvato, sono
1901 rispettivamente \funcd{setuid} e \funcd{setgid}; i loro prototipi sono:
1902
1903 \begin{funcproto}{
1904 \fhead{unistd.h}
1905 \fhead{sys/types.h}
1906 \fdecl{int setuid(uid\_t uid)}
1907 \fdesc{Imposta l'\ids{UID} del processo corrente.}
1908 \fdecl{int setgid(gid\_t gid)}
1909 \fdesc{Imposta il \ids{GID} del processo corrente.}
1910 }
1911 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
1912 caso \var{errno} uno dei valori: 
1913 \begin{errlist}
1914 \item[\errcode{EAGAIN}] (solo per \func{setuid}) la chiamata cambierebbe
1915   l'\ids{UID} reale ma il kernel non dispone temporaneamente delle risorse per
1916   farlo, oppure, per i kernel precendenti il 3.1, il cambiamento
1917   dell'\ids{UID} reale farebbe superare il limite per il numero dei processi
1918   \const{RLIMIT\_NPROC} (vedi sez.~\ref{sec:sys_resource_limit}).
1919 \item[\errcode{EINVAL}] il valore di dell'argomento non è valido per il
1920     \textit{namespace} corrente (vedi sez.~\ref{sec:process_namespaces}).
1921 \item[\errcode{EPERM}] non si hanno i permessi per l'operazione richiesta.
1922 \end{errlist} 
1923 }
1924 \end{funcproto}
1925
1926 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1927 la prima, la seconda si comporta esattamente allo stesso modo facendo
1928 riferimento al \ids{GID} invece che all'\ids{UID}. Gli eventuali \ids{GID}
1929 supplementari non vengono modificati.
1930
1931 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1932 l'\ids{UID} effettivo è zero (cioè è quello dell'amministratore di sistema o
1933 il processo ha la la capacità \const{CAP\_SETUID}) allora tutti gli
1934 identificatori (\textit{real}, \textit{effective} e \textit{saved}) vengono
1935 impostati al valore specificato da \param{uid}, altrimenti viene impostato
1936 solo l'\ids{UID} effettivo, e soltanto se il valore specificato corrisponde o
1937 all'\ids{UID} reale o all'\ids{UID} salvato, ottenendo un errore di
1938 \errcode{EPERM} negli altri casi.
1939
1940 E' importante notare che la funzione può fallire con \errval{EAGAIN} anche
1941 quando viene invocata da un processo con privilegi di amministratore per
1942 cambiare il proprio l'\ids{UID} reale, sia per una temporanea indisponibilità
1943 di risorse del kernel, sia perché l'utente di cui si vuole assumere
1944 l'\ids{UID} andrebbe a superare un eventuale limite sul numero di processi (il
1945 limite \const{RLIMIT\_NPROC}, che tratteremo in
1946 sez.~\ref{sec:sys_resource_limit}),\footnote{non affronteremo qui l'altro caso
1947   di errore, che può avvenire solo quando si esegue la funzione all'interno di
1948   un diverso \textit{user namespace}, argomento su cui torneremo in
1949   sez.~\ref{sec:process_namespaces}.} pertanto occorre sempre verificare lo
1950 stato di uscita della funzione.
1951
1952 Non controllare questo tipo di errori perché si presume che la funzione abbia
1953 sempre successo quando si hanno i privilegi di amministratore può avere
1954 conseguente devastanti per la sicurezza, in particolare quando la si usa per
1955 cedere i suddetti privilegi ed eseguire un programma per conto di un utente
1956 non privilegiato.
1957
1958 E' per diminuire l'impatto di questo tipo di disattenzioni che a partire dal
1959 kernel 3.1 il comportamento di \func{setuid} e di tutte le analoghe funzioni
1960 che tratteremo nel seguito di questa sezione è stato modificato e nel caso di
1961 superamento del limite sulle risorse esse hanno comunque successo. Quando
1962 questo avviene il processo assume comunque il nuovo \ids{UID} ed il controllo
1963 sul superamento di \const{RLIMIT\_NPROC} viene posticipato ad una eventuale
1964 successiva invocazione di \func{execve} (essendo questo poi il caso d'uso più
1965 comune). In tal caso, se alla chiamata ancora sussiste la situazione di
1966 superamento del limite, sarà \func{execve} a fallire con un errore di
1967 \const{EAGAIN}.\footnote{che pertanto, a partire dal kernel 3.1, può
1968   restituire anche questo errore, non presente in altri sistemi
1969   \textit{unix-like}.}
1970
1971 Come accennato l'uso principale di queste funzioni è quello di poter
1972 consentire ad un programma con i bit \acr{suid} o \acr{sgid} impostati (vedi
1973 sez.~\ref{sec:file_special_perm}) di riportare l'\ids{UID} effettivo a quello
1974 dell'utente che ha lanciato il programma, effettuare il lavoro che non
1975 necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
1976
1977 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
1978 viene gestito l'accesso al file \sysfiled{/var/run/utmp}.  In questo file viene
1979 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1980 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1981 falsificare la registrazione.
1982
1983 Per questo motivo questo file (e l'analogo \sysfiled{/var/log/wtmp} su cui
1984 vengono registrati login e logout) appartengono ad un gruppo dedicato (in
1985 genere \acr{utmp}) ed i programmi che devono accedervi (ad esempio tutti i
1986 programmi di terminale in X, o il programma \cmd{screen} che crea terminali
1987 multipli su una console) appartengono a questo gruppo ed hanno il bit
1988 \acr{sgid} impostato.
1989
1990 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
1991 situazione degli identificatori è la seguente:
1992 \begin{eqnarray*}
1993   \label{eq:1}
1994   \textsl{group-ID reale}      &=& \textrm{\ids{GID} (del chiamante)} \\
1995   \textsl{group-ID effettivo}  &=& \textrm{\acr{utmp}} \\
1996   \textsl{group-ID salvato}    &=& \textrm{\acr{utmp}}
1997 \end{eqnarray*}
1998 in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
1999 programma può accedere a \sysfile{/var/run/utmp} in scrittura ed aggiornarlo.
2000 A questo punto il programma può eseguire una \code{setgid(getgid())} per
2001 impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il
2002 \textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
2003 non sarà possibile lanciare dal terminale programmi che modificano detto file,
2004 in tal caso infatti la situazione degli identificatori sarebbe:
2005 \begin{eqnarray*}
2006   \label{eq:2}
2007   \textsl{group-ID reale}      &=& \textrm{\ids{GID} (invariato)}  \\
2008   \textsl{group-ID effettivo}  &=& \textrm{\ids{GID}} \\
2009   \textsl{group-ID salvato}    &=& \textrm{\acr{utmp} (invariato)}
2010 \end{eqnarray*}
2011 e ogni processo lanciato dal terminale avrebbe comunque \ids{GID} come
2012 \textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
2013 aggiornare lo stato di \sysfile{/var/run/utmp} il programma eseguirà una
2014 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
2015 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
2016 in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la
2017 funzione avrà successo e riporterà la situazione a:
2018 \begin{eqnarray*}
2019   \label{eq:3}
2020   \textsl{group-ID reale}      &=& \textrm{\ids{GID} (invariato)}  \\
2021   \textsl{group-ID effettivo}  &=& \textrm{\acr{utmp}} \\
2022   \textsl{group-ID salvato}    &=& \textrm{\acr{utmp} (invariato)}
2023 \end{eqnarray*}
2024 consentendo l'accesso a \sysfile{/var/run/utmp}.
2025
2026 Occorre però tenere conto che tutto questo non è possibile con un processo con
2027 i privilegi di amministratore, in tal caso infatti l'esecuzione di una
2028 \func{setuid} comporta il cambiamento di tutti gli identificatori associati al
2029 processo, rendendo impossibile riguadagnare i privilegi di amministratore.
2030 Questo comportamento è corretto per l'uso che ne fa un programma come
2031 \cmd{login} una volta che crea una nuova shell per l'utente, ma quando si
2032 vuole cambiare soltanto l'\ids{UID} effettivo del processo per cedere i
2033 privilegi occorre ricorrere ad altre funzioni.
2034
2035 Le due funzioni di sistema \funcd{setreuid} e \funcd{setregid} derivano da BSD
2036 che, non supportando (almeno fino alla versione 4.3+BSD) gli identificatori
2037 del gruppo \textit{saved}, le usa per poter scambiare fra di loro
2038 \textit{effective} e \textit{real}; i rispettivi prototipi sono:
2039
2040 \begin{funcproto}{ 
2041 \fhead{unistd.h}
2042 \fhead{sys/types.h}
2043 \fdecl{int setreuid(uid\_t ruid, uid\_t euid)}
2044 \fdesc{Imposta \ids{UID} reale e \ids{UID} effettivo del processo corrente.} 
2045 \fdecl{int setregid(gid\_t rgid, gid\_t egid)}
2046 \fdesc{Imposta \ids{GID} reale e \ids{GID} effettivo del processo corrente.} 
2047 }
2048 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2049 caso \var{errno} assume i valori visti per \func{setuid}/\func{setgid}.
2050 }
2051 \end{funcproto}
2052
2053 Le due funzioni sono identiche, quanto diremo per la prima riguardo gli
2054 \ids{UID} si applica alla seconda per i \ids{GID}.  La funzione
2055 \func{setreuid} imposta rispettivamente l'\ids{UID} reale e l'\ids{UID}
2056 effettivo del processo corrente ai valori specificati da \param{ruid}
2057 e \param{euid}.
2058
2059 I processi non privilegiati possono impostare solo valori che corrispondano o
2060 al loro \ids{UID} effettivo o a quello reale o a quello salvato, valori
2061 diversi comportano il fallimento della chiamata.  L'amministratore invece può
2062 specificare un valore qualunque.  Specificando un argomento di valore $-1$
2063 l'identificatore corrispondente verrà lasciato inalterato.
2064
2065 Con queste funzioni si possono scambiare fra loro gli \ids{UID} reale ed
2066 effettivo, e pertanto è possibile implementare un comportamento simile a
2067 quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
2068 scambio, e recuperandoli, una volta eseguito il lavoro non privilegiato, con
2069 un secondo scambio.
2070
2071 In questo caso però occorre porre molta attenzione quando si creano nuovi
2072 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
2073 questo caso infatti essi avranno un \ids{UID} reale privilegiato, che dovrà
2074 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
2075 programma, occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
2076 prima della \func{exec} per uniformare l'\ids{UID} reale a quello effettivo,
2077 perché in caso contrario il nuovo programma potrebbe a sua volta effettuare
2078 uno scambio e riottenere dei privilegi non previsti.
2079
2080 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
2081 si pone anche per l'\ids{UID} salvato. Ma la funzione \func{setreuid} deriva
2082 da un'implementazione di sistema che non ne prevede la presenza, e quindi non
2083 è possibile usarla per correggere la situazione come nel caso precedente. Per
2084 questo motivo in Linux tutte le volte che si imposta un qualunque valore
2085 diverso da quello dall'\ids{UID} reale corrente, l'\ids{UID} salvato viene
2086 automaticamente uniformato al valore dell'\ids{UID} effettivo.
2087
2088 Altre due funzioni di sistema, \funcd{seteuid} e \funcd{setegid}, sono
2089 un'estensione dello standard POSIX.1, ma sono comunque supportate dalla
2090 maggior parte degli Unix, esse vengono usate per cambiare gli identificatori
2091 del gruppo \textit{effective} ed i loro prototipi sono:
2092
2093 \begin{funcproto}{ 
2094 \fhead{unistd.h}
2095 \fhead{sys/types.h}
2096 \fdecl{int seteuid(uid\_t uid)}
2097 \fdesc{Imposta l'\ids{UID} effettivo del processo corrente.} 
2098 \fdecl{int setegid(gid\_t gid)}
2099 \fdesc{Imposta il \ids{GID} effettivo del processo corrente.} 
2100 }
2101 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2102 caso \var{errno} assume i valori visti per \func{setuid}/\func{setgid}. 
2103 }
2104 \end{funcproto}
2105
2106 Ancora una volta le due funzioni sono identiche, e quanto diremo per la prima
2107 riguardo gli \ids{UID} si applica allo stesso modo alla seconda per i
2108 \ids{GID}. Con \func{seteuid} gli utenti normali possono impostare l'\ids{UID}
2109 effettivo solo al valore dell'\ids{UID} reale o dell'\ids{UID} salvato,
2110 l'amministratore può specificare qualunque valore. Queste funzioni sono usate
2111 per permettere all'amministratore di impostare solo l'\ids{UID} effettivo,
2112 dato che l'uso normale di \func{setuid} comporta l'impostazione di tutti gli
2113 identificatori.
2114  
2115 Le due funzioni di sistema \funcd{setresuid} e \funcd{setresgid} sono invece
2116 un'estensione introdotta in Linux (a partire dal kernel 2.1.44) e permettono
2117 un completo controllo su tutti e tre i gruppi di identificatori
2118 (\textit{real}, \textit{effective} e \textit{saved}), i loro prototipi sono:
2119
2120 \begin{funcproto}{ 
2121 \fhead{unistd.h}
2122 \fhead{sys/types.h}
2123 \fdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)}
2124 \fdesc{Imposta l'\ids{UID} reale, effettivo e salvato del processo corrente.} 
2125 \fdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)}
2126 \fdesc{Imposta il \ids{GID} reale, effettivo e salvato del processo corrente.} 
2127 }
2128 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2129 caso \var{errno} può assumere solo il valore \errcode{EPERM}.
2130 }
2131 \end{funcproto}
2132
2133 Di nuovo le due funzioni sono identiche e quanto detto per la prima riguardo
2134 gli \ids{UID} si applica alla seconda per i \ids{GID}.  La funzione
2135 \func{setresuid} imposta l'\ids{UID} reale, l'\ids{UID} effettivo e
2136 l'\ids{UID} salvato del processo corrente ai valori specificati
2137 rispettivamente dagli argomenti \param{ruid}, \param{euid} e \param{suid}.  I
2138 processi non privilegiati possono cambiare uno qualunque degli\ids{UID} solo
2139 ad un valore corrispondente o all'\ids{UID} reale, o a quello effettivo o a
2140 quello salvato, l'amministratore può specificare i valori che vuole. Un valore
2141 di $-1$ per un qualunque argomento lascia inalterato l'identificatore
2142 corrispondente.
2143
2144 Per queste funzioni di sistema esistono anche due controparti,
2145 \funcd{getresuid} e \funcd{getresgid},\footnote{le funzioni non sono standard,
2146   anche se appaiono in altri kernel, su Linux sono presenti dal kernel 2.1.44
2147   e con le versioni della \acr{glibc} a partire dalla 2.3.2, definendo la
2148   macro \macro{\_GNU\_SOURCE}.} che permettono di leggere in blocco i vari
2149 identificatori; i loro prototipi sono:
2150
2151 \begin{funcproto}{ 
2152 \fhead{unistd.h}
2153 \fhead{sys/types.h}
2154 \fdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)}
2155 \fdesc{Legge l'\ids{UID} reale, effettivo e salvato del processo corrente.} 
2156 \fdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)}
2157 \fdesc{Legge il \ids{GID} reale, effettivo e salvato del processo corrente.} 
2158 }
2159 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2160   caso \var{errno} può assumere solo il valore \errcode{EFAULT} se gli
2161   indirizzi delle variabili di ritorno non sono validi.  }
2162 \end{funcproto}
2163
2164 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
2165 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
2166 specificati come puntatori (è un altro esempio di \textit{value result
2167   argument}). Si noti che queste funzioni sono le uniche in grado di leggere
2168 gli identificatori del gruppo \textit{saved}.
2169
2170 Infine le funzioni \func{setfsuid} e \func{setfsgid} servono per impostare gli
2171 identificatori del gruppo \textit{filesystem} che sono usati da Linux per il
2172 controllo dell'accesso ai file.  Come già accennato in
2173 sez.~\ref{sec:proc_access_id} Linux definisce questo ulteriore gruppo di
2174 identificatori, che in circostanze normali sono assolutamente equivalenti a
2175 quelli del gruppo \textit{effective}, dato che ogni cambiamento di questi
2176 ultimi viene immediatamente riportato su di essi.
2177
2178 C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
2179 identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
2180 ovviare ad un problema di sicurezza che si presenta quando si deve
2181 implementare un server NFS. 
2182
2183 Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai
2184 file per assumere l'identità del singolo utente remoto, ma se questo viene
2185 fatto cambiando l'\ids{UID} effettivo o l'\ids{UID} reale il server si espone
2186 alla ricezione di eventuali segnali ostili da parte dell'utente di cui ha
2187 temporaneamente assunto l'identità.  Cambiando solo l'\ids{UID} di filesystem
2188 si ottengono i privilegi necessari per accedere ai file, mantenendo quelli
2189 originari per quanto riguarda tutti gli altri controlli di accesso, così che
2190 l'utente non possa inviare segnali al server NFS.
2191
2192 Le due funzioni di sistema usate appositamente per cambiare questi
2193 identificatori sono \funcd{setfsuid} e \funcd{setfsgid} ovviamente sono
2194 specifiche di Linux e non devono essere usate se si intendono scrivere
2195 programmi portabili; i loro prototipi sono:
2196
2197 \begin{funcproto}{ 
2198 \fhead{sys/fsuid.h}
2199 \fdecl{int setfsuid(uid\_t fsuid)}
2200 \fdesc{Imposta l'\ids{UID} di filesystem del processo corrente.} 
2201 \fdecl{int setfsgid(gid\_t fsgid)}
2202 \fdesc{Legge il \ids{GID} di filesystem del processo corrente.} 
2203 }
2204 {Le funzioni restituiscono il nuovo valore dell'identificativo in caso di
2205   successo e quello corrente per un errore, in questo caso non viene però
2206   impostato nessun codice di errore in \var{errno}.}
2207 \end{funcproto}
2208
2209 Le due funzioni sono analoghe ed usano il valore passato come argomento per
2210 effettuare l'impostazione dell'identificativo.  Le funzioni hanno successo
2211 solo se il processo chiamante ha i privilegi di amministratore o, per gli
2212 altri utenti, se il valore specificato coincide con uno dei di quelli del
2213 gruppo \textit{real}, \textit{effective} o \textit{saved}.
2214
2215
2216 \subsection{Le funzioni per la gestione dei gruppi associati a un processo}
2217 \label{sec:proc_setgroups}
2218
2219 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
2220 gruppi supplementari cui un utente può appartenere. Ogni processo può avere
2221 almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
2222   gruppi secondari può essere ottenuto con \func{sysconf} (vedi
2223   sez.~\ref{sec:sys_limits}), leggendo il parametro
2224   \const{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
2225 ereditati dal processo padre e possono essere cambiati con queste funzioni.
2226
2227 La funzione di sistema che permette di leggere i gruppi supplementari
2228 associati ad un processo è \funcd{getgroups}; questa funzione è definita nello
2229 standard POSIX.1, ed il suo prototipo è:
2230
2231 \begin{funcproto}{ 
2232 \fhead{sys/types.h}
2233 \fhead{unistd.h}
2234 \fdecl{int getgroups(int size, gid\_t list[])}
2235 \fdesc{Legge gli identificatori dei gruppi supplementari.} 
2236 }
2237 {La funzione ritorna il numero di gruppi letti in caso di successo e $-1$ per
2238   un errore, nel qual caso \var{errno} assumerà uno dei valori:
2239 \begin{errlist}
2240 \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
2241 \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
2242   minore del numero di gruppi supplementari del processo.
2243 \end{errlist}}
2244 \end{funcproto}
2245
2246 La funzione legge gli identificatori dei gruppi supplementari del processo sul
2247 vettore \param{list} che deve essere di dimensione pari a \param{size}. Non è
2248 specificato se la funzione inserisca o meno nella lista il \ids{GID} effettivo
2249 del processo. Se si specifica un valore di \param{size} uguale a $0$ allora
2250 l'argomento \param{list} non viene modificato, ma si ottiene il numero di
2251 gruppi supplementari.
2252
2253 Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
2254 ottenere tutti i gruppi a cui appartiene utente identificato per nome; il suo
2255 prototipo è:
2256
2257 \begin{funcproto}{ 
2258 \fhead{grp.h}
2259 \fdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups, int
2260   *ngroups)} 
2261 \fdesc{Legge i gruppi cui appartiene un utente.} 
2262 }
2263 {La funzione ritorna il numero di gruppi ottenuto in caso di successo e $-1$
2264   per un errore, che avviene solo quando il numero di gruppi è maggiore di
2265   quelli specificati con \param{ngroups}.}
2266 \end{funcproto}
2267
2268 La funzione esegue una scansione del database dei gruppi (si veda
2269 sez.~\ref{sec:sys_user_group}) per leggere i gruppi supplementari dell'utente
2270 specificato per nome (e non con un \ids{UID}) nella stringa passata con
2271 l'argomento \param{user}. Ritorna poi nel vettore \param{groups} la lista dei
2272 \ids{GID} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups},
2273 che in ingresso deve indicare la dimensione di \param{group}, è passato come
2274 \textit{value result argument} perché, qualora il valore specificato sia
2275 troppo piccolo, la funzione ritorna $-1$, passando comunque indietro il numero
2276 dei gruppi trovati, in modo da poter ripetere la chiamata con un vettore di
2277 dimensioni adeguate.
2278
2279 Infine per impostare i gruppi supplementari di un processo ci sono due
2280 funzioni, che possono essere usate solo se si hanno i privilegi di
2281 amministratore.\footnote{e più precisamente se si ha la \textit{capability}
2282   \const{CAP\_SETGID}.} La prima delle due è la funzione di sistema
2283 \funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, ma a
2284   differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
2285   poterla utilizzare deve essere definita la macro \macro{\_BSD\_SOURCE}.} ed
2286 il suo prototipo è:
2287
2288 \begin{funcproto}{ 
2289 \fhead{grp.h}
2290 \fdecl{int setgroups(size\_t size, gid\_t *list)}
2291 \fdesc{Imposta i gruppi supplementari del processo.} 
2292 }
2293 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2294 caso \var{errno} assumerà uno dei valori:
2295 \begin{errlist}
2296 \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
2297 \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
2298     massimo consentito di gruppi supplementari.
2299 \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
2300 \end{errlist}}
2301 \end{funcproto}
2302
2303 La funzione imposta i gruppi supplementari del processo corrente ai valori
2304 specificati nel vettore passato con l'argomento \param{list}, di dimensioni
2305 date dall'argomento \param{size}. Il numero massimo di gruppi supplementari
2306 che si possono impostare è un parametro di sistema, che può essere ricavato
2307 con le modalità spiegate in sez.~\ref{sec:sys_characteristics}.
2308
2309 Se invece si vogliono impostare i gruppi supplementari del processo a quelli
2310 di un utente specifico, si può usare la funzione \funcd{initgroups} il cui
2311 prototipo è:
2312
2313 \begin{funcproto}{ 
2314 \fhead{sys/types.h}
2315 \fhead{grp.h}
2316 \fdecl{int initgroups(const char *user, gid\_t group)}
2317 \fdesc{Inizializza la lista dei gruppi supplementari.} 
2318 }
2319 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2320 caso \var{errno} assumerà uno dei valori:
2321 \begin{errlist}
2322 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare lo spazio per
2323   informazioni dei gruppi.
2324 \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
2325 \end{errlist}}
2326 \end{funcproto}
2327
2328 La funzione esegue la scansione del database dei gruppi (usualmente
2329 \conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
2330 (di nuovo specificato per nome e non per \ids{UID}) con cui costruisce una
2331 lista di gruppi supplementari, a cui aggiunge anche \param{group}, infine
2332 imposta questa lista per il processo corrente usando \func{setgroups}.  Si
2333 tenga presente che sia \func{setgroups} che \func{initgroups} non sono
2334 definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle
2335 quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
2336 \cmd{-ansi}, è pertanto meglio evitarle se si vuole scrivere codice portabile.
2337
2338  
2339 \section{La gestione della priorità dei processi}
2340 \label{sec:proc_priority}
2341
2342 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
2343 lo \textit{scheduler} assegna la CPU ai vari processi attivi.  In particolare
2344 prenderemo in esame i vari meccanismi con cui viene gestita l'assegnazione del
2345 tempo di CPU, ed illustreremo le varie funzioni di gestione. Tratteremo infine
2346 anche le altre priorità dei processi (come quelle per l'accesso a disco)
2347 divenute disponibili con i kernel più recenti.
2348
2349
2350 \subsection{I meccanismi di \textit{scheduling}}
2351 \label{sec:proc_sched}
2352
2353 \itindbeg{scheduler}
2354
2355 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
2356 il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
2357 ed oggetto di numerose ricerche; in generale essa dipende in maniera
2358 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
2359 cui non esiste un meccanismo che sia valido per tutti gli usi.
2360
2361 La caratteristica specifica di un sistema multitasking come Linux è quella del
2362 cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
2363   multitasking}: questo significa che al contrario di altri sistemi (che usano
2364 invece il cosiddetto \itindex{cooperative~multitasking} \textit{cooperative
2365   multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
2366 quando la CPU deve essere passata ad un altro processo. Come accennato in
2367 sez.~\ref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
2368 apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
2369 distribuire al meglio il tempo di CPU fra i vari processi.
2370
2371 La cosa è resa ancora più complicata dal fatto che con le architetture
2372 multi-processore si deve anche scegliere quale sia la CPU più opportuna da
2373 utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
2374   rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
2375   un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
2376   banale.}  Tutto questo comunque appartiene alle sottigliezze
2377 dell'implementazione del kernel; dal punto di vista dei programmi che girano
2378 in \textit{user space}, anche quando si hanno più processori (e dei processi
2379 che sono eseguiti davvero in contemporanea), le politiche di
2380 \textit{scheduling} riguardano semplicemente l'allocazione della risorsa
2381 \textsl{tempo di esecuzione}, la cui assegnazione sarà governata dai
2382 meccanismi di scelta delle priorità che restano gli stessi indipendentemente
2383 dal numero di processori.
2384
2385 Si tenga conto poi che i processi non devono solo eseguire del codice: ad
2386 esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
2387 venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
2388 tempo.  In tutti questi casi la CPU diventa disponibile ed è compito dello
2389 kernel provvedere a mettere in esecuzione un altro processo.
2390
2391 Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
2392 processo, in Linux un processo può trovarsi in uno degli stati riportati in
2393 tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
2394 \textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
2395 sia la sua priorità, un processo non potrà mai essere messo in esecuzione
2396 fintanto che esso si trova in uno qualunque degli altri stati.
2397
2398 \begin{table}[htb]
2399   \footnotesize
2400   \centering
2401   \begin{tabular}[c]{|p{2.4cm}|c|p{9cm}|}
2402     \hline
2403     \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
2404     \hline
2405     \hline
2406     \textit{runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
2407                                     essere eseguito (cioè è in attesa che gli
2408                                     venga assegnata la CPU).\\
2409     \textit{sleep}   & \texttt{S} & Il processo  è in attesa di un
2410                                     risposta dal sistema, ma può essere 
2411                                     interrotto da un segnale.\\
2412     \textit{uninterrutible sleep}& \texttt{D} & Il  processo è in
2413                                     attesa di un risposta dal sistema (in 
2414                                     genere per I/O), e non può essere
2415                                     interrotto in nessuna circostanza.\\
2416     \textit{stopped} & \texttt{T} & Il processo è stato fermato con un
2417                                     \signal{SIGSTOP}, o è tracciato.\\
2418     \textit{zombie}  & \texttt{Z} & Il processo è terminato ma il
2419                                     suo stato di terminazione non è ancora
2420                                     stato letto dal padre.\\
2421     \textit{killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
2422                                     2.6.25, sostanzialmente identico
2423                                     all'\textit{uninterrutible sleep} con la
2424                                     sola differenza che il processo può
2425                                     terminato con \signal{SIGKILL} (usato per
2426                                     lo più per NFS).\\ 
2427     \hline
2428   \end{tabular}
2429   \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
2430     \texttt{STAT} si è riportata la corrispondente lettera usata dal comando 
2431     \cmd{ps} nell'omonimo campo.}
2432   \label{tab:proc_proc_states}
2433 \end{table}
2434
2435 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
2436 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
2437 dello scopo del programma non è detto neanche che sia la più importante, dato
2438 che molti programmi dipendono in maniera molto più critica dall'I/O. Per
2439 questo motivo non è affatto detto che dare ad un programma la massima priorità
2440 di esecuzione abbia risultati significativi in termini di prestazioni.
2441
2442 Il meccanismo tradizionale di \textit{scheduling} di Unix (che tratteremo in
2443 sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
2444 \textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
2445 i meno importanti, potessero ricevere un po' di tempo di CPU. In sostanza
2446 quando un processo ottiene la CPU la sua priorità viene diminuita. In questo
2447 modo alla fine, anche un processo con priorità iniziale molto bassa, finisce
2448 per avere una priorità sufficiente per essere eseguito.
2449
2450 Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
2451   assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
2452 alla normale priorità dinamica), per tenere conto dei sistemi
2453 \textit{real-time},\footnote{per sistema \textit{real-time} si intende un
2454   sistema in grado di eseguire operazioni in un tempo ben determinato; in
2455   genere si tende a distinguere fra l'\textit{hard real-time} in cui è
2456   necessario che i tempi di esecuzione di un programma siano determinabili con
2457   certezza assoluta (come nel caso di meccanismi di controllo di macchine,
2458   dove uno sforamento dei tempi avrebbe conseguenze disastrose), e
2459   \textit{soft-real-time} in cui un occasionale sforamento è ritenuto
2460   accettabile.} in cui è vitale che i processi che devono essere eseguiti in
2461 un determinato momento non debbano aspettare la conclusione di altri che non
2462 hanno questa necessità.
2463
2464 Il concetto di priorità assoluta dice che quando due processi si contendono
2465 l'esecuzione, vince sempre quello con la priorità assoluta più alta.
2466 Ovviamente questo avviene solo per i processi che sono pronti per essere
2467 eseguiti (cioè nello stato \textit{runnable}).  La priorità assoluta viene in
2468 genere indicata con un numero intero, ed un valore più alto comporta una
2469 priorità maggiore. Su questa politica di \textit{scheduling} torneremo in
2470 sez.~\ref{sec:proc_real_time}.
2471
2472 In generale quello che succede in tutti gli Unix moderni è che ai processi
2473 normali viene sempre data una priorità assoluta pari a zero, e la decisione di
2474 assegnazione della CPU è fatta solo con il meccanismo tradizionale della
2475 priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
2476 assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
2477 priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
2478 bisogno della CPU.
2479
2480
2481 \subsection{Il meccanismo di \textit{scheduling} standard}
2482 \label{sec:proc_sched_stand}
2483
2484 A meno che non si abbiano esigenze specifiche,\footnote{per alcune delle quali
2485   sono state introdotte delle varianti specifiche.} l'unico meccanismo di
2486 \textit{scheduling} con il quale si avrà a che fare è quello tradizionale, che
2487 prevede solo priorità dinamiche. È di questo che, di norma, ci si dovrà
2488 preoccupare nella programmazione.  Come accennato in Linux i processi ordinari
2489 hanno tutti una priorità assoluta nulla; quello che determina quale, fra tutti
2490 i processi in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
2491 \textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna
2492   \texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché
2493 varia nel corso dell'esecuzione di un processo.
2494
2495 Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
2496   dipende strettamente dalla versione di kernel; in particolare a partire
2497   dalla serie 2.6.x lo \textit{scheduler} è stato riscritto completamente, con
2498   molte modifiche susseguitesi per migliorarne le prestazioni, per un certo
2499   periodo ed è stata anche introdotta la possibilità di usare diversi
2500   algoritmi, selezionabili sia in fase di compilazione, che, nelle versioni
2501   più recenti, all'avvio (addirittura è stato ideato un sistema modulare che
2502   permette di cambiare lo \textit{scheduler} a sistema attivo).} ma a grandi
2503 linee si può dire che ad ogni processo è assegnata una \textit{time-slice},
2504 cioè un intervallo di tempo (letteralmente una fetta) per il quale, a meno di
2505 eventi esterni, esso viene eseguito senza essere interrotto.  Inoltre la
2506 priorità dinamica viene calcolata dallo \textit{scheduler} a partire da un
2507 valore iniziale che viene \textsl{diminuito} tutte le volte che un processo è
2508 in stato \textit{runnable} ma non viene posto in esecuzione.\footnote{in
2509   realtà il calcolo della priorità dinamica e la conseguente scelta di quale
2510   processo mettere in esecuzione avviene con un algoritmo molto più
2511   complicato, che tiene conto anche della \textsl{interattività} del processo,
2512   utilizzando diversi fattori, questa è una brutale semplificazione per
2513   rendere l'idea del funzionamento, per una trattazione più dettagliata, anche
2514   se non aggiornatissima, dei meccanismi di funzionamento dello
2515   \textit{scheduler} si legga il quarto capitolo di \cite{LinKernDev}.} Lo
2516 \textit{scheduler} infatti mette sempre in esecuzione, fra tutti i processi in
2517 stato \textit{runnable}, quello che ha il valore di priorità dinamica più
2518 basso.\footnote{con le priorità dinamiche il significato del valore numerico
2519   ad esse associato è infatti invertito, un valore più basso significa una
2520   priorità maggiore.} Il fatto che questo valore venga diminuito quando un
2521 processo non viene posto in esecuzione pur essendo pronto, significa che la
2522 priorità dei processi che non ottengono l'uso del processore viene
2523 progressivamente incrementata, così che anche questi alla fine hanno la
2524 possibilità di essere eseguiti.
2525
2526 Sia la dimensione della \textit{time-slice} che il valore di partenza della
2527 priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o
2528 \textit{niceness}) del processo.\footnote{questa è una delle tante proprietà
2529   che ciascun processo si porta dietro, essa viene ereditata dai processi
2530   figli e mantenuta attraverso una \func{exec}; fino alla serie 2.4 essa era
2531   mantenuta nell'omonimo campo \texttt{nice} della \texttt{task\_struct}, con
2532   la riscrittura dello \textit{scheduler} eseguita nel 2.6 viene mantenuta nel
2533   campo \texttt{static\_prio} come per le priorità statiche.} L'origine del
2534 nome di questo parametro sta nel fatto che generalmente questo viene usato per
2535 \textsl{diminuire} la priorità di un processo, come misura di cortesia nei
2536 confronti degli altri.  I processi infatti vengono creati dal sistema con un
2537 valore nullo e nessuno è privilegiato rispetto agli altri. Specificando un
2538 valore di \textit{nice} positivo si avrà una \textit{time-slice} più breve ed
2539 un valore di priorità dinamica iniziale più alto, mentre un valore negativo
2540 darà una \textit{time-slice} più lunga ed un valore di priorità dinamica
2541 iniziale più basso.
2542
2543 Esistono diverse funzioni che consentono di indicare un valore di
2544 \textit{nice} di un processo; la più semplice è \funcd{nice}, che opera sul
2545 processo corrente, il suo prototipo è:
2546
2547 \begin{funcproto}{ 
2548 \fhead{unistd.h}
2549 \fdecl{int nice(int inc)}
2550 \fdesc{Aumenta il valore di \textit{nice} del processo corrente.} 
2551 }
2552 {La funzione ritorna il nuovo valore di \textit{nice} in caso di successo e
2553   $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
2554 \begin{errlist}
2555   \item[\errcode{EPERM}] non si ha il permesso di specificare un valore
2556     di \param{inc} negativo. 
2557 \end{errlist}}
2558 \end{funcproto}
2559
2560 \constbeg{PRIO\_MIN}
2561 \constbeg{PRIO\_MAX}
2562
2563 L'argomento \param{inc} indica l'incremento da effettuare rispetto al valore
2564 di \textit{nice} corrente, che può assumere valori compresi fra
2565 \const{PRIO\_MIN} e \const{PRIO\_MAX}; nel caso di Linux sono fra $-20$ e
2566 $19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di
2567   kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere
2568   anche l'intervallo fra $-20$ e $20$.} ma per \param{inc} si può specificare
2569 un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare
2570 il risultato nell'intervallo consentito. Valori positivi comportano maggiore
2571 \textit{cortesia} e cioè una diminuzione della priorità, valori negativi
2572 comportano invece un aumento della priorità. Con i kernel precedenti il 2.6.12
2573 solo l'amministratore\footnote{o un processo con la \textit{capability}
2574   \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} può
2575 specificare valori negativi di \param{inc} che permettono di aumentare la
2576 priorità di un processo, a partire da questa versione è consentito anche agli
2577 utenti normali alzare (entro certi limiti, che vedremo in
2578 sez.~\ref{sec:sys_resource_limit}) la priorità dei propri processi.
2579
2580 \constend{PRIO\_MIN}
2581 \constend{PRIO\_MAX}
2582
2583 Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
2584 di \textit{nice} del processo; tuttavia la \textit{system call} di Linux non
2585 segue questa convenzione e restituisce sempre $0$ in caso di successo e $-1$
2586 in caso di errore; questo perché $-1$ è anche un valore di \textit{nice}
2587 legittimo e questo comporta una confusione con una eventuale condizione di
2588 errore. La \textit{system call} originaria inoltre non consente, se non dotati
2589 di adeguati privilegi, di diminuire un valore di \textit{nice} precedentemente
2590 innalzato.
2591  
2592 Fino alla \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
2593 risultato dalla \textit{system call}, violando lo standard, per cui per
2594 ottenere il nuovo valore occorreva una successiva chiamata alla funzione
2595 \func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
2596 reimplementata e non viene più chiamata la omonima \textit{system call}, con
2597 questa versione viene restituito come valore di ritorno il valore di
2598 \textit{nice}, come richiesto dallo standard.\footnote{questo viene fatto
2599   chiamando al suo interno \func{setpriority}, che tratteremo a breve.}  In
2600 questo caso l'unico modo per rilevare in maniera affidabile una condizione di
2601 errore è quello di azzerare \var{errno} prima della chiamata della funzione e
2602 verificarne il valore quando \func{nice} restituisce $-1$.
2603
2604 Per leggere il valore di \textit{nice} di un processo occorre usare la
2605 funzione di sistema \funcd{getpriority}, derivata da BSD; il suo prototipo è:
2606
2607 \begin{funcproto}{ 
2608 \fhead{sys/time.h}
2609 \fhead{sys/resource.h}
2610 \fdecl{int getpriority(int which, int who)}
2611 \fdesc{Legge un valore di \textit{nice}.} 
2612 }
2613 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2614 caso \var{errno} assumerà uno dei valori:
2615 \begin{errlist}
2616 \item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
2617     elencati in tab.~\ref{tab:proc_getpriority}.
2618 \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2619   \param{which} e \param{who}.
2620 \end{errlist}}
2621 \end{funcproto}
2622
2623 La funzione permette, a seconda di quanto specificato
2624 nell'argomento \param{which}, di leggere il valore di \textit{nice} di un
2625 processo, di un gruppo di processi (vedi sez.~\ref{sec:sess_proc_group}) o di
2626 un utente indicato dall'argomento \param{who}. Nelle vecchie versioni può
2627 essere necessario includere anche \headfiled{sys/time.h}, questo non è più
2628 necessario con versioni recenti delle librerie, ma è comunque utile per
2629 portabilità.
2630
2631 I valori possibili per \param{which}, ed il tipo di valore che occorre usare
2632 in corrispondenza per \param{who} solo elencati nella legenda di
2633 tab.~\ref{tab:proc_getpriority} insieme ai relativi significati. Usare un
2634 valore nullo per \param{who} indica, a seconda della corrispondente
2635 indicazione usata per \param{which} il processo, il gruppo di processi o
2636 l'utente correnti.
2637
2638 \begin{table}[htb]
2639   \centering
2640   \footnotesize
2641   \begin{tabular}[c]{|c|c|l|}
2642     \hline
2643     \param{which} & \param{who} & \textbf{Significato} \\
2644     \hline
2645     \hline
2646     \constd{PRIO\_PROCESS} & \type{pid\_t} & processo  \\
2647     \constd{PRIO\_PRGR}    & \type{pid\_t} & \textit{process group} (vedi
2648                                              sez.~\ref{sec:sess_proc_group})\\
2649     \constd{PRIO\_USER}    & \type{uid\_t} & utente \\
2650     \hline
2651   \end{tabular}
2652   \caption{Legenda del valore dell'argomento \param{which} e del tipo
2653     dell'argomento \param{who} delle funzioni \func{getpriority} e
2654     \func{setpriority} per le tre possibili scelte.}
2655   \label{tab:proc_getpriority}
2656 \end{table}
2657
2658 In caso di una indicazione che faccia riferimento a più processi, la funzione
2659 restituisce la priorità più alta (cioè il valore più basso) fra quelle dei
2660 processi corrispondenti. Come per \func{nice} $-1$ è un valore possibile
2661 corretto, per cui di nuovo per poter rilevare una condizione di errore è
2662 necessario cancellare sempre \var{errno} prima della chiamata alla funzione e
2663 quando si ottiene un valore di ritorno uguale a $-1$ per verificare che essa
2664 resti uguale a zero.
2665
2666 Analoga a \func{getpriority} è la funzione di sistema \funcd{setpriority} che
2667 permette di impostare la priorità di uno o più processi; il suo prototipo è:
2668
2669 \begin{funcproto}{ 
2670 \fhead{sys/time.h}
2671 \fhead{sys/resource.h}
2672 \fdecl{int setpriority(int which, int who, int prio)}
2673 \fdesc{Imposta un valore di \textit{nice}.} 
2674 }
2675 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2676 caso \var{errno} assumerà uno dei valori:
2677 \begin{errlist}
2678 \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
2679   sufficienti privilegi.
2680 \item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
2681   elencati in tab.~\ref{tab:proc_getpriority}.
2682 \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
2683   cercato di modificare la priorità di un processo di un altro utente.
2684 \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2685   \param{which} e \param{who}.
2686 \end{errlist}}
2687 \end{funcproto}
2688
2689 La funzione imposta la priorità dinamica al valore specificato da \param{prio}
2690 per tutti i processi indicati dagli argomenti \param{which} e \param{who}, per
2691 i quali valgono le stesse considerazioni fatte per \func{getpriority} e lo
2692 specchietto di tab.~\ref{tab:proc_getpriority}. 
2693
2694 In questo caso come valore di \param{prio} deve essere specificato il valore
2695 di \textit{nice} da assegnare, e non un incremento (positivo o negativo) come
2696 nel caso di \func{nice}, nell'intervallo fra \const{PRIO\_MIN} ($-20$) e
2697 \const{PRIO\_MAX} ($19$). La funzione restituisce il valore di \textit{nice}
2698 assegnato in caso di successo e $-1$ in caso di errore, e come per \func{nice}
2699 anche in questo caso per rilevare un errore occorre sempre porre a zero
2700 \var{errno} prima della chiamata della funzione, essendo $-1$ un valore di
2701 \textit{nice} valido.
2702
2703 Si tenga presente che solo l'amministratore\footnote{o più precisamente un
2704   processo con la \textit{capability} \const{CAP\_SYS\_NICE}, vedi
2705   sez.~\ref{sec:proc_capabilities}.} ha la possibilità di modificare
2706 arbitrariamente le priorità di qualunque processo. Un utente normale infatti
2707 può modificare solo la priorità dei suoi processi ed in genere soltanto
2708 diminuirla.  Fino alla versione di kernel 2.6.12 Linux ha seguito le
2709 specifiche dello standard SUSv3, e come per tutti i sistemi derivati da SysV
2710 veniva richiesto che l'\ids{UID} reale o quello effettivo del processo
2711 chiamante corrispondessero all'\ids{UID} reale (e solo a quello) del processo
2712 di cui si intendeva cambiare la priorità. A partire dalla versione 2.6.12 è
2713 stata adottata la semantica in uso presso i sistemi derivati da BSD (SunOS,
2714 Ultrix, *BSD), in cui la corrispondenza può essere anche con l'\ids{UID}
2715 effettivo.
2716
2717 Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
2718 ordinari poter aumentare la priorità dei propri processi specificando un
2719 valore di \param{prio} negativo. Questa operazione non è possibile però in
2720 maniera indiscriminata, ed in particolare può essere effettuata solo
2721 nell'intervallo consentito dal valore del limite \const{RLIMIT\_NICE}
2722 (torneremo su questo in sez.~\ref{sec:sys_resource_limit}).
2723
2724 Infine nonostante i valori siano sempre rimasti gli stessi, il significato del
2725 valore di \textit{nice} è cambiato parecchio nelle progressive riscritture
2726 dello \textit{scheduler} di Linux, ed in particolare a partire dal kernel
2727 2.6.23 l'uso di diversi valori di \textit{nice} ha un impatto molto più forte
2728 nella distribuzione della CPU ai processi. Infatti se viene comunque calcolata
2729 una priorità dinamica per i processi che non ricevono la CPU così che anche
2730 essi possano essere messi in esecuzione, un alto valore di \textit{nice}
2731 corrisponde comunque ad una \textit{time-slice} molto piccola che non cresce
2732 comunque, per cui un processo a bassa priorità avrà davvero scarse possibilità
2733 di essere eseguito in presenza di processi attivi a priorità più alta.
2734
2735
2736
2737 \subsection{Il meccanismo di \textit{scheduling real-time}}
2738 \label{sec:proc_real_time}
2739
2740 Come spiegato in sez.~\ref{sec:proc_sched} lo standard POSIX.1b ha introdotto
2741 le priorità assolute per permettere la gestione di processi real-time. In
2742 realtà nel caso di Linux non si tratta di un vero \textit{hard real-time}, in
2743 quanto in presenza di eventuali interrupt il kernel interrompe l'esecuzione di
2744 un processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
2745   siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
2746   ottenere un sistema effettivamente \textit{hard real-time}. In tal caso
2747   infatti gli interrupt vengono intercettati dall'interfaccia
2748   \textit{real-time} (o nel caso di Adeos gestiti dalle code del nano-kernel),
2749   in modo da poterli controllare direttamente qualora ci sia la necessità di
2750   avere un processo con priorità più elevata di un \textit{interrupt
2751     handler}.} mentre con l'incorrere in un \textit{page fault} si possono
2752 avere ritardi non previsti.  Se l'ultimo problema può essere aggirato
2753 attraverso l'uso delle funzioni di controllo della memoria virtuale (vedi
2754 sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
2755 ritardi non prevedibili riguardo ai tempi di esecuzione di qualunque processo.
2756
2757 Nonostante questo, ed in particolare con una serie di miglioramenti che sono
2758 stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire
2759   dalla versione 2.6.18 sono stati inserite nel kernel una serie di modifiche
2760   che consentono di avvicinarsi sempre di più ad un vero e proprio sistema
2761   \textit{real-time} estendendo il concetto di \textit{preemption} alle
2762   operazioni dello stesso kernel; esistono vari livelli a cui questo può
2763   essere fatto, ottenibili attivando in fase di compilazione una fra le
2764   opzioni \texttt{CONFIG\_PREEMPT\_NONE}, \texttt{CONFIG\_PREEMPT\_VOLUNTARY}
2765   e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima
2766 approssimazione di sistema \textit{real-time} usando le priorità assolute.
2767 Occorre farlo però con molta attenzione: se si dà ad un processo una priorità
2768 assoluta e questo finisce in un loop infinito, nessun altro processo potrà
2769 essere eseguito, ed esso sarà mantenuto in esecuzione permanentemente
2770 assorbendo tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
2771 sistema. Per questo motivo è sempre opportuno, quando si lavora con processi
2772 che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
2773 massima priorità assoluta, in modo da poter essere comunque in grado di
2774 rientrare nel sistema.
2775
2776 Quando c'è un processo con priorità assoluta lo \textit{scheduler} lo metterà
2777 in esecuzione prima di ogni processo normale. In caso di più processi sarà
2778 eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
2779 processi con la stessa priorità assoluta questi vengono tenuti in una coda e
2780 tocca al kernel decidere quale deve essere eseguito.  Il meccanismo con cui
2781 vengono gestiti questi processi dipende dalla politica di \textit{scheduling}
2782 che si è scelta; lo standard ne prevede due:
2783 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
2784 \item[\textit{First In First Out} (FIFO)] Il processo viene eseguito
2785   fintanto che non cede volontariamente la CPU (con la funzione
2786   \func{sched\_yield}), si blocca, finisce o viene interrotto da un processo a
2787   priorità più alta. Se il processo viene interrotto da uno a priorità più
2788   alta esso resterà in cima alla lista e sarà il primo ad essere eseguito
2789   quando i processi a priorità più alta diverranno inattivi. Se invece lo si
2790   blocca volontariamente sarà posto in coda alla lista (ed altri processi con
2791   la stessa priorità potranno essere eseguiti).
2792 \item[\textit{Round Robin} (RR)] Il comportamento è del tutto analogo a quello
2793   precedente, con la sola differenza che ciascun processo viene eseguito al
2794   massimo per un certo periodo di tempo (la cosiddetta \textit{time-slice})
2795   dopo di che viene automaticamente posto in fondo alla coda dei processi con
2796   la stessa priorità. In questo modo si ha comunque una esecuzione a turno di
2797   tutti i processi, da cui il nome della politica. Solo i processi con la
2798   stessa priorità ed in stato \textit{runnable} entrano nel
2799   \textsl{girotondo}.
2800 \end{basedescript}
2801
2802 Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare
2803 le politiche di \textit{scheduling}, passando da \textit{real-time} a
2804 ordinarie o viceversa, che di specificare, in caso di politiche
2805 \textit{real-time}, la eventuale priorità statica; la funzione di sistema è
2806 \funcd{sched\_setscheduler} ed il suo prototipo è:
2807
2808 \begin{funcproto}{ 
2809 \fhead{sched.h}
2810 \fdecl{int sched\_setscheduler(pid\_t pid, int policy, const struct
2811   sched\_param *p)}
2812 \fdesc{Imposta priorità e politica di \textit{scheduling}.} 
2813 }
2814 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2815 caso \var{errno} assumerà uno dei valori:
2816 \begin{errlist}
2817     \item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il
2818       relativo valore di \param{p} non è valido per la politica scelta.
2819     \item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
2820       politica richiesta.
2821     \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2822  \end{errlist}}
2823 \end{funcproto}
2824
2825 La funzione esegue l'impostazione per il processo specificato dall'argomento
2826 \param{pid}, un valore nullo di questo argomento esegue l'impostazione per il
2827 processo corrente.  La politica di \textit{scheduling} è specificata
2828 dall'argomento \param{policy} i cui possibili valori sono riportati in
2829 tab.~\ref{tab:proc_sched_policy}; la parte alta della tabella indica le
2830 politiche \textit{real-time}, quella bassa le politiche ordinarie. Un valore
2831 negativo per \param{policy} mantiene la politica di \textit{scheduling}
2832 corrente.
2833
2834 \begin{table}[htb]
2835   \centering
2836   \footnotesize
2837   \begin{tabular}[c]{|l|p{6cm}|}
2838     \hline
2839     \textbf{Politica}  & \textbf{Significato} \\
2840     \hline
2841     \hline
2842     \constd{SCHED\_FIFO} & \textit{Scheduling real-time} con politica
2843                            \textit{FIFO}. \\
2844     \constd{SCHED\_RR}   & \textit{Scheduling real-time} con politica
2845                            \textit{Round Robin}. \\ 
2846     \hline
2847     \constd{SCHED\_OTHER}& \textit{Scheduling} ordinario.\\
2848     \constd{SCHED\_BATCH}& \textit{Scheduling} ordinario con l'assunzione
2849                            ulteriore di lavoro \textit{CPU
2850                            intensive} (dal kernel 2.6.16).\\ 
2851     \constd{SCHED\_IDLE} & \textit{Scheduling} di priorità estremamente
2852                            bassa (dal kernel 2.6.23).\\
2853     \hline
2854   \end{tabular}
2855   \caption{Valori dell'argomento \param{policy} per la funzione
2856     \func{sched\_setscheduler}.}
2857   \label{tab:proc_sched_policy}
2858 \end{table}
2859
2860 % TODO Aggiungere SCHED_DEADLINE, sulla nuova politica di scheduling aggiunta
2861 % con il kernel 3.14, vedi anche Documentation/scheduler/sched-deadline.txt e
2862 % http://lwn.net/Articles/575497/
2863
2864 Con le versioni più recenti del kernel sono state introdotte anche delle
2865 varianti sulla politica di \textit{scheduling} tradizionale per alcuni carichi
2866 di lavoro specifici, queste due nuove politiche sono specifiche di Linux e non
2867 devono essere usate se si vogliono scrivere programmi portabili.
2868
2869 La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
2870 la sola differenza che i processi ad essa soggetti non ottengono, nel calcolo
2871 delle priorità dinamiche fatto dallo \textit{scheduler}, il cosiddetto bonus
2872 di interattività che mira a favorire i processi che si svegliano dallo stato
2873 di \textit{sleep}.\footnote{cosa che accade con grande frequenza per i
2874   processi interattivi, dato che essi sono per la maggior parte del tempo in
2875   attesa di dati in ingresso da parte dell'utente.} La si usa pertanto, come
2876 indica il nome, per processi che usano molta CPU (come programmi di calcolo)
2877 che in questo modo sono leggermente sfavoriti rispetto ai processi interattivi
2878 che devono rispondere a dei dati in ingresso, pur non perdendo il loro valore
2879 di \textit{nice}.
2880
2881 La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
2882 si desidera siano eseguiti con la più bassa priorità possibile, ancora più
2883 bassa di un processo con il minimo valore di \textit{nice}. In sostanza la si
2884 può utilizzare per processi che devono essere eseguiti se non c'è niente altro
2885 da fare. Va comunque sottolineato che anche un processo \const{SCHED\_IDLE}
2886 avrà comunque una sua possibilità di utilizzo della CPU, sia pure in
2887 percentuale molto bassa.
2888
2889 Qualora si sia richiesta una politica \textit{real-time} il valore della
2890 priorità statica viene impostato attraverso la struttura
2891 \struct{sched\_param}, riportata in fig.~\ref{fig:sig_sched_param}, il cui
2892 solo campo attualmente definito è \var{sched\_priority}. Il campo deve
2893 contenere il valore della priorità statica da assegnare al processo; lo
2894 standard prevede che questo debba essere assegnato all'interno di un
2895 intervallo fra un massimo ed un minimo che nel caso di Linux sono
2896 rispettivamente 1 e 99.
2897
2898 \begin{figure}[!htbp]
2899   \footnotesize \centering
2900   \begin{minipage}[c]{0.5\textwidth}
2901     \includestruct{listati/sched_param.c}
2902   \end{minipage} 
2903   \normalsize 
2904   \caption{La struttura \structd{sched\_param}.} 
2905   \label{fig:sig_sched_param}
2906 \end{figure}
2907
2908 I processi con politica di \textit{scheduling} ordinaria devono sempre
2909 specificare un valore nullo di \var{sched\_priority} altrimenti si avrà un
2910 errore \errcode{EINVAL}, questo valore infatti non ha niente a che vedere con
2911 la priorità dinamica determinata dal valore di \textit{nice}, che deve essere
2912 impostato con le funzioni viste in precedenza.
2913
2914 Lo standard POSIX.1b prevede che l'intervallo dei valori delle priorità
2915 statiche possa essere ottenuto con le funzioni di sistema
2916 \funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
2917 prototipi sono:
2918
2919 \begin{funcproto}{ 
2920 \fhead{sched.h}
2921 \fdecl{int sched\_get\_priority\_max(int policy)}
2922 \fdesc{Legge il valore massimo di una priorità statica.} 
2923 \fdecl{int sched\_get\_priority\_min(int policy)}
2924 \fdesc{Legge il valore minimo di una priorità statica.} 
2925 }
2926 {Le funzioni ritornano il valore della priorità in caso di successo e $-1$ per
2927   un errore, nel qual caso \var{errno} assumerà il valore:
2928 \begin{errlist}
2929 \item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
2930 \end{errlist}}
2931 \end{funcproto}
2932
2933 Le funzioni ritornano rispettivamente i due valori della massima e minima
2934 priorità statica possano essere ottenuti per una delle politiche di
2935 \textit{scheduling} \textit{real-time} indicata dall'argomento \param{policy}.
2936
2937 Si tenga presente che quando si imposta una politica di \textit{scheduling}
2938 real-time per un processo o se ne cambia la priorità statica questo viene
2939 messo in cima alla lista dei processi con la stessa priorità; questo comporta
2940 che verrà eseguito subito, interrompendo eventuali altri processi con la
2941 stessa priorità in quel momento in esecuzione.
2942
2943 Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
2944 esegue sempre il primo della lista, mentre un nuovo processo che torna in
2945 stato \textit{runnable} viene sempre inserito in coda alla lista. Se la
2946 politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
2947 automaticamente rimesso in coda alla lista, e la sua esecuzione continua
2948 fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
2949 volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
2950 sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
2951 nel caso che esso sia stato interrotto da un processo a priorità più alta.
2952
2953 Solo un processo con i privilegi di amministratore\footnote{più precisamente
2954   con la capacità \const{CAP\_SYS\_NICE}, vedi
2955   sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
2956 assolute diverse da zero o politiche \const{SCHED\_FIFO} e
2957 \const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
2958 processi che gli appartengono; è cioè richiesto che l'\ids{UID} effettivo del
2959 processo chiamante corrisponda all'\ids{UID} reale o effettivo del processo
2960 indicato con \param{pid}.
2961
2962 Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche
2963 \textit{real-time} o modificare la eventuale priorità statica di un loro
2964 processo. A partire da questa versione è divenuto possibile anche per gli
2965 utenti normali usare politiche \textit{real-time} fintanto che la priorità
2966 assoluta che si vuole impostare è inferiore al limite \const{RLIMIT\_RTPRIO}
2967 (vedi sez.~\ref{sec:sys_resource_limit}) ad essi assegnato. 
2968
2969 Unica eccezione a questa possibilità sono i processi \const{SCHED\_IDLE}, che
2970 non possono cambiare politica di \textit{scheduling} indipendentemente dal
2971 valore di \const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto
2972 ad una politica \textit{real-time}, un utente può sempre, indipendentemente
2973 dal valore di \const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una
2974 politica ordinaria.
2975
2976 Se si intende operare solo sulla priorità statica di un processo si possono
2977 usare le due funzioni di sistema \funcd{sched\_setparam} e
2978 \funcd{sched\_getparam} che consentono rispettivamente di impostarne e
2979 leggerne il valore, i loro prototipi sono:
2980
2981 \begin{funcproto}{
2982 \fhead{sched.h}
2983 \fdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *param)}
2984 \fdesc{Imposta la priorità statica di un processo.} 
2985 \fdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)}
2986 \fdesc{Legge la priorità statica di un processo.} 
2987 }
2988 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2989 caso \var{errno} assumerà uno dei valori:
2990 \begin{errlist}
2991 \item[\errcode{EINVAL}] il valore di \param{param} non ha senso per la
2992   politica usata dal processo.
2993 \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
2994   l'operazione.
2995 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2996 \end{errlist}}
2997 \end{funcproto}
2998
2999 Le funzioni richiedono di indicare nell'argomento \param{pid} il processo su
3000 cui operare e usano l'argomento \param{param} per mantenere il valore della
3001 priorità dinamica. Questo è ancora una struttura \struct{sched\_param} ed
3002 assume gli stessi valori già visti per \func{sched\_setscheduler}.
3003
3004 L'uso di \func{sched\_setparam}, compresi i controlli di accesso che vi si
3005 applicano, è del tutto equivalente a quello di \func{sched\_setscheduler} con
3006 argomento \param{policy} uguale a $-1$. Come per \func{sched\_setscheduler}
3007 specificando $0$ come valore dell'argomento \param{pid} si opera sul processo
3008 corrente. Benché la funzione sia utilizzabile anche con processi sottoposti a
3009 politica ordinaria essa ha senso soltanto per quelli \textit{real-time}, dato
3010 che per i primi la priorità statica può essere soltanto nulla.  La
3011 disponibilità di entrambe le funzioni può essere verificata controllando la
3012 macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'\textit{header
3013   file} \headfiled{sched.h}.
3014
3015 Se invece si vuole sapere quale è politica di \textit{scheduling} di un
3016 processo si può usare la funzione di sistema \funcd{sched\_getscheduler}, il
3017 cui prototipo è:
3018
3019 \begin{funcproto}{ 
3020 \fhead{sched.h}
3021 \fdecl{int sched\_getscheduler(pid\_t pid)}
3022 \fdesc{Legge la politica di \textit{scheduling}.} 
3023 }
3024 {La funzione ritorna la politica di \textit{scheduling}  in caso di successo e
3025   $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
3026 \begin{errlist}
3027     \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
3028       l'operazione.
3029     \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3030 \end{errlist}}
3031 \end{funcproto}
3032
3033 La funzione restituisce il valore, secondo quanto elencato in
3034 tab.~\ref{tab:proc_sched_policy}, della politica di \textit{scheduling} per il
3035 processo specificato dall'argomento \param{pid}, se questo è nullo viene
3036 restituito il valore relativo al processo chiamante.
3037
3038 L'ultima funzione di sistema che permette di leggere le informazioni relative
3039 ai processi real-time è \funcd{sched\_rr\_get\_interval}, che permette di
3040 ottenere la lunghezza della \textit{time-slice} usata dalla politica
3041 \textit{round robin}; il suo prototipo è:
3042
3043 \begin{funcproto}{ 
3044 \fhead{sched.h}
3045 \fdecl{int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)}
3046 \fdesc{Legge la durata della \textit{time-slice} per lo \textit{scheduling}
3047   \textit{round robin}.}  
3048 }
3049 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
3050 caso \var{errno} assumerà uno dei valori:
3051 \begin{errlist}
3052 \item[\errcode{EINVAL}] l'argomento \param{pid} non è valido. 
3053 \item[\errcode{ENOSYS}] la \textit{system call} non è presente (solo per
3054   kernel arcaici).
3055 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3056 \end{errlist}
3057 ed inoltre anche \errval{EFAULT} nel suo significato generico.}
3058 \end{funcproto}
3059
3060 La funzione restituisce nell'argomento \param{tp} come una struttura
3061 \struct{timespec}, (la cui definizione si può trovare in
3062 fig.~\ref{fig:sys_timeval_struct}) il valore dell'intervallo di tempo usato
3063 per la politica \textit{round robin} dal processo indicato da \ids{PID}. Il
3064 valore dipende dalla versione del kernel, a lungo infatti questo intervallo di
3065 tempo era prefissato e non modificabile ad un valore di 150 millisecondi,
3066 restituito indipendentemente dal \ids{PID} indicato. 
3067
3068 Con kernel recenti però è possibile ottenere una variazione della
3069 \textit{time-slice}, modificando il valore di \textit{nice} del processo
3070 (anche se questo non incide assolutamente sulla priorità statica) che come
3071 accennato in precedenza modifica il valore assegnato alla \textit{time-slice}
3072 di un processo ordinario, che però viene usato anche dai processi
3073 \textit{real-time}.
3074
3075 Come accennato ogni processo può rilasciare volontariamente la CPU in modo da
3076 consentire agli altri processi di essere eseguiti; la funzione di sistema che
3077 consente di fare tutto questo è \funcd{sched\_yield}, il cui prototipo è:
3078
3079 \begin{funcproto}{ 
3080 \fhead{sched.h}
3081 \fdecl{int sched\_yield(void)}
3082 \fdesc{Rilascia volontariamente l'esecuzione.} 
3083 }
3084 {La funzione ritorna $0$ in caso di successo e teoricamente $-1$ per un
3085   errore, ma su Linux ha sempre successo.}
3086 \end{funcproto}
3087
3088
3089 Questa funzione ha un utilizzo effettivo soltanto quando si usa lo
3090 \textit{scheduling} \textit{real-time}, e serve a far sì che il processo
3091 corrente rilasci la CPU, in modo da essere rimesso in coda alla lista dei
3092 processi con la stessa priorità per permettere ad un altro di essere eseguito;
3093 se però il processo è l'unico ad essere presente sulla coda l'esecuzione non
3094 sarà interrotta. In genere usano questa funzione i processi con politica
3095 \const{SCHED\_FIFO}, per permettere l'esecuzione degli altri processi con pari
3096 priorità quando la sezione più urgente è finita.
3097
3098 La funzione può essere utilizzata anche con processi che usano lo
3099 \textit{scheduling} ordinario, ma in questo caso il comportamento non è ben
3100 definito, e dipende dall'implementazione. Fino al kernel 2.6.23 questo
3101 comportava che i processi venissero messi in fondo alla coda di quelli attivi,
3102 con la possibilità di essere rimessi in esecuzione entro breve tempo, con
3103 l'introduzione del \textit{Completely Fair Scheduler} questo comportamento è
3104 cambiato ed un processo che chiama la funzione viene inserito nella lista dei
3105 processi inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
3106   ripristinare un comportamento analogo al precedente scrivendo il valore 1
3107   nel file \sysctlfiled{kernel/sched\_compat\_yield}.}
3108
3109 L'uso delle funzione nella programmazione ordinaria può essere utile e
3110 migliorare le prestazioni generali del sistema quando si è appena rilasciata
3111 una risorsa contesa con altri processi, e si vuole dare agli altri una
3112 possibilità di approfittarne mettendoli in esecuzione, ma chiamarla senza
3113 necessità, specie se questo avviene ripetutamente all'interno di un qualche
3114 ciclo, può avere invece un forte impatto negativo per la generazione di
3115 \textit{context switch} inutili.
3116
3117
3118 \subsection{Il controllo dello \textit{scheduler} per i sistemi
3119   multiprocessore}
3120 \label{sec:proc_sched_multiprocess}
3121
3122 \index{effetto~ping-pong|(} 
3123
3124 Con il supporto dei sistemi multiprocessore sono state introdotte delle
3125 funzioni che permettono di controllare in maniera più dettagliata la scelta di
3126 quale processore utilizzare per eseguire un certo programma. Uno dei problemi
3127 che si pongono nei sistemi multiprocessore è infatti quello del cosiddetto
3128 \textsl{effetto ping-pong}. Può accadere cioè che lo \textit{scheduler},
3129 quando riavvia un processo precedentemente interrotto scegliendo il primo
3130 processore disponibile, lo faccia eseguire da un processore diverso rispetto a
3131 quello su cui era stato eseguito in precedenza. Se il processo passa da un
3132 processore all'altro in questo modo, cosa che avveniva abbastanza di frequente
3133 con i kernel della seria 2.4.x, si ha l'effetto ping-pong.
3134
3135 Questo tipo di comportamento può generare dei seri problemi di prestazioni;
3136 infatti tutti i processori moderni utilizzano una memoria interna (la
3137 \textit{cache}) contenente i dati più usati, che permette di evitare di
3138 eseguire un accesso (molto più lento) alla memoria principale sulla scheda
3139 madre.  Chiaramente un processo sarà favorito se i suoi dati sono nella cache
3140 del processore, ma è ovvio che questo può essere vero solo per un processore
3141 alla volta, perché in presenza di più copie degli stessi dati su più
3142 processori, non si potrebbe determinare quale di questi ha la versione dei
3143 dati aggiornata rispetto alla memoria principale.
3144
3145 Questo comporta che quando un processore inserisce un dato nella sua cache,
3146 tutti gli altri processori che hanno lo stesso dato devono invalidarlo, e
3147 questa operazione è molto costosa in termini di prestazioni. Il problema
3148 diventa serio quando si verifica l'effetto ping-pong, in tal caso infatti un
3149 processo \textsl{rimbalza} continuamente da un processore all'altro e si ha
3150 una continua invalidazione della cache, che non diventa mai disponibile.
3151
3152 \itindbeg{CPU~affinity}
3153
3154 Per ovviare a questo tipo di problemi è nato il concetto di \textsl{affinità
3155   di processore} (o \textit{CPU affinity}); la possibilità cioè di far sì che
3156 un processo possa essere assegnato per l'esecuzione sempre allo stesso
3157 processore. Lo \textit{scheduler} dei kernel della serie 2.4.x aveva una
3158 scarsa \textit{CPU affinity}, e l'effetto ping-pong era comune; con il nuovo
3159 \textit{scheduler} dei kernel della 2.6.x questo problema è stato risolto ed
3160 esso cerca di mantenere il più possibile ciascun processo sullo stesso
3161 processore.
3162
3163 \index{effetto~ping-pong|)}
3164
3165 In certi casi però resta l'esigenza di poter essere sicuri che un processo sia
3166 sempre eseguito dallo stesso processore,\footnote{quella che viene detta
3167   \textit{hard CPU affinity}, in contrasto con quella fornita dallo
3168   \textit{scheduler}, detta \textit{soft CPU affinity}, che di norma indica
3169   solo una preferenza, non un requisito assoluto.} e per poter risolvere
3170 questo tipo di problematiche nei nuovi kernel\footnote{le due \textit{system
3171     call} per la gestione della \textit{CPU affinity} sono state introdotte
3172   nel kernel 2.5.8, e le corrispondenti funzioni di sistema nella
3173   \textsl{glibc} 2.3.} è stata introdotta l'opportuna infrastruttura ed una
3174 nuova \textit{system call} che permette di impostare su quali processori far
3175 eseguire un determinato processo attraverso una \textsl{maschera di
3176   affinità}. La corrispondente funzione di sistema è
3177 \funcd{sched\_setaffinity} ed il suo prototipo è:
3178
3179 \index{insieme~di~processori|(}
3180
3181 \begin{funcproto}{ 
3182 \fhead{sched.h}
3183 \fdecl{int sched\_setaffinity(pid\_t pid, size\_t setsize, 
3184   cpu\_set\_t *mask)}
3185 \fdesc{Imposta la maschera di affinità di un processo.} 
3186 }
3187 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
3188 caso \var{errno} assumerà uno dei valori:
3189 \begin{errlist}
3190 \item[\errcode{EINVAL}] il valore di \param{mask} contiene riferimenti a
3191   processori non esistenti nel sistema o a cui non è consentito l'accesso.
3192 \item[\errcode{EPERM}] il processo non ha i privilegi sufficienti per
3193   eseguire l'operazione.
3194 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3195 \end{errlist}
3196 ed inoltre anche \errval{EFAULT} nel suo significato generico.}
3197 \end{funcproto}
3198
3199 Questa funzione e la corrispondente \func{sched\_getaffinity} hanno una storia
3200 abbastanza complessa, la sottostante \textit{system call} infatti prevede
3201 l'uso di due soli argomenti (per il pid e l'indicazione della maschera dei
3202 processori), che corrispondono al fatto che l'implementazione effettiva usa
3203 una semplice maschera binaria. Quando le funzioni vennero incluse nella
3204 \acr{glibc} assunsero invece un prototipo simile a quello mostrato però con il
3205 secondo argomento di tipo \ctyp{unsigned int}. A complicare la cosa si
3206 aggiunge il fatto che nella versione 2.3.3 della \acr{glibc} detto argomento
3207 venne stato eliminato, per poi essere ripristinato nella versione 2.3.4 nella
3208 forma attuale.\footnote{pertanto se la vostra pagina di manuale non è
3209   aggiornata, o usate quella particolare versione della \acr{glibc}, potrete
3210   trovare indicazioni diverse, il prototipo illustrato è quello riportato
3211   nella versione corrente (maggio 2008) delle pagine di manuale e
3212   corrispondente alla definizione presente in \headfile{sched.h}.}
3213
3214 La funzione imposta, con l'uso del valore contenuto all'indirizzo
3215 \param{mask}, l'insieme dei processori sui quali deve essere eseguito il
3216 processo identificato tramite il valore passato in \param{pid}. Come in
3217 precedenza il valore nullo di \param{pid} indica il processo corrente.  Per
3218 poter utilizzare questa funzione sono richiesti i privilegi di amministratore
3219 (è necessaria la capacità \const{CAP\_SYS\_NICE}) altrimenti essa fallirà con
3220 un errore di \errcode{EPERM}. Una volta impostata una maschera di affinità,
3221 questa viene ereditata attraverso una \func{fork}, in questo modo diventa
3222 possibile legare automaticamente un gruppo di processi ad un singolo
3223 processore.
3224
3225 Nell'uso comune, almeno con i kernel successivi alla serie 2.6.x, l'uso di
3226 questa funzione non è necessario, in quanto è lo \textit{scheduler} stesso che
3227 provvede a mantenere al meglio l'affinità di processore. Esistono però
3228 esigenze particolari, ad esempio quando un processo (o un gruppo di processi)
3229 è utilizzato per un compito importante (ad esempio per applicazioni
3230 \textit{real-time} o la cui risposta è critica) e si vuole la massima
3231 velocità, e con questa interfaccia diventa possibile selezionare gruppi di
3232 processori utilizzabili in maniera esclusiva.  Lo stesso dicasi quando
3233 l'accesso a certe risorse (memoria o periferiche) può avere un costo diverso a
3234 seconda del processore, come avviene nelle architetture NUMA
3235 (\textit{Non-Uniform Memory Access}).
3236
3237 Infine se un gruppo di processi accede alle stesse risorse condivise (ad
3238 esempio una applicazione con più \textit{thread}) può avere senso usare lo
3239 stesso processore in modo da sfruttare meglio l'uso della sua cache; questo
3240 ovviamente riduce i benefici di un sistema multiprocessore nell'esecuzione
3241 contemporanea dei \textit{thread}, ma in certi casi (quando i \textit{thread}
3242 sono inerentemente serializzati nell'accesso ad una risorsa) possono esserci
3243 sufficienti vantaggi nell'evitare la perdita della cache da rendere
3244 conveniente l'uso dell'affinità di processore.
3245
3246 Dato che il numero di processori può variare a seconda delle architetture, per
3247 semplificare l'uso dell'argomento \param{mask} la \acr{glibc} ha introdotto un
3248 apposito dato di tipo, \typed{cpu\_set\_t},\footnote{questa è una estensione
3249   specifica della \acr{glibc}, da attivare definendo la macro
3250   \macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per questo
3251   tipo di interfaccia e POSIX al momento non prevede nulla al riguardo.} che
3252 permette di identificare un insieme di processori. Il dato è normalmente una
3253 maschera binaria: nei casi più comuni potrebbe bastare un intero a 32 bit, in
3254 cui ogni bit corrisponde ad un processore, ma oggi esistono architetture in
3255 cui questo numero può non essere sufficiente, e per questo è stato creato
3256 questo tipo opaco e una interfaccia di gestione che permette di usare a basso
3257 livello un tipo di dato qualunque rendendosi indipendenti dal numero di bit e
3258 dalla loro disposizione.  Per questo le funzioni richiedono anche che oltre
3259 all'insieme di processori si indichi anche la dimensione dello stesso con
3260 l'argomento \param{setsize}, per il quale, se non si usa l'allocazione
3261 dinamica che vedremo a breve, ed è in genere sufficiente passare il valore
3262 \code{sizeof(cpu\_set\_t)}.
3263
3264 L'interfaccia di gestione degli insiemi di processori, oltre alla definizione
3265 del tipo \type{cpu\_set\_t}, prevede una serie di macro di preprocessore per
3266 la manipolazione degli stessi. Quelle di base, che consentono rispettivamente
3267 di svuotare un insieme, di aggiungere o togliere un processore o di verificare
3268 se esso è già presente in un insieme, sono le seguenti:
3269
3270 {\centering
3271 \vspace{3pt}
3272 \begin{funcbox}{ 
3273 \fhead{sched.h}
3274 \fdecl{void \macrod{CPU\_ZERO}(cpu\_set\_t *set)}
3275 \fdesc{Inizializza un insieme di processori vuoto \param{set}.} 
3276 \fdecl{void \macrod{CPU\_SET}(int cpu, cpu\_set\_t *set)}
3277 \fdesc{Inserisce il processore \param{cpu} nell'insieme di
3278   processori \param{set}.}  
3279 \fdecl{void \macrod{CPU\_CLR}(int cpu, cpu\_set\_t *set)}
3280 \fdesc{Rimuove il processore \param{cpu} nell'insieme di
3281   processori \param{set}.}  
3282 \fdecl{int \macrod{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
3283 \fdesc{Controlla se il processore \param{cpu} è nell'insieme di
3284   processori \param{set}.}  
3285 }
3286 \end{funcbox}}
3287
3288 Queste macro che sono ispirate dalle analoghe usate per gli insiemi di
3289 \textit{file descriptor} (vedi sez.~\ref{sec:file_select}) e sono state
3290 introdotte con la versione 2.3.3 della \acr{glibc}. Tutte richiedono che si
3291 specifichi il numero di una CPU nell'argomento \param{cpu}, ed un insieme su
3292 cui operare. L'unica che ritorna un risultato è \macro{CPU\_ISSET}, che
3293 restituisce un intero da usare come valore logico (zero se la CPU non è
3294 presente, diverso da zero se è presente).
3295
3296 \itindbeg{side~effects}
3297 Si tenga presente che trattandosi di macro l'argomento \param{cpu} può essere
3298 valutato più volte. Questo significa ad esempio che non si può usare al suo
3299 posto una funzione o un'altra macro, altrimenti queste verrebbero eseguite più
3300 volte, l'argomento cioè non deve avere \textsl{effetti collaterali} (in gergo
3301  \textit{side effects}).\footnote{nel linguaggio C si
3302   parla appunto di \textit{side effects} quando si usano istruzioni la cui
3303   valutazione comporta effetti al di fuori dell'istruzione stessa, come il
3304   caso indicato in cui si passa una funzione ad una macro che usa l'argomento
3305   al suo interno più volte, o si scrivono espressioni come \code{a=a++} in cui
3306   non è chiaro se prima avvenga l'incremento e poi l'assegnazione, ed il cui
3307   risultato dipende dall'implementazione del compilatore.}
3308 \itindend{side~effects}
3309
3310
3311 Le CPU sono numerate da zero (che indica la prima disponibile) fino ad
3312 un numero massimo che dipende dalla architettura hardware. La costante
3313 \constd{CPU\_SETSIZE} indica il numero massimo di processori che possono far
3314 parte di un insieme (al momento vale sempre 1024), e costituisce un limite
3315 massimo al valore dell'argomento \param{cpu}.
3316 Dalla versione 2.6 della \acr{glibc} alle precedenti macro è stata aggiunta,
3317 per contare il numero di processori in un insieme, l'ulteriore:
3318
3319 {\centering
3320 \vspace{3pt}
3321 \begin{funcbox}{ 
3322 \fhead{sched.h}
3323 \fdecl{int \macrod{CPU\_COUNT}(cpu\_set\_t *set)}
3324 \fdesc{Conta il numero di processori presenti nell'insieme \param{set}.} 
3325 }
3326 \end{funcbox}}
3327
3328 A partire dalla versione 2.7 della \acr{glibc} sono state introdotte altre
3329 macro che consentono ulteriori manipolazioni, in particolare si possono
3330 compiere delle operazioni logiche sugli insiemi di processori con:
3331
3332 {\centering
3333 \vspace{3pt}
3334 \begin{funcbox}{ 
3335 \fhead{sched.h}
3336 \fdecl{void \macrod{CPU\_AND}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
3337 \fdesc{Esegue l'AND logico di due insiemi di processori.} 
3338 \fdecl{void \macrod{CPU\_OR}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
3339 \fdesc{Esegue l'OR logico di due insiemi di processori.} 
3340 \fdecl{void \macrod{CPU\_XOR}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
3341 \fdesc{Esegue lo XOR logico di due insiemi di processori.} 
3342 \fdecl{int \macrod{CPU\_EQUAL}(cpu\_set\_t *set1, cpu\_set\_t *set2)}
3343 \fdesc{Verifica se due insiemi di processori sono uguali.} 
3344 }
3345 \end{funcbox}}
3346
3347 Le prime tre macro richiedono due insiemi di partenza, \param{srcset1}
3348 e \param{srcset2} e forniscono in un terzo insieme \param{destset} (che può
3349 essere anche lo stesso di uno dei precedenti) il risultato della rispettiva
3350 operazione logica sui contenuti degli stessi. In sostanza con \macro{CPU\_AND}
3351 si otterrà come risultato l'insieme che contiene le CPU presenti in entrambi
3352 gli insiemi di partenza, con \macro{CPU\_OR} l'insieme che contiene le CPU
3353 presenti in uno qualunque dei due insiemi di partenza, e con \macro{CPU\_XOR}
3354 l'insieme che contiene le CPU presenti presenti in uno solo dei due insiemi di
3355 partenza. Infine \macro{CPU\_EQUAL} confronta due insiemi ed è l'unica che
3356 restituisce un intero, da usare come valore logico che indica se sono
3357 identici o meno.
3358
3359 Inoltre, sempre a partire dalla versione 2.7 della \acr{glibc}, è stata
3360 introdotta la possibilità di una allocazione dinamica degli insiemi di
3361 processori, per poterli avere di dimensioni corrispondenti al numero di CPU
3362 effettivamente in gioco, senza dover fare riferimento necessariamente alla
3363 precedente dimensione preimpostata di 1024. Per questo motivo sono state
3364 definite tre ulteriori macro, che consentono rispettivamente di allocare,
3365 disallocare ed ottenere la dimensione in byte di un insieme di processori:
3366
3367 {\centering
3368 \vspace{3pt}
3369 \begin{funcbox}{ 
3370 \fhead{sched.h}
3371 \fdecl{cpu\_set\_t * \macrod{CPU\_ALLOC}(num\_cpus)}
3372 \fdesc{Alloca dinamicamente un insieme di processori di dimensione voluta.} 
3373 \fdecl{void \macrod{CPU\_FREE}(cpu\_set\_t *set)}
3374 \fdesc{Disalloca un insieme di processori allocato dinamicamente.} 
3375 \fdecl{size\_t \macrod{CPU\_ALLOC\_SIZE}(num\_cpus)}
3376 \fdesc{Ritorna la dimensione di un insieme di processori allocato dinamicamente.} 
3377 }
3378 \end{funcbox}}
3379
3380 La prima macro, \macro{CPU\_ALLOC}, restituisce il puntatore ad un insieme di
3381 processori in grado di contenere almeno \param{num\_cpus} che viene allocato
3382 dinamicamente. Ogni insieme così allocato dovrà essere disallocato con
3383 \macro{CPU\_FREE} passandogli un puntatore ottenuto da una precedente
3384 \macro{CPU\_ALLOC}. La terza macro, \macro{CPU\_ALLOC\_SIZE}, consente di
3385 ottenere la dimensione in byte di un insieme allocato dinamicamente che
3386 contenga \param{num\_cpus} processori.
3387
3388 Dato che le dimensioni effettive possono essere diverse le macro di gestione e
3389 manipolazione che abbiamo trattato in precedenza non si applicano agli insiemi
3390 allocati dinamicamente, per i quali dovranno sono state definite altrettante
3391 macro equivalenti contraddistinte dal suffisso \texttt{\_S}, che effettuano le
3392 stesse operazioni, ma richiedono in più un argomento
3393 aggiuntivo \param{setsize} che deve essere assegnato al valore ottenuto con
3394 \macro{CPU\_ALLOC\_SIZE}. Questo stesso valore deve essere usato per l'omonimo
3395 argomento delle funzioni \func{sched\_setaffinity} o \func{sched\_getaffinity}
3396 quando si vuole usare per l'argomento che indica la maschera di affinità un
3397 insieme di processori allocato dinamicamente.
3398
3399 \index{insieme~di~processori|)}
3400
3401 A meno di non aver utilizzato \func{sched\_setaffinity}, in condizioni
3402 ordinarie la maschera di affinità di un processo è preimpostata dal sistema in
3403 modo che esso possa essere eseguito su qualunque processore. Se ne può
3404 comunque ottenere il valore corrente usando la funzione di sistema
3405 \funcd{sched\_getaffinity}, il cui prototipo è:
3406
3407 \begin{funcproto}{ 
3408 \fhead{sched.h}
3409 \fdecl{int sched\_getaffinity (pid\_t pid, size\_t setsize, 
3410   cpu\_set\_t *mask)}
3411 \fdesc{Legge la maschera di affinità di un processo.} 
3412 }
3413 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
3414 caso \var{errno} assumerà uno dei valori:
3415 \begin{errlist}
3416 \item[\errcode{EINVAL}] \param{setsize} è più piccolo delle dimensioni
3417   della maschera di affinità usata dal kernel.
3418 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3419 \end{errlist}
3420 ed inoltre anche \errval{EFAULT} nel suo significato generico.}
3421 \end{funcproto}
3422
3423 La funzione restituirà all'indirizzo specificato da \param{mask} il valore
3424 della maschera di affinità del processo indicato dall'argomento \param{pid}
3425 (al solito un valore nullo indica il processo corrente) così da poterla
3426 riutilizzare per una successiva reimpostazione.
3427
3428 È chiaro che queste funzioni per la gestione dell'affinità hanno significato
3429 soltanto su un sistema multiprocessore, esse possono comunque essere
3430 utilizzate anche in un sistema con un processore singolo, nel qual caso però
3431 non avranno alcun risultato effettivo.
3432
3433 \itindend{scheduler}
3434 \itindend{CPU~affinity}
3435
3436
3437 \subsection{Le priorità per le operazioni di I/O}
3438 \label{sec:io_priority}
3439
3440 A lungo l'unica priorità usata per i processi è stata quella relativa
3441 all'assegnazione dell'uso del processore. Ma il processore non è l'unica
3442 risorsa che i processi devono contendersi, un'altra, altrettanto importante
3443 per le prestazioni, è quella dell'accesso a disco. Per questo motivo nello
3444 sviluppo del kernel sono stati introdotti diversi \textit{I/O scheduler} in
3445 grado di distribuire in maniera opportuna questa risorsa ai vari processi.
3446
3447 Fino al kernel 2.6.17 era possibile soltanto differenziare le politiche
3448 generali di gestione, scegliendo di usare un diverso \textit{I/O scheduler}. A
3449 partire da questa versione, con l'introduzione dello \textit{scheduler} CFQ
3450 (\textit{Completely Fair Queuing}) è divenuto possibile, qualora si usi questo
3451 \textit{scheduler}, impostare anche delle diverse priorità di accesso per i
3452 singoli processi.\footnote{al momento (kernel 2.6.31), le priorità di I/O sono
3453   disponibili soltanto per questo \textit{scheduler}.}
3454
3455 La scelta di uno \textit{scheduler} di I/O si può fare in maniera generica per
3456 tutto il sistema all'avvio del kernel con il parametro di avvio
3457 \texttt{elevator},\footnote{per la trattazione dei parametri di avvio del
3458   kernel si rimanda al solito alla sez.~5.3 di \cite{AGL}.} cui assegnare il
3459 nome dello \textit{scheduler}, ma se ne può anche indicare uno specifico per
3460 l'accesso al singolo disco scrivendo nel file
3461 \texttt{/sys/block/\textit{<dev>}/queue/scheduler} (dove
3462 \texttt{\textit{<dev>}} è il nome del dispositivo associato al disco).
3463
3464 Gli \textit{scheduler} disponibili sono mostrati dal contenuto dello stesso
3465 file che riporta fra parentesi quadre quello attivo, il default in tutti i
3466 kernel recenti è proprio il \texttt{cfq},\footnote{nome con cui si indica
3467   appunto lo \textit{scheduler} CFQ.} che supporta le priorità. Per i dettagli
3468 sulle caratteristiche specifiche degli altri \textit{scheduler}, la cui
3469 discussione attiene a problematiche di ambito sistemistico, si consulti la
3470 documentazione nella directory \texttt{Documentation/block/} dei sorgenti del
3471 kernel.
3472
3473 Una volta che si sia impostato lo \textit{scheduler} CFQ ci sono due
3474 specifiche \textit{system call}, specifiche di Linux, che consentono di
3475 leggere ed impostare le priorità di I/O.\footnote{se usate in corrispondenza
3476   ad uno \textit{scheduler} diverso il loro utilizzo non avrà alcun effetto.}
3477 Dato che non esiste una interfaccia diretta nella \acr{glibc} per queste due
3478 funzioni\footnote{almeno al momento della scrittura di questa sezione, con la
3479   versione 2.11 della \acr{glibc}.} occorrerà invocarle tramite la funzione
3480 \func{syscall} (come illustrato in sez.~\ref{sec:proc_syscall}). Le due
3481 \textit{system call} sono \funcd{ioprio\_get} ed \funcd{ioprio\_set}; i
3482 rispettivi prototipi sono:
3483
3484 \begin{funcproto}{ 
3485 \fhead{linux/ioprio.h}
3486 \fdecl{int ioprio\_get(int which, int who)}
3487 \fdesc{Legge la priorità di I/O di un processo.} 
3488 \fdecl{int ioprio\_set(int which, int who, int ioprio)}
3489 \fdesc{Imposta la priorità di I/O di un processo.} 
3490 }
3491 {Le funzioni ritornano rispettivamente un intero positivo o 0 in caso di
3492   successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
3493   valori:
3494 \begin{errlist}
3495 \item[\errcode{EINVAL}] i valori di \param{which} o di \param{ioprio} non
3496   sono validi. 
3497 \item[\errcode{EPERM}] non si hanno i privilegi per eseguire
3498   l'impostazione (solo per \func{ioprio\_set}). 
3499 \item[\errcode{ESRCH}] non esiste un processo corrispondente alle indicazioni.
3500 \end{errlist}}
3501 \end{funcproto}
3502
3503 Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione
3504 dei due argomenti \param{which} e \param{who} che hanno lo stesso significato
3505 già visto per gli omonimi argomenti di \func{getpriority} e
3506 \func{setpriority}. Anche in questo caso si deve specificare il valore
3507 di \param{which} tramite le opportune costanti riportate in
3508 tab.~\ref{tab:ioprio_args} che consentono di indicare un singolo processo, i
3509 processi di un \textit{process group} (tratteremo questo argomento in
3510 sez.~\ref{sec:sess_proc_group}) o tutti i processi di un utente.
3511
3512 \begin{table}[htb]
3513   \centering
3514   \footnotesize
3515   \begin{tabular}[c]{|c|c|l|}
3516     \hline
3517     \param{which} & \param{who} & \textbf{Significato} \\
3518     \hline
3519     \hline
3520     \constd{IPRIO\_WHO\_PROCESS} & \type{pid\_t} & processo\\
3521     \constd{IPRIO\_WHO\_PRGR}    & \type{pid\_t} & \textit{process group}\\ 
3522     \constd{IPRIO\_WHO\_USER}    & \type{uid\_t} & utente\\
3523     \hline
3524   \end{tabular}
3525   \caption{Legenda del valore dell'argomento \param{which} e del tipo
3526     dell'argomento \param{who} delle funzioni \func{ioprio\_get} e
3527     \func{ioprio\_set} per le tre possibili scelte.}
3528   \label{tab:ioprio_args}
3529 \end{table}
3530
3531 In caso di successo \func{ioprio\_get} restituisce un intero positivo che
3532 esprime il valore della priorità di I/O, questo valore è una maschera binaria
3533 composta da due parti, una che esprime la \textsl{classe} di
3534 \textit{scheduling} di I/O del processo, l'altra che esprime, quando la classe
3535 di \textit{scheduling} lo prevede, la priorità del processo all'interno della
3536 classe stessa. Questo stesso formato viene utilizzato per indicare il valore
3537 della priorità da impostare con l'argomento \param{ioprio} di