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