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