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