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