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