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