3 %% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
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 \textit{process identifier} o, più brevemente, \acr{pid}, assegnato in forma
48 progressiva (vedi sez.~\ref{sec:proc_pid}) quando il processo viene creato.
50 Una seconda caratteristica di un sistema unix-like è che la generazione di un
51 processo è un'operazione separata rispetto al lancio di un programma. In
52 genere la sequenza è sempre quella di creare un nuovo processo, il quale
53 eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
54 quello che fa la shell quando mette in esecuzione il programma che gli
55 indichiamo nella linea di comando.
57 Una terza caratteristica del sistema è che ogni processo è sempre stato
58 generato da un altro processo, il processo generato viene chiamato
59 \textit{processo figlio} (\textit{child process}) mentre quello che lo ha
60 viene chiamato \textsl{processo padre} (\textit{parent process}). Questo vale
61 per tutti i processi, con una sola eccezione, dato che ci deve essere un punto
62 di partenza esiste un processo speciale (che normalmente è \cmd{/sbin/init}),
63 che come abbiamo accennato in sez.~\ref{sec:intro_kern_and_sys} viene lanciato
64 dal kernel alla conclusione della fase di avvio. Essendo questo il primo
65 processo lanciato dal sistema ha sempre il \acr{pid} uguale a 1 e non è figlio
66 di nessun altro processo.
68 Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
69 partire tutti gli altri processi necessari al funzionamento del sistema,
70 inoltre \cmd{init} è essenziale per svolgere una serie di compiti
71 amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
72 essi in sez.~\ref{sec:proc_termination}) e non può mai essere terminato. La
73 struttura del sistema comunque consente di lanciare al posto di \cmd{init}
74 qualunque altro programma, e in casi di emergenza (ad esempio se il file di
75 \cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
76 posto.\footnote{la cosa si fa passando la riga \cmd{init=/bin/sh} come
77 parametro di avvio del kernel, l'argomento è di natura amministrativa e
78 trattato in sez.~5.3 di \cite{AGL}.}
83 [piccardi@gont piccardi]$ pstree -n
102 |-bash---startx---xinit-+-XFree86
103 | `-WindowMaker-+-ssh-agent
111 | |-wterm---bash---pstree
112 | `-wterm---bash-+-emacs
119 \caption{L'albero dei processi, così come riportato dal comando
121 \label{fig:proc_tree}
124 Dato che tutti i processi attivi nel sistema sono comunque generati da
125 \cmd{init} o da uno dei suoi figli si possono classificare i processi con la
126 relazione padre/figlio in un'organizzazione gerarchica ad albero. In
127 fig.~\ref{fig:proc_tree} si è mostrato il risultato del comando \cmd{pstree}
128 che permette di visualizzare questa struttura, alla cui base c'è \cmd{init}
129 che è progenitore di tutti gli altri processi.\footnote{in realtà questo non è
130 del tutto vero, in Linux, specialmente nelle versioni più recenti del
131 kernel, ci sono alcuni processi speciali (come \cmd{keventd}, \cmd{kswapd},
132 ecc.) che pur comparendo nei comandi come figli di \cmd{init}, o con
133 \acr{pid} successivi ad uno, sono in realtà processi interni al kernel e che
134 non rientrano in questa classificazione.}
136 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
137 \itindex{process~table} \textit{process table}. Per ciascun processo viene
138 mantenuta una voce in questa tabella, costituita da una struttura
139 \struct{task\_struct}, che contiene tutte le informazioni rilevanti per quel
140 processo. Tutte le strutture usate a questo scopo sono dichiarate
141 nell'\textit{header file} \file{linux/sched.h}, ed uno schema semplificato,
142 che riporta la struttura delle principali informazioni contenute nella
143 \struct{task\_struct} (che in seguito incontreremo a più riprese), è mostrato
144 in fig.~\ref{fig:proc_task_struct}.
147 \centering \includegraphics[width=14cm]{img/task_struct}
148 \caption{Schema semplificato dell'architettura delle strutture usate dal
149 kernel nella gestione dei processi.}
150 \label{fig:proc_task_struct}
153 % TODO la task_struct è cambiata per qualche dettaglio vedi anche
154 % http://www.ibm.com/developerworks/linux/library/l-linux-process-management/
155 % TODO completare la parte su quando viene chiamato lo scheduler.
157 Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
158 \textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
159 eseguito ad ogni \textit{system call} ed ad ogni interrupt e in una serie di
160 altre occasioni, ma può essere anche attivato esplicitamente. Il timer di
161 sistema provvede comunque a che esso sia invocato periodicamente; generando un
162 interrupt periodico secondo la frequenza specificata dalla costante
163 \const{HZ},\footnote{fino al kernel 2.4 il valore di \const{HZ} era 100 su
164 tutte le architetture tranne l'alpha, per cui era 1000, nel 2.6 è stato
165 portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di
166 compilazione del kernel, con un default di 250 e valori possibili di 100,
167 250, 1000 e dal 2.6.20 anche 300 (che è divisibile per le frequenze di
168 refresh della televisione); occorre fare attenzione a non confondere questo
169 valore con quello dei \itindex{clock~tick} \textit{clock tick} (vedi
170 sez.~\ref{sec:sys_unix_time}).} definita in \file{asm/param.h}, ed il cui
171 valore è espresso in Hertz.
173 A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo
174 completamente diverso, detto \textit{tickless}, in cui non c'è più una
175 interruzione periodica con frequenza prefissata, ma ad ogni chiamata del timer
176 viene programmata l'interruzione successiva sulla base di una stima; in questo
177 modo si evita di dover eseguire un migliaio di interruzioni al secondo anche
178 su macchine che non stanno facendo nulla, con un forte risparmio nell'uso
179 dell'energia da parte del processore che può essere messo in stato di
180 sospensione anche per lunghi periodi di tempo.
182 Indipendentemente dalle motivazioni per cui questo avviene, ogni volta che
183 viene eseguito lo \itindex{scheduler} \textit{scheduler} effettua il calcolo
184 delle priorità dei vari processi attivi (torneremo su questo in
185 sez.~\ref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
186 esecuzione fino alla successiva invocazione.
189 \subsection{Gli identificatori dei processi}
192 Come accennato nella sezione precedente ogni processo viene identificato dal
193 sistema da un numero identificativo univoco, il \textit{process ID} o
194 \acr{pid}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un
195 intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
198 Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
199 processo viene creato,\footnote{in genere viene assegnato il numero successivo
200 a quello usato per l'ultimo processo creato, a meno che questo numero non
201 sia già utilizzato per un altro \acr{pid}, \acr{pgid} o \acr{sid} (vedi
202 sez.~\ref{sec:sess_proc_group}).} fino ad un limite che, essendo il
203 tradizionalmente il \acr{pid} un numero positivo memorizzato in un intero a 16
204 bit, arriva ad un massimo di 32768. Oltre questo valore l'assegnazione
205 riparte dal numero più basso disponibile a partire da un minimo di
206 300,\footnote{questi valori, fino al kernel 2.4.x, erano definiti dalla macro
207 \const{PID\_MAX} nei file \file{threads.h} e \file{fork.c} dei sorgenti del
208 kernel, con il 2.6.x e la nuova interfaccia per i \itindex{thread}
209 \textit{thread} anche il meccanismo di allocazione dei \acr{pid} è stato
210 modificato ed il valore massimo è impostabile attraverso il file
211 \procfile{/proc/sys/kernel/pid\_max} e di default vale 32768.} che serve a
212 riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
213 Per questo motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di
214 avvio (\cmd{init}) ha sempre il \acr{pid} uguale a uno.
216 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
217 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
218 \textit{parent process ID}). Questi due identificativi possono essere
219 ottenuti usando le due funzioni \funcd{getpid} e \funcd{getppid}, i cui
225 \fdecl{pid\_t getpid(void)}
226 \fdesc{Restituisce il \acr{pid} del processo corrente..}
227 \fdecl{pid\_t getppid(void)}
228 \fdesc{Restituisce il \acr{pid} del padre del processo corrente.}
230 {Entrambe le funzioni non riportano condizioni di errore.}
233 \noindent esempi dell'uso di queste funzioni sono riportati in
234 fig.~\ref{fig:proc_fork_code}, nel programma \file{ForkTest.c}.
236 Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un
237 candidato per generare ulteriori indicatori associati al processo di cui
238 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
239 funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
240 \acr{pid} per generare un \itindex{pathname} \textit{pathname} univoco, che
241 non potrà essere replicato da un altro processo che usi la stessa
242 funzione. Questo utilizzo però può risultare pericoloso, un \acr{pid} infatti
243 è univoco solo fintanto che un processo è attivo, una volta terminato esso
244 potrà essere riutilizzato da un processo completamente diverso, e di questo
245 bisogna essere ben consapevoli.
247 Tutti i processi figli dello stesso processo padre sono detti
248 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
249 sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
250 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
251 cap.~\ref{cha:session}, dove esamineremo gli altri identificativi associati ad
252 un processo e le varie relazioni fra processi utilizzate per definire una
255 Oltre al \acr{pid} e al \acr{ppid}, e a quelli che vedremo in
256 sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione, ad ogni
257 processo vengono associati degli ulteriori identificatori ed in particolare
258 quelli che vengono usati per il controllo di accesso. Questi servono per
259 determinare se un processo può eseguire o meno le operazioni richieste, a
260 seconda dei privilegi e dell'identità di chi lo ha posto in esecuzione;
261 l'argomento è complesso e sarà affrontato in dettaglio in
262 sez.~\ref{sec:proc_perms}.
265 \subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
266 \label{sec:proc_fork}
268 La funzione \funcd{fork} è la funzione fondamentale della gestione dei
269 processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
270 processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
271 \textit{system call} usata da Linux per creare nuovi processi è \func{clone}
272 (vedi \ref{sec:process_clone}), anche perché a partire dalle \acr{glibc}
273 2.3.3 non viene più usata la \textit{system call} originale, ma la stessa
274 \func{fork} viene implementata tramite \func{clone}, cosa che consente una
275 migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
276 centrale tutte le volte che si devono scrivere programmi che usano il
277 multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei
278 \textit{thread} che tratteremo al cap.~\ref{cha:threads}, è in parte minore,
279 ma \func{fork} resta comunque la funzione principale per la creazione di
280 processi.} Il prototipo della funzione è:
284 \fdecl{pid\_t fork(void)}
285 \fdesc{Crea un nuovo processo.}
287 {La funzione ritorna il \acr{pid} del figlio al padre e $0$ al figlio in caso
288 di successo e $-1$ al padre senza creare il figlio per un errore,
289 nel qual caso \var{errno} assumerà uno dei valori:
291 \item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro
292 processo (per allocare la tabella delle pagine e le strutture del task) o
293 si è esaurito il numero di processi disponibili.
294 \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
295 strutture necessarie al kernel per creare il nuovo processo.
299 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
300 il processo figlio continuano ad essere eseguiti normalmente a partire
301 dall'istruzione successiva alla \func{fork}. Il processo figlio è una copia del
302 padre, e riceve una copia dei \index{segmento!testo} segmenti di testo,
303 \index{segmento!dati} dati e dello \itindex{stack} \textit{stack} (vedi
304 sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
305 padre. Si tenga presente però che la memoria è copiata e non condivisa,
306 pertanto padre e figlio vedranno variabili diverse e le eventuali modifiche
307 saranno totalmente indipendenti.
309 Per quanto riguarda la gestione della memoria, in generale il
310 \index{segmento!testo} segmento di testo, che è identico per i due processi, è
311 condiviso e tenuto in sola lettura per il padre e per i figli. Per gli altri
312 segmenti Linux utilizza la tecnica del \itindex{copy~on~write} \textit{copy on
313 write}. Questa tecnica comporta che una pagina di memoria viene
314 effettivamente copiata per il nuovo processo solo quando ci viene effettuata
315 sopra una scrittura, e si ha quindi una reale differenza fra padre e figlio.
316 In questo modo si rende molto più efficiente il meccanismo della creazione di
317 un nuovo processo, non essendo più necessaria la copia di tutto lo spazio
318 degli indirizzi virtuali del padre, ma solo delle pagine di memoria che sono
319 state modificate, e solo al momento della modifica stessa.
321 La differenza che si ha nei due processi è che nel processo padre il valore di
322 ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
323 nel figlio è zero; in questo modo il programma può identificare se viene
324 eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
325 due volte, una nel padre e una nel figlio.
327 La scelta di questi valori di ritorno non è casuale, un processo infatti può
328 avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
329 permette di identificare quello appena creato. Al contrario un figlio ha
330 sempre un solo padre, il cui \acr{pid} può sempre essere ottenuto con
331 \func{getppid}, come spiegato in sez.~\ref{sec:proc_pid}, per cui si usa il
332 valore nullo, che non è il \acr{pid} di nessun processo.
334 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni: o ci
335 sono già troppi processi nel sistema, il che di solito è sintomo che
336 qualcos'altro non sta andando per il verso giusto, o si è ecceduto il limite
337 sul numero totale di processi permessi all'utente argomento su cui torneremo
338 in sez.~\ref{sec:sys_resource_limit}, (vedi in particolare
339 tab.~\ref{tab:sys_rlimit_values}).
341 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
342 quella in cui all'interno di un programma si creano processi figli cui viene
343 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
344 ne esegue un'altra. È il caso tipico dei programmi server (il modello
345 \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}) in cui il
346 padre riceve ed accetta le richieste da parte dei programmi client, per
347 ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
350 La seconda modalità è quella in cui il processo vuole eseguire un altro
351 programma; questo è ad esempio il caso della shell. In questo caso il processo
352 crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
353 cui parleremo in sez.~\ref{sec:proc_exec}) subito dopo la \func{fork}.
355 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
356 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
357 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
358 scelto di mantenere questa separazione, dato che, come per la prima modalità
359 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
360 aver bisogno di eseguire una \func{exec}.
362 Inoltre, anche nel caso della seconda modalità d'uso, avere le due funzioni
363 separate permette al figlio di cambiare alcune caratteristiche del processo
364 (maschera dei segnali, redirezione dell'output, utente per conto del cui viene
365 eseguito, e molto altro su cui torneremo in seguito) prima della \func{exec},
366 rendendo così relativamente facile intervenire sulle le modalità di esecuzione
370 \footnotesize \centering
371 \begin{minipage}[c]{\codesamplewidth}
372 \includecodesample{listati/ForkTest.c}
375 \caption{Esempio di codice per la creazione di nuovi processi.}
376 \label{fig:proc_fork_code}
379 In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
380 di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
381 dell'uso della funzione \func{fork}. Il programma crea un numero di figli
382 specificato da linea di comando, e prende anche alcune opzioni per indicare
383 degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
384 \func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
385 descrizione delle opzioni). Il codice completo, compresa la parte che gestisce
386 le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
387 distribuito insieme agli altri sorgenti degli esempi su
388 \url{http://gapil.truelite.it/gapil_source.tgz}.
390 Decifrato il numero di figli da creare, il ciclo principale del programma
391 (\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
392 controllando il successo della chiamata a \func{fork} (\texttt{\small
393 25--29}); ciascun figlio (\texttt{\small 31--34}) si limita a stampare il
394 suo numero di successione, eventualmente attendere il numero di secondi
395 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
396 (\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente
397 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
398 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
401 Se eseguiamo il comando, che è preceduto dall'istruzione \code{export
402 LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche, senza
403 specificare attese (come si può notare in (\texttt{\small 17--19}) i valori
404 predefiniti specificano di non attendere), otterremo come risultato sul
407 [piccardi@selidor sources]$ export LD_LIBRARY_PATH=./; ./forktest 3
411 Process 1963: forking 3 child
412 Spawned 1 child, pid 1964
413 Child 1 successfully executing
414 Child 1, parent 1963, exiting
416 Spawned 2 child, pid 1965
417 Child 2 successfully executing
418 Child 2, parent 1963, exiting
420 Child 3 successfully executing
421 Child 3, parent 1963, exiting
422 Spawned 3 child, pid 1966
426 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
427 si può dire quale processo fra il padre ed il figlio venga eseguito per primo
428 dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei
429 primi due cicli sia stato eseguito per primo il padre (con la stampa del
430 \acr{pid} del nuovo processo) per poi passare all'esecuzione del figlio
431 (completata con i due avvisi di esecuzione ed uscita), e tornare
432 all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
433 mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
436 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
437 \itindex{scheduler} scheduling usato dal kernel, dalla particolare situazione
438 in cui si trova la macchina al momento della chiamata, risultando del tutto
439 impredicibile. Eseguendo più volte il programma di prova e producendo un
440 numero diverso di figli, si sono ottenute situazioni completamente diverse,
441 compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
442 prima che uno dei figli venisse messo in esecuzione.
444 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
445 istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
446 essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
447 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
448 rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race
449 condition} (vedi sez.~\ref{sec:proc_race_cond}).
451 In realtà con l'introduzione dei kernel della serie 2.6 lo \itindex{scheduler}
452 \textit{scheduler} è stato modificato per eseguire sempre per primo il
453 figlio.\footnote{i risultati precedenti infatti sono stati ottenuti usando un
454 kernel della serie 2.4.} Questa è una ottimizzazione adottata per evitare
455 che il padre, effettuando per primo una operazione di scrittura in memoria,
456 attivasse il meccanismo del \itindex{copy~on~write} \textit{copy on write},
457 operazione inutile qualora il figlio venga creato solo per eseguire una
458 \func{exec} su altro programma che scarta completamente lo spazio degli
459 indirizzi e rende superflua la copia della memoria modificata dal
460 padre. Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata
461 subito, con la certezza di utilizzare \itindex{copy~on~write} \textit{copy on
462 write} solo quando necessario.
464 Con il kernel 2.6.32 però il comportamento è stato nuovamente cambiato,
465 stavolta facendo eseguire per primo sempre il padre. Si è realizzato infatti
466 che l'eventualità prospettata per la scelta precedente era comunque molto
467 improbabile, mentre l'esecuzione immediata del padre presenta sempre il
468 vantaggio di poter utilizzare immediatamente tutti i dati che sono nella cache
469 della CPU e nella unità di gestione della memoria virtuale senza doverli
470 invalidare, cosa che per i processori moderni, che hanno linee di cache
471 interne molto profonde, avrebbe un forte impatto sulle prestazioni.
473 Allora anche se quanto detto in precedenza vale come comportamento effettivo
474 dei programmi soltanto per i kernel fino alla serie 2.4, per mantenere la
475 portabilità con altri kernel unix-like, e con i diversi comportamenti adottati
476 dalle Linux nelle versioni successive, è opportuno non fare affidamento su
477 nessun tipo comportamento predefinito e non dare per assunta l'esecuzione
478 preventiva del padre o del figlio.
480 Si noti poi come dopo la \func{fork}, essendo i segmenti di memoria utilizzati
481 dai singoli processi completamente indipendenti, le modifiche delle variabili
482 nei processi figli, come l'incremento di \var{i} in (\texttt{\small 31}), sono
483 visibili solo a loro, (ogni processo vede solo la propria copia della
484 memoria), e non hanno alcun effetto sul valore che le stesse variabili hanno
485 nel processo padre ed in eventuali altri processi figli che eseguano lo stesso
488 Un secondo aspetto molto importante nella creazione dei processi figli è
489 quello dell'interazione dei vari processi con i file. Ne parleremo qui anche
490 se buona parte dei concetti relativi ai file verranno trattati più avanti
491 (principalmente nel cap.~\ref{cha:file_unix_interface}). Per illustrare meglio
492 quello che avviene si può redirigere su un file l'output del programma di
493 test, quello che otterremo è:
495 [piccardi@selidor sources]$ ./forktest 3 > output
496 [piccardi@selidor sources]$ cat output
499 Process 1967: forking 3 child
500 Child 1 successfully executing
501 Child 1, parent 1967, exiting
502 Test for forking 3 child
503 Spawned 1 child, pid 1968
505 Child 2 successfully executing
506 Child 2, parent 1967, exiting
507 Test for forking 3 child
508 Spawned 1 child, pid 1968
510 Spawned 2 child, pid 1969
512 Child 3 successfully executing
513 Child 3, parent 1967, exiting
514 Test for forking 3 child
515 Spawned 1 child, pid 1968
517 Spawned 2 child, pid 1969
519 Spawned 3 child, pid 1970
522 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
524 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
525 in gran dettaglio in cap.~\ref{cha:file_unix_interface} per l'interfaccia
526 nativa Unix ed in cap.~\ref{cha:files_std_interface} per la standardizzazione
527 adottata nelle librerie del linguaggio C e valida per qualunque sistema
528 operativo. Qui basta accennare che si sono usate le funzioni standard della
529 libreria del C che prevedono l'output bufferizzato. Il punto è che questa
530 bufferizzazione (che tratteremo in dettaglio in sez.~\ref{sec:file_buffering})
531 varia a seconda che si tratti di un file su disco, in cui il buffer viene
532 scaricato su disco solo quando necessario, o di un terminale, in cui il buffer
533 viene scaricato ad ogni carattere di a capo.
535 Nel primo esempio allora avevamo che, essendovi un a capo nella stringa
536 stampata, ad ogni chiamata a \func{printf} il buffer veniva scaricato, per cui
537 le singole righe comparivano a video subito dopo l'esecuzione della
538 \func{printf}. Ma con la redirezione su file la scrittura non avviene più alla
539 fine di ogni riga e l'output resta nel buffer. Dato che ogni figlio riceve una
540 copia della memoria del padre, esso riceverà anche quanto c'è nel buffer delle
541 funzioni di I/O, comprese le linee scritte dal padre fino allora. Così quando
542 il buffer viene scritto su disco all'uscita del figlio, troveremo nel file
543 anche tutto quello che il processo padre aveva scritto prima della sua
544 creazione. E alla fine del file (dato che in questo caso il padre esce per
545 ultimo) troveremo anche l'output completo del padre.
547 L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
548 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
549 solo processi diversi possono scrivere in contemporanea sullo stesso file
550 (l'argomento della condivisione dei file è trattato in dettaglio in
551 sez.~\ref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
552 le variabili in memoria, la posizione corrente sul file è condivisa fra il
553 padre e tutti i processi figli.
555 Quello che succede è che quando lo \textit{standard output}\footnote{si chiama
556 così il file su cui un programma scrive i suoi dati in uscita, tratteremo
557 l'argomento in dettaglio in sez.~\ref{sec:file_std_descr}.} del padre viene
558 rediretto come si è fatto nell'esempio, lo stesso avviene anche per tutti i
559 figli. La funzione \func{fork} infatti ha la caratteristica di duplicare nei
560 processi figli tutti i file descriptor (vedi sez.~\ref{sec:file_fd}) dei file
561 aperti nel processo padre (allo stesso modo in cui lo fa la funzione
562 \func{dup}, trattata in sez.~\ref{sec:file_dup}), il che comporta che padre e
563 figli condividono le stesse voci della \itindex{file~table} \textit{file
564 table} (tratteremo in dettagli questi termini in
565 sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente nel file.
567 In questo modo se un processo scrive su un file aggiornerà la posizione
568 corrente sulla \itindex{file~table} \textit{file table}, e tutti gli altri
569 processi, che vedono la stessa \itindex{file~table} \textit{file table},
570 vedranno il nuovo valore. In questo modo si evita, in casi come quello appena
571 mostrato in cui diversi processi scrivono sullo stesso file, che l'output
572 successivo di un processo vada a sovrapporsi a quello dei precedenti: l'output
573 potrà risultare mescolato, ma non ci saranno parti perdute per via di una
576 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
577 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
578 scrivono sullo stesso file. Un caso tipico di questo comportamento è la shell
579 quando lancia un programma. In questo modo, anche se lo standard output viene
580 rediretto, il padre potrà sempre continuare a scrivere in coda a quanto
581 scritto dal figlio in maniera automatica; se così non fosse ottenere questo
582 comportamento sarebbe estremamente complesso necessitando di una qualche forma
583 di comunicazione fra i due processi per far riprendere al padre la scrittura
586 In generale comunque non è buona norma far scrivere più processi sullo stesso
587 file senza una qualche forma di sincronizzazione in quanto, come visto anche
588 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
589 una sequenza impredicibile. Per questo le modalità con cui in genere si usano
590 i file dopo una \func{fork} sono sostanzialmente due:
592 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
593 è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
594 della posizione corrente dopo eventuali operazioni di lettura e scrittura
595 effettuate dal figlio è automatica.
596 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
597 ciascuno dei due processi deve chiudere i file che non gli servono una volta
598 che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
601 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
602 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
603 comune dopo l'esecuzione di una \func{fork} è la seguente:
605 \item i file aperti e gli eventuali flag di \itindex{close-on-exec}
606 \textit{close-on-exec} impostati (vedi sez.~\ref{sec:proc_exec} e
607 sez.~\ref{sec:file_fcntl});
608 \item gli identificatori per il controllo di accesso: l'\textsl{user-ID
609 reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
610 \textsl{group-ID effettivo} ed i \textit{group-ID supplementari} (vedi
611 sez.~\ref{sec:proc_access_id});
612 \item gli identificatori per il controllo di sessione: il
613 \itindex{process~group} \textit{process group-ID} e il \textit{session id}
614 ed il terminale di controllo (vedi sez.~\ref{sec:sess_proc_group});
615 \item la directory di lavoro e la directory radice (vedi
616 sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
617 \item la maschera dei permessi di creazione dei file (vedi
618 sez.~\ref{sec:file_perm_management});
619 \item la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask}) e le
620 azioni installate (vedi sez.~\ref{sec:sig_gen_beha});
621 \item i segmenti di memoria condivisa agganciati al processo (vedi
622 sez.~\ref{sec:ipc_sysv_shm});
623 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
624 \item il valori di \textit{nice}, le priorità real-time e le affinità di
625 processore (vedi sez.~\ref{sec:proc_sched_stand},
626 sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
627 \item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
628 \item l'insieme dei descrittori associati alle code di messaggi POSIX (vedi
629 sez.~\ref{sec:ipc_posix_mq}) che vengono copiate come i file descriptor,
630 questo significa che entrambi condivideranno gli stessi flag.
633 Oltre a quelle relative ad un diverso spazio degli indirizzi (e una memoria
634 totalmente indipendente) le differenze fra padre e figlio dopo l'esecuzione di
635 una \func{fork} invece sono:\footnote{a parte le ultime quattro, relative a
636 funzionalità specifiche di Linux, le altre sono esplicitamente menzionate
637 dallo standard POSIX.1-2001.}
639 \item il valore di ritorno di \func{fork};
640 \item il \acr{pid} (\textit{process id}), quello del figlio viene assegnato ad
641 un nuovo valore univoco;
642 \item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
643 impostato al \acr{pid} del padre;
644 \item i valori dei tempi di esecuzione (vedi sez.~\ref{sec:sys_cpu_times}) e
645 delle risorse usate (vedi sez.~\ref{sec:sys_resource_use}), che nel figlio
647 \item i \textit{lock} sui file (vedi sez.~\ref{sec:file_locking}) e sulla
648 memoria (vedi sez.~\ref{sec:proc_mem_lock}), che non vengono ereditati dal
650 \item gli allarmi, i timer (vedi sez.~\ref{sec:sig_alarm_abort}) ed i segnali
651 pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che per il figlio vengono
653 \item le operazioni di I/O asincrono in corso (vedi
654 sez.~\ref{sec:file_asyncronous_io}) che non vengono ereditate dal figlio;
655 \item gli aggiustamenti fatti dal padre ai semafori con \func{semop} (vedi
656 sez.~\ref{sec:ipc_sysv_sem}).
657 \item le notifiche sui cambiamenti delle directory con \textit{dnotify} (vedi
658 sez.~\ref{sec:sig_notification}), che non vengono ereditate dal figlio;
659 \item le mappature di memoria marcate come \const{MADV\_DONTFORK} (vedi
660 sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;
661 \item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:process_prctl}) che
662 notifica al figlio la terminazione del padre viene cancellata se presente
664 \item il segnale di terminazione del figlio è sempre \signal{SIGCHLD} anche
665 qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}).
668 Una seconda funzione storica usata per la creazione di un nuovo processo è
669 \func{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
670 semantica e gli stessi errori; la sola differenza è che non viene creata la
671 tabella delle pagine né la struttura dei task per il nuovo processo. Il
672 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
673 \func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
674 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
675 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
677 Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
678 \func{fork} comportava anche la copia completa del segmento dati del processo
679 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
680 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
681 venne introdotta in BSD per migliorare le prestazioni.
683 Dato che Linux supporta il \itindex{copy~on~write} \textit{copy on write} la
684 perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
685 funzione, che resta un caso speciale della \textit{system call} \func{clone}
686 (che tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per
687 questo eviteremo di trattarla ulteriormente.
690 \subsection{La conclusione di un processo}
691 \label{sec:proc_termination}
693 In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
694 chiudere un programma, ma dall'interno del programma stesso. Avendo a che fare
695 con un sistema \textit{multitasking} resta da affrontare l'argomento dal punto
696 di vista di come il sistema gestisce la conclusione dei processi.
698 Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
699 programma viene terminato in maniera normale: la chiamata di \func{exit}, che
700 esegue le funzioni registrate per l'uscita e chiude i \textit{file stream} e
701 poi esegue \func{\_exit}, il ritorno dalla funzione \func{main} equivalente
702 alla chiamata di \func{exit}, e la chiamata diretta a \func{\_exit}, che passa
703 direttamente alle operazioni di terminazione del processo da parte del kernel.
705 Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
706 modalità di conclusione anomala. Queste sono in sostanza due: il programma può
707 chiamare la funzione \func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}) per
708 invocare una chiusura anomala, o essere terminato da un segnale (torneremo sui
709 segnali in cap.~\ref{cha:signals}). In realtà anche la prima modalità si
710 riconduce alla seconda, dato che \func{abort} si limita a generare il segnale
713 Qualunque sia la modalità di conclusione di un processo, il kernel esegue
714 comunque una serie di operazioni di terminazione: chiude tutti i file aperti,
715 rilascia la memoria che stava usando, e così via; l'elenco completo delle
716 operazioni eseguite alla chiusura di un processo è il seguente:
718 \item tutti i file descriptor sono chiusi;
719 \item viene memorizzato lo stato di terminazione del processo;
720 \item ad ogni processo figlio viene assegnato un nuovo padre (in genere
722 \item viene inviato il segnale \signal{SIGCHLD} al processo padre (vedi
723 sez.~\ref{sec:sig_sigchld});
724 \item se il processo è un leader di sessione ed il suo terminale di controllo
725 è quello della sessione viene mandato un segnale di \signal{SIGHUP} a tutti i
726 processi del gruppo di \textit{foreground} e il terminale di controllo viene
727 disconnesso (vedi sez.~\ref{sec:sess_ctrl_term});
728 \item se la conclusione di un processo rende orfano un \textit{process
729 group} ciascun membro del gruppo viene bloccato, e poi gli vengono
730 inviati in successione i segnali \signal{SIGHUP} e \signal{SIGCONT}
731 (vedi ancora sez.~\ref{sec:sess_ctrl_term}).
734 \itindbeg{termination~status}
736 Oltre queste operazioni è però necessario poter disporre di un meccanismo
737 ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
738 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
739 scelto consiste nel riportare lo \itindex{termination~status} \textsl{stato di
740 terminazione} (il cosiddetto \textit{termination status}) al processo padre.
742 Nel caso di conclusione normale, abbiamo visto in
743 sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
744 caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
745 valore passato come argomento alle funzioni \func{exit} o \func{\_exit} o il
746 valore di ritorno per \func{main}. Ma se il processo viene concluso in
747 maniera anomala il programma non può specificare nessun \textit{exit status},
748 ed è il kernel che deve generare autonomamente il \textit{termination status}
749 per indicare le ragioni della conclusione anomala.
751 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
752 quello che contraddistingue lo stato di chiusura del processo e viene
753 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
754 sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione
755 normale il kernel usa il primo (nel codice eseguito da \func{\_exit}) per
758 La scelta di riportare al padre lo stato di terminazione dei figli, pur
759 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
760 alla sua creazione è scontato che ogni nuovo processo abbia un padre, non è
761 detto che sia così alla sua conclusione, dato che il padre potrebbe essere già
762 terminato; si potrebbe avere cioè quello che si chiama un processo
765 Questa complicazione viene superata facendo in modo che il processo orfano
766 venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \acr{pid} 1,
767 cioè quello lanciato direttamente dal kernel all'avvio, che sta alla base
768 dell'albero dei processi visto in sez.~\ref{sec:proc_hierarchy} e che anche
769 per questo motivo ha un ruolo essenziale nel sistema e non può mai
770 terminare.\footnote{almeno non senza un blocco completo del sistema, in caso
771 di terminazione o di non esecuzione di \cmd{init} infatti il kernel si
772 blocca con un cosiddetto \textit{kernel panic}, dato che questo è un errore
775 Come già accennato quando un processo termina, il kernel controlla se è il
776 padre di altri processi in esecuzione: in caso positivo allora il \acr{ppid}
777 di tutti questi processi verrà sostituito dal kernel con il \acr{pid} di
778 \cmd{init}, cioè con 1. In questo modo ogni processo avrà sempre un padre (nel
779 caso possiamo parlare di un padre \textsl{adottivo}) cui riportare il suo
780 stato di terminazione.
782 Come verifica di questo comportamento possiamo eseguire il nostro programma
783 \cmd{forktest} imponendo a ciascun processo figlio due secondi di attesa prima
784 di uscire, il risultato è:
786 [piccardi@selidor sources]$ ./forktest -c2 3
788 \begin{Terminal}[commandchars=\\\{\}]
789 Process 1972: forking 3 child
790 Spawned 1 child, pid 1973
791 Child 1 successfully executing
793 Spawned 2 child, pid 1974
794 Child 2 successfully executing
796 Child 3 successfully executing
797 Spawned 3 child, pid 1975
800 \textbf{[piccardi@selidor sources]$} Child 3, parent 1, exiting
801 Child 2, parent 1, exiting
802 Child 1, parent 1, exiting
804 come si può notare in questo caso il processo padre si conclude prima dei
805 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
806 secondi dopo viene stampato a video anche l'output dei tre figli che
807 terminano, e come si può notare in questo caso, al contrario di quanto visto
808 in precedenza, essi riportano 1 come \acr{ppid}.
810 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
811 perché non è detto che il padre possa ricevere immediatamente lo stato di
812 terminazione, quindi il kernel deve comunque conservare una certa quantità di
813 informazioni riguardo ai processi che sta terminando.
815 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
816 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
817 dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
818 mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente.
820 I processi che sono terminati, ma il cui stato di terminazione non è stato
821 ancora ricevuto dal padre sono chiamati \itindex{zombie} \textit{zombie}, essi
822 restano presenti nella tabella dei processi ed in genere possono essere
823 identificati dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella
824 colonna che ne indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando
825 il padre effettuerà la lettura dello stato di terminazione anche questa
826 informazione, non più necessaria, verrà scartata ed il processo potrà
827 considerarso completamente concluso.
829 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
830 condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi
831 sez.~\ref{sec:sess_job_control}), indicando al processo padre di aspettare 10
832 secondi prima di uscire. In questo caso, usando \cmd{ps} sullo stesso
833 terminale (prima dello scadere dei 10 secondi) otterremo:
835 [piccardi@selidor sources]$ ps T
839 PID TTY STAT TIME COMMAND
840 419 pts/0 S 0:00 bash
841 568 pts/0 S 0:00 ./forktest -e10 3
842 569 pts/0 Z 0:00 [forktest <defunct>]
843 570 pts/0 Z 0:00 [forktest <defunct>]
844 571 pts/0 Z 0:00 [forktest <defunct>]
845 572 pts/0 R 0:00 ps T
847 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
848 terminazione, i tre processi figli sono ancora presenti pur essendosi
849 conclusi, con lo stato di \itindex{zombie} \textit{zombie} e l'indicazione che
850 sono terminati (la scritta \texttt{defunct}).
852 La possibilità di avere degli \itindex{zombie} \textit{zombie} deve essere
853 tenuta sempre presente quando si scrive un programma che deve essere mantenuto
854 in esecuzione a lungo e creare molti figli. In questo caso si deve sempre
855 avere cura di far leggere l'eventuale stato di uscita di tutti i figli. In
856 genere questo si fa attraverso un apposito \textit{signal handler}, che chiama
857 la funzione \func{wait}, (vedi sez.~\ref{sec:sig_sigchld} e
858 sez.~\ref{sec:proc_wait}) di cui vedremo un esempio in
859 fig.~\ref{fig:sig_sigchld_handl}.
861 Questa operazione è necessaria perché anche se gli \itindex{zombie}
862 \textit{zombie} non consumano risorse di memoria o processore, occupano
863 comunque una voce nella tabella dei processi e se li si lascia accumulare a
864 lungo quest'ultima potrebbe riempirsi, con l'impossibilità di lanciare nuovi
867 Si noti tuttavia che quando un processo adottato da \cmd{init} termina, non
868 diviene mai uno \itindex{zombie} \textit{zombie}. Questo perché una delle
869 funzioni di \cmd{init} è appunto quella di chiamare la funzione \func{wait}
870 per i processi a cui fa da padre, completandone la terminazione. Questo è
871 quanto avviene anche quando, come nel caso del precedente esempio con
872 \cmd{forktest}, il padre termina con dei figli in stato di \itindex{zombie}
873 \textit{zombie}. Questi scompaiono quando, alla terminazione del padre dopo i
874 secondi programmati, tutti figli che avevamo generato, e che erano diventati
875 \itindex{zombie} \textit{zombie}, vengono adottati da \cmd{init}, il quale
876 provvede a completarne la terminazione.
878 Si tenga presente infine che siccome gli \itindex{zombie} \textit{zombie} sono
879 processi già terminati, non c'è modo di eliminarli con il comando \cmd{kill} o
880 inviandogli un qualunque segnale di terminazione (l'argomento è trattato in
881 sez.~\ref{sec:sig_termination}). L'unica possibilità di cancellarli dalla
882 tabella dei processi è quella di terminare il processo che li ha generati, in
883 modo che \cmd{init} possa adottarli e concluderne la terminazione.
885 \subsection{Le funzioni di attesa e ricezione degli stati di uscita}
886 \label{sec:proc_wait}
888 Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
889 consiste nella creazione di programmi di tipo server, in cui un processo
890 principale attende le richieste che vengono poi soddisfatte da una serie di
893 Si è già sottolineato al paragrafo precedente come in questo caso diventi
894 necessario gestire esplicitamente la conclusione dei figli onde evitare di
895 riempire di \itindex{zombie} \textit{zombie} la tabella dei
896 processi. Tratteremo in questa sezione le funzioni deputate a questo compito;
897 la prima è \funcd{wait} ed il suo prototipo è:
902 \fdecl{pid\_t wait(int *status)}
903 \fdesc{Attende la terminazione di un processo.}
905 {La funzione ritorna il \acr{pid} del figlio in caso di successo e $-1$ per un
906 errore, nel qual caso \var{errno} assumerà uno dei valori:
908 \item[\errcode{ECHILD}] il processo non ha nessun figlio di cui attendere
909 uno stato di terminazione.
910 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
914 Questa funzione è presente fin dalle prime versioni di Unix ed è quella usata
915 tradizionalmente per attendere la terminazione dei figli. La funzione sospende
916 l'esecuzione del processo corrente e ritorna non appena un qualunque processo
917 figlio termina. Se un figlio è già terminato prima della sua chiamata la
918 funzione ritorna immediatamente, se più processi figli sono già terminati
919 occorrerà continuare a chiamare la funzione più volte fintanto che non si è
920 recuperato lo stato di terminazione di tutti quanti.
922 Al ritorno della funzione lo stato di terminazione del figlio viene salvato
923 (come \itindex{value~result~argument} \textit{value result argument}) nella
924 variabile puntata da \param{status} e tutte le risorse del kernel relative al
925 processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate. Nel caso
926 un processo abbia più figli il valore di ritorno della funzione sarà impostato
927 al \acr{pid} del processo di cui si è ricevuto lo stato di terminazione, cosa
928 che permette di identificare qual è il figlio che è terminato.
930 \itindend{termination~status}
932 Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
933 all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
934 necessario attendere la conclusione di uno specifico processo fra tutti quelli
935 esistenti occorre predisporre un meccanismo che tenga conto di tutti processi
936 che sono terminati, e provveda a ripetere la chiamata alla funzione nel caso
937 il processo cercato non risulti fra questi. Se infatti il processo cercato è
938 già terminato e se è già ricevuto lo stato di uscita senza registrarlo, la
939 funzione non ha modo di accorgersene, e si continuerà a chiamarla senza
940 accorgersi che quanto interessava è già accaduto.
942 Per questo motivo lo standard POSIX.1 ha introdotto una seconda funzione che
943 effettua lo stesso servizio, ma dispone di una serie di funzionalità più
944 ampie, legate anche al controllo di sessione (si veda
945 sez.~\ref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
946 comportamento di \func{wait}\footnote{in effetti il codice
947 \code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
948 \&status, 0)}.} si consiglia di utilizzare sempre questa nuova funzione,
949 \funcd{waitpid}, il cui prototipo è:
954 \fdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
955 \fdesc{Attende il cambiamento di stato di un processo figlio.}
957 {La funzione ritorna il \acr{pid} del processo che ha cambiato stato in caso
958 di successo, o 0 se è stata specificata l'opzione \const{WNOHANG} e il
959 processo non è uscito e $-1$ per un errore, nel qual caso \var{errno}
960 assumerà uno dei valori:
962 \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
963 la funzione è stata interrotta da un segnale.
964 \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
965 non è figlio del processo chiamante.
966 \item[\errcode{EINVAL}] si è specificato un valore non valido per
967 l'argomento \param{options}.
971 La prima differenza fra le due funzioni è che con \func{waitpid} si può
972 specificare in maniera flessibile quale processo attendere, sulla base del
973 valore fornito dall'argomento \param{pid}, questo può assumere diversi valori,
974 secondo lo specchietto riportato in tab.~\ref{tab:proc_waidpid_pid}, dove si
975 sono riportate anche le costanti definite per indicare alcuni di essi.
980 \begin{tabular}[c]{|c|c|p{8cm}|}
982 \textbf{Valore} & \textbf{Costante} &\textbf{Significato}\\
985 $<-1$& -- & Attende per un figlio il cui
986 \itindex{process~group} \textit{process group}
987 (vedi sez.~\ref{sec:sess_proc_group}) è uguale
988 al valore assoluto di \param{pid}. \\
989 $-1$&\const{WAIT\_ANY} & Attende per un figlio qualsiasi, usata in
990 questa maniera senza specificare nessuna opzione
991 è equivalente a \func{wait}.\\
992 $ 0$&\const{WAIT\_MYPGRP}&Attende per un figlio il cui
993 \itindex{process~group} \textit{process group}
994 (vedi sez.~\ref{sec:sess_proc_group}) è
995 uguale a quello del processo chiamante. \\
996 $>0$& -- & Attende per un figlio il cui \acr{pid} è uguale
997 al valore di \param{pid}.\\
1000 \caption{Significato dei valori dell'argomento \param{pid} della funzione
1002 \label{tab:proc_waidpid_pid}
1005 Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
1006 funzione delle opportune opzioni tramite l'argomento \param{options}; questo
1007 deve essere specificato come maschera binaria delle costanti riportati nella
1008 prima parte in tab.~\ref{tab:proc_waitpid_options} che possono essere
1009 combinate fra loro con un OR aritmetico. Nella seconda parte della stessa
1010 tabella si sono riportati anche alcuni valori non standard specifici di Linux,
1011 che consentono un controllo più dettagliato per i processi creati con la
1012 \textit{system call} generica \func{clone} (vedi sez.~\ref{sec:process_clone})
1013 usati principalmente per la gestione della terminazione dei \itindex{thread}
1014 \textit{thread} (vedi sez.~\ref{sec:thread_xxx}).
1019 \begin{tabular}[c]{|l|p{8cm}|}
1021 \textbf{Valore} & \textbf{Descrizione}\\
1024 \const{WNOHANG} & La funzione ritorna immediatamente anche se non è
1025 terminato nessun processo figlio. \\
1026 \const{WUNTRACED} & Ritorna anche se un processo figlio è stato fermato. \\
1027 \const{WCONTINUED}& Ritorna anche quando un processo figlio che era stato
1028 fermato ha ripreso l'esecuzione.\footnotemark \\
1030 \const{\_\_WCLONE}& Attende solo per i figli creati con \func{clone}
1031 (vedi sez.~\ref{sec:process_clone}), vale a dire
1032 processi che non emettono nessun segnale
1033 o emettono un segnale diverso da \signal{SIGCHLD} alla
1035 \const{\_\_WALL} & Attende per qualunque processo figlio. \\
1036 \const{\_\_WNOTHREAD}& Non attende per i figli di altri \textit{thread}
1037 dello stesso gruppo. \\
1040 \caption{Costanti che identificano i bit dell'argomento \param{options}
1041 della funzione \func{waitpid}.}
1042 \label{tab:proc_waitpid_options}
1045 \footnotetext{disponibile solo a partire dal kernel 2.6.10.}
1047 L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della
1048 funzione qualora nessun figlio sia uscito (o non si siano verificate le altre
1049 condizioni per l'uscita della funzione); in tal caso la funzione ritornerà un
1050 valore nullo anziché positivo.\footnote{anche in questo caso un valore
1051 positivo indicherà il \acr{pid} del processo di cui si è ricevuto lo stato
1052 ed un valore negativo un errore.}
1054 Le altre due opzioni \const{WUNTRACED} e \const{WCONTINUED} consentono
1055 rispettivamente di tracciare non la terminazione di un processo, ma il fatto
1056 che esso sia stato fermato, o fatto ripartire, e sono utilizzate per la
1057 gestione del controllo di sessione (vedi sez.~\ref{sec:sess_job_control}).
1059 Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \acr{pid},
1060 quando un processo figlio entra nello stato \textit{stopped}\footnote{in
1061 realtà viene notificato soltanto il caso in cui il processo è stato fermato
1062 da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in
1063 cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace} (vedi
1064 sez.~\ref{sec:process_ptrace}).} (vedi tab.~\ref{tab:proc_proc_states}),
1065 mentre con \const{WCONTINUED} la funzione ritorna quando un processo in stato
1066 \textit{stopped} riprende l'esecuzione per la ricezione del segnale
1067 \signal{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
1068 dettagliato in sez.~\ref{sec:sess_ctrl_term}).
1070 La terminazione di un processo figlio (così come gli altri eventi osservabili
1071 con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
1072 di un programma e può avvenire in un qualunque momento. Per questo motivo,
1073 come accennato nella sezione precedente, una delle azioni prese dal kernel
1074 alla conclusione di un processo è quella di mandare un segnale di
1075 \signal{SIGCHLD} al padre. L'azione predefinita (si veda
1076 sez.~\ref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
1077 generazione costituisce il meccanismo di comunicazione asincrona con cui il
1078 kernel avverte il processo padre che uno dei suoi figli è terminato.
1080 Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4
1081 al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello
1082 standard POSIX.1-2001,\footnote{una revisione del 2001 dello standard POSIX.1
1083 che ha aggiunto dei requisiti e delle nuove funzioni, come \func{waitid}.}
1084 e come da esso richiesto se \signal{SIGCHLD} viene ignorato, o se si imposta il
1085 flag di \const{SA\_NOCLDSTOP} nella ricezione dello stesso (si veda
1086 sez.~\ref{sec:sig_sigaction}) i processi figli che terminano non diventano
1087 \textit{zombie} e sia \func{wait} che \func{waitpid} si bloccano fintanto che
1088 tutti i processi figli non sono terminati, dopo di che falliscono con un
1089 errore di \errcode{ENOCHLD}.\footnote{questo è anche il motivo per cui le
1090 opzioni \const{WUNTRACED} e \const{WCONTINUED} sono utilizzabili soltanto
1091 qualora non si sia impostato il flag di \const{SA\_NOCLDSTOP} per il segnale
1094 Con i kernel della serie 2.4 e tutti i kernel delle serie precedenti entrambe
1095 le funzioni di attesa ignorano questa prescrizione\footnote{lo standard POSIX.1
1096 originale infatti lascia indefinito il comportamento di queste funzioni
1097 quando \signal{SIGCHLD} viene ignorato.} e si comportano sempre nello stesso
1098 modo, indipendentemente dal fatto \signal{SIGCHLD} sia ignorato o meno:
1099 attendono la terminazione di un processo figlio e ritornano il relativo
1100 \acr{pid} e lo stato di terminazione nell'argomento \param{status}.
1105 \begin{tabular}[c]{|l|p{10cm}|}
1107 \textbf{Macro} & \textbf{Descrizione}\\
1110 \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo
1111 figlio che sia terminato normalmente. \\
1112 \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
1113 stato di uscita del processo (passato attraverso
1114 \func{\_exit}, \func{exit} o come valore di
1115 ritorno di \func{main}); può essere valutata solo
1116 se \val{WIFEXITED} ha restituito un valore non
1118 \macro{WIFSIGNALED(s)} & Condizione vera se il processo figlio è terminato
1119 in maniera anomala a causa di un segnale che non
1120 è stato catturato (vedi
1121 sez.~\ref{sec:sig_notification}).\\
1122 \macro{WTERMSIG(s)} & Restituisce il numero del segnale che ha causato
1123 la terminazione anomala del processo; può essere
1124 valutata solo se \val{WIFSIGNALED} ha restituito
1125 un valore non nullo.\\
1126 \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
1127 file di \itindex{core~dump} \textit{core
1128 dump}; può essere valutata solo se
1129 \val{WIFSIGNALED} ha restituito un valore non
1130 nullo.\footnotemark \\
1131 \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
1132 \func{waitpid} è bloccato; l'uso è possibile solo
1133 con \func{waitpid} avendo specificato l'opzione
1134 \const{WUNTRACED}.\\
1135 \macro{WSTOPSIG(s)} & Restituisce il numero del segnale che ha bloccato
1136 il processo; può essere valutata solo se
1137 \val{WIFSTOPPED} ha restituito un valore non
1139 \macro{WIFCONTINUED(s)}& Vera se il processo che ha causato il ritorno è
1140 stato riavviato da un
1141 \signal{SIGCONT}.\footnotemark \\
1144 \caption{Descrizione delle varie macro di preprocessore utilizzabili per
1145 verificare lo stato di terminazione \var{s} di un processo.}
1146 \label{tab:proc_status_macro}
1149 \footnotetext[20]{questa macro non è definita dallo standard POSIX.1-2001, ma è
1150 presente come estensione sia in Linux che in altri Unix, deve essere
1151 pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un
1152 blocco \texttt{\#ifdef WCOREDUMP ... \#endif}.}
1154 \footnotetext{è presente solo a partire dal kernel 2.6.10.}
1156 In generale in un programma non si vuole essere forzati ad attendere la
1157 conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
1158 questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente
1159 la presenza di \itindex{zombie} \textit{zombie}).
1161 Per questo la modalità più comune di chiamare queste funzioni è quella di
1162 utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
1163 come gestire \signal{SIGCHLD} con i segnali in sez.~\ref{sec:sig_example}). In
1164 questo caso infatti, dato che il segnale è generato dalla terminazione di un
1165 figlio, avremo la certezza che la chiamata a \func{waitpid} non si bloccherà.
1167 Come accennato sia \func{wait} che \func{waitpid} restituiscono lo stato di
1168 terminazione del processo tramite il puntatore \param{status} (se non
1169 interessa memorizzare lo stato si può passare un puntatore nullo). Il valore
1170 restituito da entrambe le funzioni dipende dall'implementazione, ma
1171 tradizionalmente alcuni bit (in genere 8) sono riservati per memorizzare lo
1172 stato di uscita, e altri per indicare il segnale che ha causato la
1173 terminazione (in caso di conclusione anomala), uno per indicare se è stato
1174 generato un \itindex{core~dump} \textit{core dump}, ecc.\footnote{le
1175 definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
1176 questo file non deve mai essere usato direttamente, esso viene incluso
1177 attraverso \file{<sys/wait.h>}.}
1179 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
1180 analizzare lo stato di uscita. Esse sono definite sempre in
1181 \file{<sys/wait.h>} ed elencate in tab.~\ref{tab:proc_status_macro}; si tenga
1182 presente che queste macro prevedono che gli si passi come parametro la
1183 variabile di tipo \ctyp{int} puntata dall'argomento \param{status} restituito
1184 da \func{wait} o \func{waitpid}.
1186 Si tenga conto che nel caso di conclusione anomala il valore restituito da
1187 \val{WTERMSIG} può essere confrontato con le costanti che identificano i
1188 segnali definite in \file{signal.h} ed elencate in
1189 tab.~\ref{tab:sig_signal_list}, e stampato usando le apposite funzioni
1190 trattate in sez.~\ref{sec:sig_strsignal}.
1192 A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è
1193 stata introdotta una nuova funzione di attesa che consente di avere un
1194 controllo molto più preciso sui possibili cambiamenti di stato dei processi
1195 figli e più dettagli sullo stato di uscita; la funzione è \funcd{waitid} ed il
1201 \fdecl{int waitid(idtype\_t idtype, id\_t id, siginfo\_t *infop, int options)}
1202 \fdesc{Attende il cambiamento di stato di un processo figlio.}
1204 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1205 caso \var{errno} assumerà uno dei valori:
1207 \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
1208 la funzione è stata interrotta da un segnale.
1209 \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
1210 non è figlio del processo chiamante.
1211 \item[\errcode{EINVAL}] si è specificato un valore non valido per
1212 l'argomento \param{options}.
1216 La funzione prevede che si specifichi quali processi si intendono osservare
1217 usando i due argomenti \param{idtype} ed \param{id}; il primo indica se ci si
1218 vuole porre in attesa su un singolo processo, un gruppo di processi o un
1219 processo qualsiasi, e deve essere specificato secondo uno dei valori di
1220 tab.~\ref{tab:proc_waitid_idtype}; il secondo indica, a seconda del valore del
1221 primo, quale processo o quale gruppo di processi selezionare.
1226 \begin{tabular}[c]{|l|p{8cm}|}
1228 \textbf{Valore} & \textbf{Descrizione}\\
1231 \const{P\_PID} & Indica la richiesta di attendere per un processo figlio
1232 il cui \acr{pid} corrisponda al valore dell'argomento
1234 \const{P\_PGID}& Indica la richiesta di attendere per un processo figlio
1235 appartenente al \textit{process group} (vedi
1236 sez.~\ref{sec:sess_proc_group}) il cui \acr{pgid}
1237 corrisponda al valore dell'argomento \param{id}.\\
1238 \const{P\_ALL} & Indica la richiesta di attendere per un processo figlio
1239 generico, il valore dell'argomento \param{id} viene
1243 \caption{Costanti per i valori dell'argomento \param{idtype} della funzione
1245 \label{tab:proc_waitid_idtype}
1248 Come per \func{waitpid} anche il comportamento di \func{waitid} viene
1249 controllato dall'argomento \param{options}, da specificare come maschera
1250 binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
1251 alcuni di questi siano identici come significato ed effetto ai precedenti di
1252 tab.~\ref{tab:proc_waitpid_options}, ci sono delle differenze significative:
1253 in questo caso si dovrà specificare esplicitamente l'attesa della terminazione
1254 di un processo impostando l'opzione \const{WEXITED}, mentre il precedente
1255 \const{WUNTRACED} è sostituito da \const{WSTOPPED}. Infine è stata aggiunta
1256 l'opzione \const{WNOWAIT} che consente una lettura dello stato mantenendo il
1257 processo in attesa di ricezione, così che una successiva chiamata possa di
1258 nuovo riceverne lo stato.
1263 \begin{tabular}[c]{|l|p{8cm}|}
1265 \textbf{Valore} & \textbf{Descrizione}\\
1268 \const{WEXITED} & Ritorna quando un processo figlio è terminato.\\
1269 \const{WNOHANG} & Ritorna immediatamente anche se non c'è niente da
1271 \const{WSTOPPED} & Ritorna quando un processo figlio è stato fermato.\\
1272 \const{WCONTINUED}& Ritorna quando un processo figlio che era stato
1273 fermato ha ripreso l'esecuzione.\\
1274 \const{WNOWAIT} & Lascia il processo ancora in attesa di ricezione, così
1275 che una successiva chiamata possa di nuovo riceverne
1279 \caption{Costanti che identificano i bit dell'argomento \param{options}
1280 della funzione \func{waitid}.}
1281 \label{tab:proc_waitid_options}
1284 La funzione \func{waitid} restituisce un valore nullo in caso di successo, e
1285 $-1$ in caso di errore; viene restituito un valore nullo anche se è stata
1286 specificata l'opzione \const{WNOHANG} e la funzione è ritornata immediatamente
1287 senza che nessun figlio sia terminato. Pertanto per verificare il motivo del
1288 ritorno della funzione occorre analizzare le informazioni che essa
1289 restituisce; queste, al contrario delle precedenti \func{wait} e
1290 \func{waitpid} che usavano un semplice valore numerico, sono ritornate in una
1291 struttura di tipo \struct{siginfo\_t} (vedi fig.~\ref{fig:sig_siginfo_t})
1292 all'indirizzo puntato dall'argomento \param{infop}.
1294 Tratteremo nei dettagli la struttura \struct{siginfo\_t} ed il significato dei
1295 suoi vari campi in sez.~\ref{sec:sig_sigaction}, per quanto ci interessa qui
1296 basta dire che al ritorno di \func{waitid} verranno avvalorati i seguenti
1298 \begin{basedescript}{\desclabelwidth{2.0cm}}
1299 \item[\var{si\_pid}] con il \acr{pid} del figlio.
1300 \item[\var{si\_uid}] con l'user-ID reale (vedi sez.~\ref{sec:proc_perms}) del
1302 \item[\var{si\_signo}] con \signal{SIGCHLD}.
1303 \item[\var{si\_status}] con lo stato di uscita del figlio o con il segnale che
1304 lo ha terminato, fermato o riavviato.
1305 \item[\var{si\_code}] con uno fra \const{CLD\_EXITED}, \const{CLD\_KILLED},
1306 \const{CLD\_STOPPED}, \const{CLD\_CONTINUED}, \const{CLD\_TRAPPED} e
1307 \const{CLD\_DUMPED} a indicare la ragione del ritorno della funzione, il cui
1308 significato è, nell'ordine: uscita normale, terminazione da segnale,
1309 processo fermato, processo riavviato, processo terminato in \textit{core
1313 Infine Linux, seguendo un'estensione di BSD, supporta altre due funzioni per
1314 la lettura dello stato di terminazione di un processo, analoghe alle
1315 precedenti ma che prevedono un ulteriore argomento attraverso il quale il
1316 kernel può restituire al padre informazioni sulle risorse (vedi
1317 sez.~\ref{sec:sys_res_limits}) usate dal processo terminato e dai vari figli.
1318 Le due funzioni sono \funcd{wait3} e \funcd{wait4}, che diventano accessibili
1319 definendo la macro \macro{\_USE\_BSD}; i loro prototipi sono:
1324 \fhead{sys/resource.h}
1326 \fdecl{int wait4(pid\_t pid, int *status, int options, struct rusage *rusage))}
1327 \fdesc{Attende il cambiamento di stato di un processo figlio, riportando l'uso
1330 {La funzione ha gli stessi valori di ritorno e codici di errore di
1336 \headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
1337 \headdecl{sys/resource.h}
1339 \funcdecl{pid\_t wait4(pid\_t pid, int *status, int options, struct rusage
1341 È identica a \func{waitpid} sia per comportamento che per i valori degli
1342 argomenti, ma restituisce in \param{rusage} un sommario delle risorse usate
1345 \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
1346 Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è
1347 ormai deprecata in favore di \func{wait4}.
1350 la struttura \struct{rusage} è definita in \file{sys/resource.h}, e viene
1351 utilizzata anche dalla funzione \func{getrusage} (vedi
1352 sez.~\ref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
1353 processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
1356 \subsection{La funzione \func{exec} e le funzioni di esecuzione dei programmi}
1357 \label{sec:proc_exec}
1359 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1360 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1361 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1362 processo chiama una di queste funzioni esso viene completamente sostituito dal
1363 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
1364 creato un nuovo processo, la funzione semplicemente rimpiazza lo
1365 \itindex{stack} \textit{stack}, lo \itindex{heap} \textit{heap}, i
1366 \index{segmento!dati} dati ed il \index{segmento!testo} testo del processo
1367 corrente con un nuovo programma letto da disco.
1369 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1370 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1371 (come mostrato in fig.~\ref{fig:proc_exec_relat}), sono tutte un front-end a
1372 \funcd{execve}. Il prototipo di quest'ultima è:
1373 \begin{prototype}{unistd.h}
1374 {int execve(const char *filename, char *const argv[], char *const envp[])}
1375 Esegue il programma contenuto nel file \param{filename}.
1377 \bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel
1378 qual caso \var{errno} può assumere i valori:
1380 \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è
1381 montato in \cmd{noexec}, oppure non è un file regolare o un interprete.
1382 \item[\errcode{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o
1383 \itindex{sgid~bit} \acr{sgid}, l'utente non è root, il processo viene
1384 tracciato, o il filesystem è montato con l'opzione \cmd{nosuid}.
1385 \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
1386 riconosciuto come tale, o compilato per un'altra architettura.
1387 \item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1388 necessari per eseguirlo non esistono.
1389 \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
1391 \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
1392 \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
1394 \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
1396 \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
1398 ed inoltre anche \errval{EFAULT}, \errval{ENOMEM}, \errval{EIO},
1399 \errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR}, \errval{ENFILE},
1403 La funzione \func{exec} esegue il file o lo script indicato da
1404 \param{filename}, passandogli la lista di argomenti indicata da \param{argv}
1405 e come ambiente la lista di stringhe indicata da \param{envp}; entrambe le
1406 liste devono essere terminate da un puntatore nullo. I vettori degli
1407 argomenti e dell'ambiente possono essere acceduti dal nuovo programma
1408 quando la sua funzione \func{main} è dichiarata nella forma
1409 \code{main(int argc, char *argv[], char *envp[])}.
1411 Le altre funzioni della famiglia servono per fornire all'utente una serie di
1412 possibili diverse interfacce per la creazione di un nuovo processo. I loro
1416 \funcdecl{int execl(const char *path, const char *arg, ...)}
1417 \funcdecl{int execv(const char *path, char *const argv[])}
1418 \funcdecl{int execle(const char *path, const char *arg, ..., char
1420 \funcdecl{int execlp(const char *file, const char *arg, ...)}
1421 \funcdecl{int execvp(const char *file, char *const argv[])}
1423 Sostituiscono l'immagine corrente del processo con quella indicata nel primo
1424 argomento. Gli argomenti successivi consentono di specificare gli argomenti a
1425 linea di comando e l'ambiente ricevuti dal nuovo processo.
1427 \bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1;
1428 nel qual caso \var{errno} assumerà i valori visti in precedenza per
1432 Per capire meglio le differenze fra le funzioni della famiglia si può fare
1433 riferimento allo specchietto riportato in tab.~\ref{tab:proc_exec_scheme}. La
1434 prima differenza riguarda le modalità di passaggio dei valori che poi andranno
1435 a costituire gli argomenti a linea di comando (cioè i valori di
1436 \param{argv} e \param{argc} visti dalla funzione \func{main} del programma
1439 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
1440 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
1441 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
1442 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
1443 questo vettore \emph{deve} essere terminato da un puntatore nullo.
1445 Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
1446 lista di puntatori, nella forma:
1447 \includecodesnip{listati/char_list.c}
1448 che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
1449 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1450 per indicare il nome del file che contiene il programma che verrà eseguito.
1455 \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1457 \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
1458 \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1460 &\func{execl}\texttt{ }&\func{execlp}&\func{execle}
1461 &\func{execv}\texttt{ }& \func{execvp}& \func{execve} \\
1464 argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
1465 argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
1467 filename completo &$\bullet$&&$\bullet$&$\bullet$&&$\bullet$\\
1468 ricerca su \var{PATH} &&$\bullet$&&&$\bullet$& \\
1470 ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
1471 uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1474 \caption{Confronto delle caratteristiche delle varie funzioni della
1475 famiglia \func{exec}.}
1476 \label{tab:proc_exec_scheme}
1479 La seconda differenza fra le funzioni riguarda le modalità con cui si
1480 specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
1481 indicano le due funzioni che replicano il comportamento della shell nello
1482 specificare il comando da eseguire; quando l'argomento \param{file} non
1483 contiene una ``\texttt{/}'' esso viene considerato come un nome di programma,
1484 e viene eseguita automaticamente una ricerca fra i file presenti nella lista
1485 di directory specificate dalla variabile di ambiente \var{PATH}. Il file che
1486 viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
1487 relativo a permessi di accesso insufficienti (cioè l'esecuzione della
1488 sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
1489 proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se
1490 non viene trovato nessun altro file viene finalmente restituito
1493 Le altre quattro funzioni si limitano invece a cercare di eseguire il file
1494 indicato dall'argomento \param{path}, che viene interpretato come il
1495 \itindex{pathname} \textit{pathname} del programma.
1497 \begin{figure}[!htb]
1498 \centering \includegraphics[width=12cm]{img/exec_rel}
1499 \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
1500 \label{fig:proc_exec_relat}
1503 La terza differenza è come viene passata la lista delle variabili di ambiente.
1504 Con lo mnemonico \texttt{e} vengono indicate quelle funzioni che necessitano
1505 di un vettore di parametri \var{envp[]} analogo a quello usato per gli
1506 argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre
1507 usano il valore della variabile \var{environ} (vedi
1508 sez.~\ref{sec:proc_environ}) del processo di partenza per costruire
1511 Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
1512 \func{exec} mantiene la gran parte delle proprietà del processo chiamante; una
1513 lista delle più significative è la seguente:
1515 \item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
1517 \item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i
1518 \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
1519 \item il \textit{session ID} (\acr{sid}) ed il \itindex{process~group}
1520 \textit{process group ID} (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group};
1521 \item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term});
1522 \item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
1523 \item la directory radice e la directory di lavoro corrente (vedi
1524 sez.~\ref{sec:file_work_dir});
1525 \item la maschera di creazione dei file \itindex{umask} (\textit{umask}, vedi
1526 sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
1527 sez.~\ref{sec:file_locking});
1528 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
1529 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime};
1530 \var{tms\_cutime}, \var{tms\_ustime} (vedi sez.~\ref{sec:sys_cpu_times});
1531 % TODO ===========Importante=============
1532 % TODO questo sotto è incerto, verificare
1533 % TODO ===========Importante=============
1534 \item la maschera dei segnali (si veda sez.~\ref{sec:sig_sigmask}).
1537 Una serie di proprietà del processo originale, che non avrebbe senso mantenere
1538 in un programma che esegue un codice completamente diverso in uno spazio di
1539 indirizzi totalmente indipendente e ricreato da zero, vengono perse con
1540 l'esecuzione di \func{exec}; lo standard POSIX.1-2001 prevede che le seguenti
1541 proprietà non vengano preservate:
1543 \item l'insieme dei segnali pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che
1545 \item gli eventuali stack alternativi per i segnali (vedi
1546 sez.~\ref{sec:sig_specific_features});
1547 \item i \textit{directory stream} (vedi sez.~\ref{sec:file_dir_read}), che
1549 \item le mappature dei file in memoria (vedi sez.~\ref{sec:file_memory_map});
1550 \item i segmenti di memoria condivisa SysV (vedi sez.~\ref{sec:ipc_sysv_shm})
1551 e POSIX (vedi sez.~\ref{sec:ipc_posix_shm});
1552 \item i blocchi sulla memoria (vedi sez.~\ref{sec:proc_mem_lock});
1553 \item le funzioni registrate all'uscita (vedi sez.~\ref{sec:proc_atexit});
1554 \item i semafori e le code di messaggi POSIX (vedi
1555 sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq});
1556 \item i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}).
1559 I segnali che sono stati impostati per essere ignorati nel processo chiamante
1560 mantengono la stessa impostazione pure nel nuovo programma, ma tutti gli altri
1561 segnali, ed in particolare quelli per i quali è stato installato un gestore
1562 vengono impostati alla loro azione predefinita (vedi
1563 sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \signal{SIGCHLD}
1564 che, quando impostato a \const{SIG\_IGN}, potrebbe anche essere reimpostato a
1565 \const{SIG\_DFL}, anche se questo con Linux non avviene.\footnote{lo standard
1566 POSIX.1-2001 prevede che questo comportamento sia deciso dalla singola
1567 implementazione, quella di Linux è di non modificare l'impostazione
1570 Oltre alle precedenti che sono completamente generali e disponibili anche su
1571 altri sistemi unix-like, esistono altre proprietà dei processi, attinenti
1572 caratteristiche specifiche di Linux, che non vengono preservate
1573 nell'esecuzione della funzione \func{exec}, queste sono:
1575 \item le operazione di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io})
1576 pendenti vengono cancellate;
1577 \item le \itindex{capabilities} \textit{capabilities} vengono modificate come
1578 illustrato in sez.~\ref{sec:proc_capabilities};
1579 \item tutti i \itindex{thread} \textit{thread} tranne il chiamante (vedi
1580 sez.~\ref{sec:thread_xxx}) sono cancellati e tutti gli oggetti ad essi
1581 relativi (vedi sez.~\ref{sec:thread_xxx}) rimossi;
1582 \item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi
1583 sez.~\ref{sec:process_prctl}) a meno che il programma da eseguire non sia
1584 \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} (vedi
1585 sez.~\ref{sec:proc_access_id});
1586 \item il flag \const{PR\_SET\_KEEPCAPS} di \func{prctl} (vedi
1587 sez.~\ref{sec:process_prctl}) viene cancellato;
1588 \item il nome del processo viene impostato al nome del file contenente il
1589 programma messo in esecuzione;
1590 \item il segnale di terminazione viene reimpostato a \signal{SIGCHLD};
1591 \item l'ambiente viene reinizializzato impostando le variabili attinenti alla
1592 localizzazione al valore di default POSIX.
1595 La gestione dei file aperti nel passaggio al nuovo programma lanciato con
1596 \func{exec} dipende dal valore che ha il flag di \itindex{close-on-exec}
1597 \textit{close-on-exec} (vedi anche sez.~\ref{sec:file_fcntl}) per ciascun file
1598 descriptor. I file per cui è impostato vengono chiusi, tutti gli altri file
1599 restano aperti. Questo significa che il comportamento predefinito è che i file
1600 restano aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
1601 \func{fcntl} che imposti il suddetto flag. Per le directory, lo standard
1602 POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec}, in genere
1603 questo è fatto dalla funzione \func{opendir} (vedi
1604 sez.~\ref{sec:file_dir_read}) che effettua da sola l'impostazione del flag di
1605 \itindex{close-on-exec} \textit{close-on-exec} sulle directory che apre, in
1606 maniera trasparente all'utente.
1608 Il comportamento della funzione in relazione agli identificatori relativi al
1609 controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms},
1610 qui è sufficiente anticipare (si faccia riferimento a
1611 sez.~\ref{sec:proc_access_id} per la definizione di questi identificatori)
1612 come l'\textsl{user-ID reale} ed il \textsl{group-ID reale} restano sempre gli
1613 stessi, mentre l'\textsl{user-ID salvato} ed il \textsl{group-ID salvato}
1614 vengono impostati rispettivamente all'\textsl{user-ID effettivo} ed il
1615 \textsl{group-ID effettivo}, questi ultimi normalmente non vengono modificati,
1616 a meno che il file di cui viene chiesta l'esecuzione non abbia o il
1617 \itindex{suid~bit} \acr{suid} bit o lo \itindex{sgid~bit} \acr{sgid} bit
1618 impostato, in questo caso l'\textsl{user-ID effettivo} ed il \textsl{group-ID
1619 effettivo} vengono impostati rispettivamente all'utente o al gruppo cui il
1622 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1623 condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
1624 del programma per caricare le librerie necessarie ed effettuare il link
1625 dell'eseguibile.\footnote{il formato è ormai in completo disuso, per cui è
1626 molto probabile che non il relativo supporto non sia disponibile.} Se il
1627 programma è in formato ELF per caricare le librerie dinamiche viene usato
1628 l'interprete indicato nel segmento \const{PT\_INTERP} previsto dal formato
1629 stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi
1630 collegati con le \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
1631 collegati con le \acr{glibc}.
1633 Infine nel caso il file sia uno script esso deve iniziare con una linea nella
1634 forma \cmd{\#!/path/to/interpreter [argomenti]} dove l'interprete indicato
1635 deve essere un programma valido (binario, non un altro script) che verrà
1636 chiamato come se si fosse eseguito il comando \cmd{interpreter [argomenti]
1637 filename}.\footnote{si tenga presente che con Linux quanto viene scritto
1638 come \texttt{argomenti} viene passato all'interprete come un unico argomento
1639 con una unica stringa di lunghezza massima di 127 caratteri e se questa
1640 dimensione viene ecceduta la stringa viene troncata; altri Unix hanno
1641 dimensioni massime diverse, e diversi comportamenti, ad esempio FreeBSD
1642 esegue la scansione della riga e la divide nei vari argomenti e se è troppo
1643 lunga restituisce un errore di \const{ENAMETOOLONG}, una comparazione dei
1644 vari comportamenti si trova su
1645 \href{http://www.in-ulm.de/~mascheck/various/shebang/}
1646 {\textsf{http://www.in-ulm.de/\tild mascheck/various/shebang/}}.}
1648 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1649 basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
1650 processo, con \func{exec} si lancia un nuovo programma, con \func{exit} e
1651 \func{wait} si effettua e verifica la conclusione dei processi. Tutte le
1652 altre funzioni sono ausiliarie e servono per la lettura e l'impostazione dei
1653 vari parametri connessi ai processi.
1657 \section{Il controllo di accesso}
1658 \label{sec:proc_perms}
1660 In questa sezione esamineremo le problematiche relative al controllo di
1661 accesso dal punto di vista dei processi; vedremo quali sono gli identificatori
1662 usati, come questi possono essere modificati nella creazione e nel lancio di
1663 nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
1664 problematiche connesse ad una gestione accorta dei privilegi.
1667 \subsection{Gli identificatori del controllo di accesso}
1668 \label{sec:proc_access_id}
1670 Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in
1671 realtà già esistono estensioni di questo modello base, che lo rendono più
1672 flessibile e controllabile, come le \itindex{capabilities}
1673 \textit{capabilities} illustrate in sez.~\ref{sec:proc_capabilities}, le ACL
1674 per i file (vedi sez.~\ref{sec:file_ACL}) o il
1675 \itindex{Mandatory~Access~Control~(MAC)} \textit{Mandatory Access Control}
1676 di \index{SELinux} SELinux; inoltre basandosi sul lavoro effettuato con
1677 SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
1678 infrastruttura di sicurezza, i \itindex{Linux~Security~Modules}
1679 \textit{Linux Security Modules}, o LSM, in grado di fornire diversi agganci
1680 a livello del kernel per modularizzare tutti i possibili controlli di
1681 accesso.} di sicurezza di un sistema unix-like è fondato sui concetti di
1682 utente e gruppo, e sulla separazione fra l'amministratore (\textsl{root},
1683 detto spesso anche \textit{superuser}) che non è sottoposto a restrizioni, ed
1684 il resto degli utenti, per i quali invece vengono effettuati i vari controlli
1687 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1688 identificatori univoci, lo user-ID ed il group-ID; questi servono al kernel per
1689 identificare uno specifico utente o un gruppo di utenti, per poi poter
1690 controllare che essi siano autorizzati a compiere le operazioni richieste. Ad
1691 esempio in sez.~\ref{sec:file_access_control} vedremo come ad ogni file vengano
1692 associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati
1693 appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal
1694 kernel nella gestione dei permessi di accesso.
1696 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1697 evidente che per poter implementare un controllo sulle operazioni occorre
1698 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1699 anche a ciascun processo dovrà essere associato un utente e un gruppo.
1701 Un semplice controllo di una corrispondenza fra identificativi non garantisce
1702 però sufficiente flessibilità per tutti quei casi in cui è necessario poter
1703 disporre di privilegi diversi, o dover impersonare un altro utente per un
1704 limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix
1705 prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati
1706 rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed
1707 \textsl{effettivi}). Nel caso di Linux si aggiungono poi altri due gruppi, il
1708 \textit{saved} (\textsl{salvati}) ed il \textit{filesystem} (\textsl{di
1709 filesystem}), secondo la situazione illustrata in
1710 tab.~\ref{tab:proc_uid_gid}.
1715 \begin{tabular}[c]{|c|c|l|p{7.3cm}|}
1717 \textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione}
1718 & \textbf{Significato} \\
1721 \acr{uid} & \textit{real} & \textsl{user-ID reale}
1722 & Indica l'utente che ha lanciato il programma.\\
1723 \acr{gid} & '' &\textsl{group-ID reale}
1724 & Indica il gruppo principale dell'utente che ha lanciato
1727 \acr{euid} & \textit{effective} &\textsl{user-ID effettivo}
1728 & Indica l'utente usato nel controllo di accesso.\\
1729 \acr{egid} & '' & \textsl{group-ID effettivo}
1730 & Indica il gruppo usato nel controllo di accesso.\\
1731 -- & -- & \textsl{group-ID supplementari}
1732 & Indicano gli ulteriori gruppi cui l'utente appartiene.\\
1734 -- & \textit{saved} & \textsl{user-ID salvato}
1735 & È una copia dell'\acr{euid} iniziale.\\
1736 -- & '' & \textsl{group-ID salvato}
1737 & È una copia dell'\acr{egid} iniziale.\\
1739 \acr{fsuid} & \textit{filesystem} &\textsl{user-ID di filesystem}
1740 & Indica l'utente effettivo per l'accesso al filesystem. \\
1741 \acr{fsgid} & '' & \textsl{group-ID di filesystem}
1742 & Indica il gruppo effettivo per l'accesso al filesystem.\\
1745 \caption{Identificatori di utente e gruppo associati a ciascun processo con
1746 indicazione dei suffissi usati dalle varie funzioni di manipolazione.}
1747 \label{tab:proc_uid_gid}
1750 Al primo gruppo appartengono l'\textsl{user-ID reale} ed il \textsl{group-ID
1751 reale}: questi vengono impostati al login ai valori corrispondenti
1752 all'utente con cui si accede al sistema (e relativo gruppo principale).
1753 Servono per l'identificazione dell'utente e normalmente non vengono mai
1754 cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
1755 modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
1756 questa possibilità è usata proprio dal programma \cmd{login} che, una volta
1757 completata la procedura di autenticazione, lancia una shell per la quale
1758 imposta questi identificatori ai valori corrispondenti all'utente che entra
1761 Al secondo gruppo appartengono lo \textsl{user-ID effettivo} ed il
1762 \textsl{group-ID effettivo} (a cui si aggiungono gli eventuali \textsl{group-ID
1763 supplementari} dei gruppi dei quali l'utente fa parte). Questi sono invece
1764 gli identificatori usati nelle verifiche dei permessi del processo e per il
1765 controllo di accesso ai file (argomento affrontato in dettaglio in
1766 sez.~\ref{sec:file_perm_overview}).
1768 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1769 \textit{real} tranne nel caso in cui, come accennato in
1770 sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
1771 bit \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} impostati
1772 (il significato di questi bit è affrontato in dettaglio in
1773 sez.~\ref{sec:file_special_perm}). In questo caso essi saranno impostati
1774 all'utente e al gruppo proprietari del file. Questo consente, per programmi in
1775 cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
1776 di un altro (o dell'amministratore).
1778 Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi
1779 identificatori possono essere letti attraverso le rispettive funzioni:
1780 \funcd{getuid}, \funcd{geteuid}, \funcd{getgid} e \funcd{getegid}, i loro
1784 \headdecl{sys/types.h}
1785 \funcdecl{uid\_t getuid(void)} Restituisce l'\textsl{user-ID reale} del
1788 \funcdecl{uid\_t geteuid(void)} Restituisce l'\textsl{user-ID effettivo} del
1791 \funcdecl{gid\_t getgid(void)} Restituisce il \textsl{group-ID reale} del
1794 \funcdecl{gid\_t getegid(void)} Restituisce il \textsl{group-ID effettivo}
1795 del processo corrente.
1797 \bodydesc{Queste funzioni non riportano condizioni di errore.}
1800 In generale l'uso di privilegi superiori deve essere limitato il più
1801 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1802 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1803 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1804 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1807 Questo in Linux viene fatto usando altri due gruppi di identificatori, il
1808 \textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
1809 SVr4, e previsto dallo standard POSIX quando è definita la costante
1810 \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
1811 del programma su altri Unix è buona norma controllare sempre la
1812 disponibilità di queste funzioni controllando se questa costante è
1813 definita.} il secondo gruppo è specifico di Linux e viene usato per
1814 migliorare la sicurezza con NFS.
1816 L'\textsl{user-ID salvato} ed il \textsl{group-ID salvato} sono copie
1817 dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo} del processo
1818 padre, e vengono impostati dalla funzione \func{exec} all'avvio del processo,
1819 come copie dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo}
1820 dopo che questi sono stati impostati tenendo conto di eventuali
1821 \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid}. Essi quindi
1822 consentono di tenere traccia di quale fossero utente e gruppo effettivi
1823 all'inizio dell'esecuzione di un nuovo programma.
1825 L'\textsl{user-ID di filesystem} e il \textsl{group-ID di filesystem} sono
1826 un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
1827 (torneremo sull'argomento in sez.~\ref{sec:proc_setuid}). Essi sono una
1828 replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
1829 quali si sostituiscono per tutte le operazioni di verifica dei permessi
1830 relativi ai file (trattate in sez.~\ref{sec:file_perm_overview}). Ogni
1831 cambiamento effettuato sugli identificatori effettivi viene automaticamente
1832 riportato su di essi, per cui in condizioni normali si può tranquillamente
1833 ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
1836 \subsection{Le funzioni di gestione degli identificatori dei processi}
1837 \label{sec:proc_setuid}
1839 Le due funzioni più comuni che vengono usate per cambiare identità (cioè
1840 utente e gruppo di appartenenza) ad un processo sono rispettivamente
1841 \funcd{setuid} e \funcd{setgid}; come accennato in
1842 sez.~\ref{sec:proc_access_id} in Linux esse seguono la semantica POSIX che
1843 prevede l'esistenza dell'\textit{user-ID salvato} e del \textit{group-ID
1844 salvato}; i loro prototipi sono:
1847 \headdecl{sys/types.h}
1849 \funcdecl{int setuid(uid\_t uid)} Imposta l'\textsl{user-ID} del processo
1852 \funcdecl{int setgid(gid\_t gid)} Imposta il \textsl{group-ID} del processo
1855 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1856 di fallimento: l'unico errore possibile è \errval{EPERM}.}
1859 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1860 la prima; la seconda si comporta esattamente allo stesso modo facendo
1861 riferimento al \textsl{group-ID} invece che all'\textsl{user-ID}. Gli
1862 eventuali \textsl{group-ID supplementari} non vengono modificati.
1864 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1865 l'\textsl{user-ID effettivo} è zero (cioè è quello dell'amministratore di
1866 sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e
1867 \textit{saved}) vengono impostati al valore specificato da \param{uid},
1868 altrimenti viene impostato solo l'\textsl{user-ID effettivo}, e soltanto se il
1869 valore specificato corrisponde o all'\textsl{user-ID reale} o
1870 all'\textsl{user-ID salvato}. Negli altri casi viene segnalato un errore (con
1873 Come accennato l'uso principale di queste funzioni è quello di poter
1874 consentire ad un programma con i bit \itindex{suid~bit} \acr{suid} o
1875 \itindex{sgid~bit} \acr{sgid} impostati (vedi sez.~\ref{sec:file_special_perm})
1876 di riportare l'\textsl{user-ID effettivo} a quello dell'utente che ha lanciato
1877 il programma, effettuare il lavoro che non necessita di privilegi aggiuntivi,
1878 ed eventualmente tornare indietro.
1880 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
1881 viene gestito l'accesso al file \sysfile{/var/log/utmp}. In questo file viene
1882 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1883 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1884 falsificare la registrazione. Per questo motivo questo file (e l'analogo
1885 \sysfile{/var/log/wtmp} su cui vengono registrati login e logout) appartengono
1886 ad un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
1887 esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che
1888 crea terminali multipli su una console) appartengono a questo gruppo ed hanno
1889 il bit \acr{sgid} impostato.
1891 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
1892 situazione degli identificatori è la seguente:
1895 \textsl{group-ID reale} &=& \textrm{\acr{gid} (del chiamante)} \\
1896 \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
1897 \textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
1899 in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
1900 programma può accedere a \sysfile{/var/log/utmp} in scrittura ed aggiornarlo.
1901 A questo punto il programma può eseguire una \code{setgid(getgid())} per
1902 impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il
1903 \textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
1904 non sarà possibile lanciare dal terminale programmi che modificano detto file,
1905 in tal caso infatti la situazione degli identificatori sarebbe:
1908 \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
1909 \textsl{group-ID effettivo} &=& \textrm{\acr{gid}} \\
1910 \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
1912 e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come
1913 \textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
1914 aggiornare lo stato di \sysfile{/var/log/utmp} il programma eseguirà una
1915 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
1916 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
1917 in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la
1918 funzione avrà successo e riporterà la situazione a:
1921 \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\
1922 \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
1923 \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
1925 consentendo l'accesso a \sysfile{/var/log/utmp}.
1927 Occorre però tenere conto che tutto questo non è possibile con un processo con
1928 i privilegi di amministratore, in tal caso infatti l'esecuzione di una
1929 \func{setuid} comporta il cambiamento di tutti gli identificatori associati al
1930 processo, rendendo impossibile riguadagnare i privilegi di amministratore.
1931 Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che
1932 crea una nuova shell per l'utente; ma quando si vuole cambiare soltanto
1933 l'\textsl{user-ID effettivo} del processo per cedere i privilegi occorre
1934 ricorrere ad altre funzioni.
1936 Le due funzioni \funcd{setreuid} e \funcd{setregid} derivano da BSD che, non
1937 supportando\footnote{almeno fino alla versione 4.3+BSD.} gli identificatori
1938 del gruppo \textit{saved}, le usa per poter scambiare fra di loro
1939 \textit{effective} e \textit{real}. I rispettivi prototipi sono:
1942 \headdecl{sys/types.h}
1944 \funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Imposta l'\textsl{user-ID
1945 reale} e l'\textsl{user-ID effettivo} del processo corrente ai valori
1946 specificati da \param{ruid} e \param{euid}.
1948 \funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Imposta il \textsl{group-ID
1949 reale} ed il \textsl{group-ID effettivo} del processo corrente ai valori
1950 specificati da \param{rgid} e \param{egid}.
1952 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
1953 di fallimento: l'unico errore possibile è \errval{EPERM}.}
1956 La due funzioni sono analoghe ed il loro comportamento è identico; quanto
1957 detto per la prima riguardo l'user-ID, si applica immediatamente alla seconda
1958 per il group-ID. I processi non privilegiati possono impostare solo i valori
1959 del loro user-ID effettivo o reale; valori diversi comportano il fallimento
1960 della chiamata; l'amministratore invece può specificare un valore qualunque.
1961 Specificando un argomento di valore -1 l'identificatore corrispondente verrà
1962 lasciato inalterato.
1964 Con queste funzioni si possono scambiare fra loro gli user-ID reale e
1965 effettivo, e pertanto è possibile implementare un comportamento simile a
1966 quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
1967 scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo
1970 In questo caso però occorre porre molta attenzione quando si creano nuovi
1971 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
1972 questo caso infatti essi avranno un user-ID reale privilegiato, che dovrà
1973 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
1974 programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
1975 prima della \func{exec} per uniformare l'user-ID reale a quello effettivo) in
1976 caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio
1977 e riottenere privilegi non previsti.
1979 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
1980 si pone per l'user-ID salvato: questa funzione deriva da un'implementazione che
1981 non ne prevede la presenza, e quindi non è possibile usarla per correggere la
1982 situazione come nel caso precedente. Per questo motivo in Linux tutte le volte
1983 che si imposta un qualunque valore diverso da quello dall'user-ID reale
1984 corrente, l'user-ID salvato viene automaticamente uniformato al valore
1985 dell'user-ID effettivo.
1987 Altre due funzioni, \funcd{seteuid} e \funcd{setegid}, sono un'estensione
1988 dello standard POSIX.1, ma sono comunque supportate dalla maggior parte degli
1989 Unix; esse vengono usate per cambiare gli identificatori del gruppo
1990 \textit{effective} ed i loro prototipi sono:
1993 \headdecl{sys/types.h}
1995 \funcdecl{int seteuid(uid\_t uid)} Imposta l'user-ID effettivo del processo
1996 corrente a \param{uid}.
1998 \funcdecl{int setegid(gid\_t gid)} Imposta il group-ID effettivo del processo
1999 corrente a \param{gid}.
2001 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
2002 di fallimento: l'unico errore è \errval{EPERM}.}
2005 Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo
2006 la prima. Gli utenti normali possono impostare l'user-ID effettivo solo al
2007 valore dell'user-ID reale o dell'user-ID salvato, l'amministratore può
2008 specificare qualunque valore. Queste funzioni sono usate per permettere
2009 all'amministratore di impostare solo l'user-ID effettivo, dato che l'uso
2010 normale di \func{setuid} comporta l'impostazione di tutti gli identificatori.
2013 Le due funzioni \funcd{setresuid} e \funcd{setresgid} sono invece
2014 un'estensione introdotta in Linux,\footnote{per essere precisi a partire dal
2015 kernel 2.1.44.} e permettono un completo controllo su tutti e tre i gruppi
2016 di identificatori (\textit{real}, \textit{effective} e \textit{saved}), i loro
2020 \headdecl{sys/types.h}
2022 \funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Imposta
2023 l'user-ID reale, l'user-ID effettivo e l'user-ID salvato del processo corrente
2024 ai valori specificati rispettivamente da \param{ruid}, \param{euid} e
2027 \funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Imposta il
2028 group-ID reale, il group-ID effettivo ed il group-ID salvato del processo
2029 corrente ai valori specificati rispettivamente da \param{rgid}, \param{egid} e
2032 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
2033 di fallimento: l'unico errore è \errval{EPERM}.}
2036 Le due funzioni sono identiche, quanto detto per la prima riguardo gli user-ID
2037 si applica alla seconda per i group-ID. I processi non privilegiati possono
2038 cambiare uno qualunque degli user-ID solo ad un valore corrispondente o
2039 all'user-ID reale, o a quello effettivo o a quello salvato, l'amministratore
2040 può specificare i valori che vuole; un valore di -1 per un qualunque argomento
2041 lascia inalterato l'identificatore corrispondente.
2043 Per queste funzioni esistono anche due controparti che permettono di leggere
2044 in blocco i vari identificatori: \funcd{getresuid} e \funcd{getresgid}; i loro
2048 \headdecl{sys/types.h}
2050 \funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge
2051 l'user-ID reale, l'user-ID effettivo e l'user-ID salvato del processo corrente.
2053 \funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il
2054 group-ID reale, il group-ID effettivo e il group-ID salvato del processo
2057 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
2058 fallimento: l'unico errore possibile è \errval{EFAULT} se gli indirizzi delle
2059 variabili di ritorno non sono validi.}
2062 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
2063 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
2064 specificati come puntatori (è un altro esempio di
2065 \itindex{value~result~argument} \textit{value result argument}). Si noti che
2066 queste funzioni sono le uniche in grado di leggere gli identificatori del
2067 gruppo \textit{saved}.
2070 Infine le funzioni \func{setfsuid} e \func{setfsgid} servono per impostare gli
2071 identificatori del gruppo \textit{filesystem} che sono usati da Linux per il
2072 controllo dell'accesso ai file. Come già accennato in
2073 sez.~\ref{sec:proc_access_id} Linux definisce questo ulteriore gruppo di
2074 identificatori, che in circostanze normali sono assolutamente equivalenti a
2075 quelli del gruppo \textit{effective}, dato che ogni cambiamento di questi
2076 ultimi viene immediatamente riportato su di essi.
2078 C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
2079 identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
2080 ovviare ad un problema di sicurezza che si presenta quando si deve
2081 implementare un server NFS.
2083 Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai
2084 file per assumere l'identità del singolo utente remoto, ma se questo viene
2085 fatto cambiando l'user-ID effettivo o l'user-ID reale il server si espone alla
2086 ricezione di eventuali segnali ostili da parte dell'utente di cui ha
2087 temporaneamente assunto l'identità. Cambiando solo l'user-ID di filesystem si
2088 ottengono i privilegi necessari per accedere ai file, mantenendo quelli
2089 originari per quanto riguarda tutti gli altri controlli di accesso, così che
2090 l'utente non possa inviare segnali al server NFS.
2092 Le due funzioni usate per cambiare questi identificatori sono \funcd{setfsuid}
2093 e \funcd{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
2094 usate se si intendono scrivere programmi portabili; i loro prototipi sono:
2096 \headdecl{sys/fsuid.h}
2098 \funcdecl{int setfsuid(uid\_t fsuid)} Imposta l'user-ID di filesystem del
2099 processo corrente a \param{fsuid}.
2101 \funcdecl{int setfsgid(gid\_t fsgid)} Imposta il group-ID di filesystem del
2102 processo corrente a \param{fsgid}.
2104 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
2105 di fallimento: l'unico errore possibile è \errval{EPERM}.}
2107 \noindent queste funzioni hanno successo solo se il processo chiamante ha i
2108 privilegi di amministratore o, per gli altri utenti, se il valore specificato
2109 coincide con uno dei di quelli del gruppo \textit{real}, \textit{effective} o
2113 \subsection{Le funzioni per la gestione dei gruppi associati a un processo}
2114 \label{sec:proc_setgroups}
2116 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
2117 gruppi supplementari cui un utente può appartenere. Ogni processo può avere
2118 almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
2119 gruppi secondari può essere ottenuto con \func{sysconf} (vedi
2120 sez.~\ref{sec:sys_sysconf}), leggendo il parametro
2121 \texttt{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
2122 ereditati dal processo padre e possono essere cambiati con queste funzioni.
2124 La funzione che permette di leggere i gruppi supplementari associati ad un
2125 processo è \funcd{getgroups}; questa funzione è definita nello standard
2126 POSIX.1, ed il suo prototipo è:
2128 \headdecl{sys/types.h}
2131 \funcdecl{int getgroups(int size, gid\_t list[])}
2133 Legge gli identificatori dei gruppi supplementari.
2135 \bodydesc{La funzione restituisce il numero di gruppi letti in caso di
2136 successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà
2139 \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
2140 \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
2141 minore del numero di gruppi supplementari del processo.
2145 La funzione legge gli identificatori dei gruppi supplementari del processo sul
2146 vettore \param{list} di dimensione \param{size}. Non è specificato se la
2147 funzione inserisca o meno nella lista il group-ID effettivo del processo. Se si
2148 specifica un valore di \param{size} uguale a 0 \param{list} non viene
2149 modificato, ma si ottiene il numero di gruppi supplementari.
2151 Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
2152 ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo è:
2154 \headdecl{sys/types.h}
2157 \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups,
2158 int *ngroups)} Legge i gruppi supplementari.
2160 \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori,
2161 restituisce 0 in caso di successo e -1 in caso di fallimento.}
2164 La funzione legge i gruppi supplementari dell'utente specificato da
2165 \param{user}, eseguendo una scansione del database dei gruppi (si veda
2166 sez.~\ref{sec:sys_user_group}). Ritorna poi in \param{groups} la lista di
2167 quelli a cui l'utente appartiene. Si noti che \param{ngroups} è passato come
2168 puntatore perché, qualora il valore specificato sia troppo piccolo, la
2169 funzione ritorna -1, passando indietro il numero dei gruppi trovati.
2171 Per impostare i gruppi supplementari di un processo ci sono due funzioni, che
2172 possono essere usate solo se si hanno i privilegi di amministratore. La prima
2173 delle due è \funcd{setgroups}, ed il suo prototipo è:
2175 \headdecl{sys/types.h}
2178 \funcdecl{int setgroups(size\_t size, gid\_t *list)}
2180 Imposta i gruppi supplementari del processo.
2182 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2183 fallimento, nel qual caso \var{errno} assumerà i valori:
2185 \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
2186 \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
2187 \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
2192 La funzione imposta i gruppi supplementari del processo corrente ai valori
2193 specificati nel vettore passato con l'argomento \param{list}, di dimensioni
2194 date dall'argomento \param{size}. Il numero massimo di gruppi supplementari è
2195 un parametro di sistema, che può essere ricavato con le modalità spiegate in
2196 sez.~\ref{sec:sys_characteristics}.
2198 Se invece si vogliono impostare i gruppi supplementari del processo a quelli di
2199 un utente specifico, si può usare \funcd{initgroups} il cui prototipo è:
2201 \headdecl{sys/types.h}
2204 \funcdecl{int initgroups(const char *user, gid\_t group)}
2206 Inizializza la lista dei gruppi supplementari.
2208 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2209 fallimento, nel qual caso \var{errno} assumerà gli stessi valori di
2210 \func{setgroups} più \errval{ENOMEM} quando non c'è memoria sufficiente
2211 per allocare lo spazio per informazioni dei gruppi.}
2214 La funzione esegue la scansione del database dei gruppi (usualmente
2215 \conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
2216 con cui costruisce una lista di gruppi supplementari, a cui aggiunge anche
2217 \param{group}, infine imposta questa lista per il processo corrente usando
2218 \func{setgroups}. Si tenga presente che sia \func{setgroups} che
2219 \func{initgroups} non sono definite nello standard POSIX.1 e che pertanto non
2220 è possibile utilizzarle quando si definisce \macro{\_POSIX\_SOURCE} o si
2221 compila con il flag \cmd{-ansi}, è pertanto meglio evitarle se si vuole
2222 scrivere codice portabile.
2225 \section{La gestione della priorità dei processi}
2226 \label{sec:proc_priority}
2228 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
2229 lo \itindex{scheduler} \textit{scheduler} assegna la CPU ai vari processi
2230 attivi. In particolare prenderemo in esame i vari meccanismi con cui viene
2231 gestita l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di
2232 gestione. Tratteremo infine anche le altre priorità dei processi (come quelle
2233 per l'accesso a disco) divenute disponibili con i kernel più recenti.
2236 \subsection{I meccanismi di \textit{scheduling}}
2237 \label{sec:proc_sched}
2239 \itindbeg{scheduler}
2241 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
2242 il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
2243 ed oggetto di numerose ricerche; in generale essa dipende in maniera
2244 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
2245 cui non esiste un meccanismo che sia valido per tutti gli usi.
2247 La caratteristica specifica di un sistema multitasking come Linux è quella del
2248 cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
2249 multitasking}: questo significa che al contrario di altri sistemi (che usano
2250 invece il cosiddetto \itindex{cooperative~multitasking} \textit{cooperative
2251 multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
2252 quando la CPU deve essere passata ad un altro processo. Come accennato in
2253 sez.~\ref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
2254 apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
2255 distribuire al meglio il tempo di CPU fra i vari processi.
2257 La cosa è resa ancora più complicata dal fatto che con le architetture
2258 multi-processore si deve anche scegliere quale sia la CPU più opportuna da
2259 utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
2260 rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
2261 un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
2262 banale.} Tutto questo comunque appartiene alle sottigliezze
2263 dell'implementazione del kernel; dal punto di vista dei programmi che girano
2264 in user space, anche quando si hanno più processori (e dei processi che sono
2265 eseguiti davvero in contemporanea), le politiche di scheduling riguardano
2266 semplicemente l'allocazione della risorsa \textsl{tempo di esecuzione}, la cui
2267 assegnazione sarà governata dai meccanismi di scelta delle priorità che
2268 restano gli stessi indipendentemente dal numero di processori.
2270 Si tenga conto poi che i processi non devono solo eseguire del codice: ad
2271 esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
2272 venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
2273 tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
2274 kernel provvedere a mettere in esecuzione un altro processo.
2276 Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
2277 processo, in Linux un processo può trovarsi in uno degli stati riportati in
2278 tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
2279 \textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
2280 sia la sua priorità, un processo non potrà mai essere messo in esecuzione
2281 fintanto che esso si trova in uno qualunque degli altri stati.
2286 \begin{tabular}[c]{|p{2.4cm}|c|p{9cm}|}
2288 \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
2291 \textit{runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
2292 essere eseguito (cioè è in attesa che gli
2293 venga assegnata la CPU).\\
2294 \textit{sleep} & \texttt{S} & Il processo è in attesa di un
2295 risposta dal sistema, ma può essere
2296 interrotto da un segnale.\\
2297 \textit{uninterrutible sleep}& \texttt{D} & Il processo è in
2298 attesa di un risposta dal sistema (in
2299 genere per I/O), e non può essere
2300 interrotto in nessuna circostanza.\\
2301 \textit{stopped} & \texttt{T} & Il processo è stato fermato con un
2302 \signal{SIGSTOP}, o è tracciato.\\
2303 \textit{zombie}\itindex{zombie}& \texttt{Z} & Il processo è terminato ma il
2304 suo stato di terminazione non è ancora
2305 stato letto dal padre.\\
2306 \textit{killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
2307 2.6.25, sostanzialmente identico
2308 all'\textit{uninterrutible sleep} con la
2309 sola differenza che il processo può
2310 terminato con \signal{SIGKILL} (usato per
2314 \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
2315 \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
2316 \cmd{ps} nell'omonimo campo.}
2317 \label{tab:proc_proc_states}
2320 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
2321 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
2322 dello scopo del programma non è detto neanche che sia la più importante (molti
2323 programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo
2324 non è affatto detto che dare ad un programma la massima priorità di esecuzione
2325 abbia risultati significativi in termini di prestazioni.
2327 Il meccanismo tradizionale di scheduling di Unix (che tratteremo in
2328 sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
2329 \textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
2330 i meno importanti, possano ricevere un po' di tempo di CPU. In sostanza quando
2331 un processo ottiene la CPU la sua priorità viene diminuita. In questo modo
2332 alla fine, anche un processo con priorità iniziale molto bassa, finisce per
2333 avere una priorità sufficiente per essere eseguito.
2335 Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
2336 assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
2337 alla normale priorità dinamica), per tenere conto dei sistemi
2338 real-time,\footnote{per sistema real-time si intende un sistema in grado di
2339 eseguire operazioni in un tempo ben determinato; in genere si tende a
2340 distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di
2341 esecuzione di un programma siano determinabili con certezza assoluta (come
2342 nel caso di meccanismi di controllo di macchine, dove uno sforamento dei
2343 tempi avrebbe conseguenze disastrose), e \textit{soft-real-time} in cui un
2344 occasionale sforamento è ritenuto accettabile.} in cui è vitale che i
2345 processi che devono essere eseguiti in un determinato momento non debbano
2346 aspettare la conclusione di altri che non hanno questa necessità.
2348 Il concetto di priorità assoluta dice che quando due processi si contendono
2349 l'esecuzione, vince sempre quello con la priorità assoluta più alta.
2350 Ovviamente questo avviene solo per i processi che sono pronti per essere
2351 eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
2352 genere indicata con un numero intero, ed un valore più alto comporta una
2353 priorità maggiore. Su questa politica di scheduling torneremo in
2354 sez.~\ref{sec:proc_real_time}.
2356 In generale quello che succede in tutti gli Unix moderni è che ai processi
2357 normali viene sempre data una priorità assoluta pari a zero, e la decisione di
2358 assegnazione della CPU è fatta solo con il meccanismo tradizionale della
2359 priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
2360 assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
2361 priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
2365 \subsection{Il meccanismo di \textit{scheduling} standard}
2366 \label{sec:proc_sched_stand}
2368 A meno che non si abbiano esigenze specifiche,\footnote{per alcune delle quali
2369 sono state introdotte delle varianti specifiche.} l'unico meccanismo di
2370 scheduling con il quale si avrà a che fare è quello tradizionale, che prevede
2371 solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare
2372 nella programmazione. Come accennato in Linux i processi ordinari hanno tutti
2373 una priorità assoluta nulla; quello che determina quale, fra tutti i processi
2374 in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
2375 \textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna
2376 \texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché
2377 varia nel corso dell'esecuzione di un processo.
2379 Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
2380 dipende strettamente dalla versione di kernel; in particolare a partire
2381 dalla serie 2.6.x lo scheduler è stato riscritto completamente, con molte
2382 modifiche susseguitesi per migliorarne le prestazioni, per un certo periodo
2383 ed è stata anche introdotta la possibilità di usare diversi algoritmi,
2384 selezionabili sia in fase di compilazione, che, nelle versioni più recenti,
2385 all'avvio (addirittura è stato ideato un sistema modulare che permette di
2386 cambiare lo scheduler a sistema attivo).} ma a grandi linee si può dire che
2387 ad ogni processo è assegnata una \textit{time-slice}, cioè un intervallo di
2388 tempo (letteralmente una fetta) per il quale, a meno di eventi esterni, esso
2389 viene eseguito senza essere interrotto. Inoltre la priorità dinamica viene
2390 calcolata dallo scheduler a partire da un valore iniziale che viene
2391 \textsl{diminuito} tutte le volte che un processo è in stato \textbf{Runnable}
2392 ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità
2393 dinamica e la conseguente scelta di quale processo mettere in esecuzione
2394 avviene con un algoritmo molto più complicato, che tiene conto anche della
2395 \textsl{interattività} del processo, utilizzando diversi fattori, questa è
2396 una brutale semplificazione per rendere l'idea del funzionamento, per una
2397 trattazione più dettagliata, anche se non aggiornatissima, dei meccanismi di
2398 funzionamento dello scheduler si legga il quarto capitolo di
2399 \cite{LinKernDev}.} Lo scheduler infatti mette sempre in esecuzione, fra
2400 tutti i processi in stato \textbf{Runnable}, quello che ha il valore di
2401 priorità dinamica più basso.\footnote{con le priorità dinamiche il significato
2402 del valore numerico ad esse associato è infatti invertito, un valore più
2403 basso significa una priorità maggiore.} Il fatto che questo valore venga
2404 diminuito quando un processo non viene posto in esecuzione pur essendo pronto,
2405 significa che la priorità dei processi che non ottengono l'uso del processore
2406 viene progressivamente incrementata, così che anche questi alla fine hanno la
2407 possibilità di essere eseguiti.
2409 Sia la dimensione della \textit{time-slice} che il valore di partenza della
2410 priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o
2411 \textit{niceness}) del processo.\footnote{questa è una delle tante proprietà
2412 che ciascun processo si porta dietro, essa viene ereditata dai processi
2413 figli e mantenuta attraverso una \func{exec}; fino alla serie 2.4 essa era
2414 mantenuta nell'omonimo campo \texttt{nice} della \texttt{task\_struct}, con
2415 la riscrittura dello scheduler eseguita nel 2.6 viene mantenuta nel campo
2416 \texttt{static\_prio} come per le priorità statiche.} L'origine del nome di
2417 questo parametro sta nel fatto che generalmente questo viene usato per
2418 \textsl{diminuire} la priorità di un processo, come misura di cortesia nei
2419 confronti degli altri. I processi infatti vengono creati dal sistema con un
2420 valore di \var{nice} nullo e nessuno è privilegiato rispetto agli altri;
2421 specificando un valore positivo si avrà una \textit{time-slice} più breve ed
2422 un valore di priorità dinamica iniziale più alto, mentre un valore negativo
2423 darà una \textit{time-slice} più lunga ed un valore di priorità dinamica
2426 Esistono diverse funzioni che consentono di modificare la \textit{niceness} di
2427 un processo; la più semplice è funzione \funcd{nice}, che opera sul processo
2428 corrente, il suo prototipo è:
2429 \begin{prototype}{unistd.h}
2431 Aumenta il valore di \var{nice} per il processo corrente.
2433 \bodydesc{La funzione ritorna zero o il nuovo valore di \var{nice} in caso
2434 di successo e -1 in caso di errore, nel qual caso \var{errno} può assumere
2437 \item[\errcode{EPERM}] non si ha il permesso di specificare un valore
2438 di \param{inc} negativo.
2442 L'argomento \param{inc} indica l'incremento da effettuare rispetto al valore
2443 di \var{nice} corrente: quest'ultimo può assumere valori compresi fra
2444 \const{PRIO\_MIN} e \const{PRIO\_MAX}; nel caso di Linux sono fra $-20$ e
2445 $19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di
2446 kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere
2447 anche l'intervallo fra $-20$ e $20$.} ma per \param{inc} si può specificare
2448 un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare
2449 il risultato nell'intervallo consentito. Valori positivi comportano maggiore
2450 \textit{cortesia} e cioè una diminuzione della priorità, valori negativi
2451 comportano invece un aumento della priorità. Con i kernel precedenti il
2452 2.6.12 solo l'amministratore\footnote{o un processo con la
2453 \itindex{capabilities} \textit{capability} \const{CAP\_SYS\_NICE}, vedi
2454 sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi
2455 di \param{inc} che permettono di aumentare la priorità di un processo, a
2456 partire da questa versione è consentito anche agli utenti normali alzare
2457 (entro certi limiti, che vedremo più avanti) la priorità dei propri processi.
2459 Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
2460 di \var{nice} del processo; tuttavia la \textit{system call} di Linux non
2461 segue questa convenzione e restituisce sempre 0 in caso di successo e $-1$ in
2462 caso di errore; questo perché $-1$ è un valore di \var{nice} legittimo e
2463 questo comporta una confusione con una eventuale condizione di errore. La
2464 \textit{system call} originaria inoltre non consente, se non dotati di
2465 adeguati privilegi, di diminuire un valore di \var{nice} precedentemente
2468 Fino alle \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
2469 risultato dalla \textit{system call}, violando lo standard, per cui per
2470 ottenere il nuovo valore occorreva una successiva chiamata alla funzione
2471 \func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
2472 reimplementata e non viene più chiamata la omonima \textit{system call}, con
2473 questa versione viene restituito come valore di ritorno il valore di
2474 \var{nice}, come richiesto dallo standard.\footnote{questo viene fatto
2475 chiamando al suo interno \func{setpriority}, che tratteremo a breve.} In
2476 questo caso l'unico modo per rilevare in maniera affidabile una condizione di
2477 errore è quello di azzerare \var{errno} prima della chiamata della funzione e
2478 verificarne il valore quando \func{nice} restituisce $-1$.
2480 Per leggere il valore di \textit{nice} di un processo occorre usare la
2481 funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è:
2482 \begin{prototype}{sys/resource.h}
2483 {int getpriority(int which, int who)}
2485 Restituisce il valore di \var{nice} per l'insieme dei processi specificati.
2487 \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di
2488 errore, nel qual caso \var{errno} può assumere i valori:
2490 \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2491 \param{which} e \param{who}.
2492 \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
2495 \noindent nelle vecchie versioni può essere necessario includere anche
2496 \file{<sys/time.h>}, questo non è più necessario con versioni recenti delle
2497 librerie, ma è comunque utile per portabilità.
2499 La funzione permette, a seconda del valore di \param{which}, di leggere la
2500 priorità di un processo, di un gruppo di processi (vedi
2501 sez.~\ref{sec:sess_proc_group}) o di un utente, specificando un corrispondente
2502 valore per \param{who} secondo la legenda di tab.~\ref{tab:proc_getpriority};
2503 un valore nullo di quest'ultimo indica il processo, il gruppo di processi o
2509 \begin{tabular}[c]{|c|c|l|}
2511 \param{which} & \param{who} & \textbf{Significato} \\
2514 \const{PRIO\_PROCESS} & \type{pid\_t} & processo \\
2515 \const{PRIO\_PRGR} & \type{pid\_t} & \itindex{process~group}
2516 \textit{process group} \\
2517 \const{PRIO\_USER} & \type{uid\_t} & utente \\
2520 \caption{Legenda del valore dell'argomento \param{which} e del tipo
2521 dell'argomento \param{who} delle funzioni \func{getpriority} e
2522 \func{setpriority} per le tre possibili scelte.}
2523 \label{tab:proc_getpriority}
2526 La funzione restituisce la priorità più alta (cioè il valore più basso) fra
2527 quelle dei processi specificati; di nuovo, dato che $-1$ è un valore
2528 possibile, per poter rilevare una condizione di errore è necessario cancellare
2529 sempre \var{errno} prima della chiamata alla funzione per verificare che essa
2530 resti uguale a zero.
2532 Analoga a \func{getpriority} è la funzione \funcd{setpriority} che permette di
2533 impostare la priorità di uno o più processi; il suo prototipo è:
2534 \begin{prototype}{sys/resource.h}
2535 {int setpriority(int which, int who, int prio)}
2536 Imposta la priorità per l'insieme dei processi specificati.
2538 \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
2539 nel qual caso \var{errno} può assumere i valori:
2541 \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2542 \param{which} e \param{who}.
2543 \item[\errcode{EINVAL}] il valore di \param{which} non è valido.
2544 \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
2545 sufficienti privilegi.
2546 \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
2547 cercato di modificare la priorità di un processo di un altro utente.
2551 La funzione imposta la priorità al valore specificato da \param{prio} per
2552 tutti i processi indicati dagli argomenti \param{which} e \param{who}. In
2553 questo caso come valore di \param{prio} deve essere specificato il valore di
2554 \textit{nice} da assegnare, e non un incremento (positivo o negativo) come nel
2555 caso di \func{nice}. La funzione restituisce il valore di \textit{nice}
2556 assegnato in caso di successo e $-1$ in caso di errore, e come per \func{nice}
2557 anche in questo caso per rilevare un errore occorre sempre porre a zero
2558 \var{errno} prima della chiamata della funzione, essendo $-1$ un valore di
2559 \textit{nice} valido.
2561 Si tenga presente che solo l'amministratore\footnote{o più precisamente un
2562 processo con la \itindex{capabilities} \textit{capability}
2563 \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} ha la
2564 possibilità di modificare arbitrariamente le priorità di qualunque
2565 processo. Un utente normale infatti può modificare solo la priorità dei suoi
2566 processi ed in genere soltanto diminuirla. Fino alla versione di kernel
2567 2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i
2568 sistemi derivati da SysV veniva richiesto che l'user-ID reale o quello
2569 effettivo del processo chiamante corrispondessero all'user-ID reale (e solo a
2570 quello) del processo di cui si intendeva cambiare la priorità. A partire dalla
2571 versione 2.6.12 è stata adottata la semantica in uso presso i sistemi derivati
2572 da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere anche con
2573 l'user-ID effettivo.
2575 Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
2576 ordinari poter aumentare la priorità dei propri processi specificando un
2577 valore di \param{prio} negativo. Questa operazione non è possibile però in
2578 maniera indiscriminata, ed in particolare può essere effettuata solo
2579 nell'intervallo consentito dal valore del limite \const{RLIMIT\_NICE}
2580 (torneremo su questo in sez.~\ref{sec:sys_resource_limit}).
2583 \subsection{Il meccanismo di \textit{scheduling real-time}}
2584 \label{sec:proc_real_time}
2586 Come spiegato in sez.~\ref{sec:proc_sched} lo standard POSIX.1b ha introdotto
2587 le priorità assolute per permettere la gestione di processi real-time. In
2588 realtà nel caso di Linux non si tratta di un vero hard real-time, in quanto in
2589 presenza di eventuali interrupt il kernel interrompe l'esecuzione di un
2590 processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si
2591 siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile
2592 ottenere un sistema effettivamente hard real-time. In tal caso infatti gli
2593 interrupt vengono intercettati dall'interfaccia real-time (o nel caso di
2594 Adeos gestiti dalle code del nano-kernel), in modo da poterli controllare
2595 direttamente qualora ci sia la necessità di avere un processo con priorità
2596 più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
2597 \itindex{page~fault} \textit{page fault} si possono avere ritardi non
2598 previsti. Se l'ultimo problema può essere aggirato attraverso l'uso delle
2599 funzioni di controllo della memoria virtuale (vedi
2600 sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
2601 ritardi non prevedibili riguardo ai tempi di esecuzione di qualunque processo.
2603 Nonostante questo, ed in particolare con una serie di miglioramenti che sono
2604 stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire
2605 dalla versione 2.6.18 sono stati inserite nel kernel una serie di modifiche
2606 che consentono di avvicinarsi sempre di più ad un vero e proprio sistema
2607 \textit{real-time} estendendo il concetto di \textit{preemption} alle
2608 operazioni dello stesso kernel; esistono vari livelli a cui questo può
2609 essere fatto, ottenibili attivando in fase di compilazione una fra le
2610 opzioni \texttt{CONFIG\_PREEMPT\_NONE}, \texttt{CONFIG\_PREEMPT\_VOLUNTARY}
2611 e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima
2612 approssimazione di sistema real-time usando le priorità assolute; occorre
2613 farlo però con molta attenzione: se si dà ad un processo una priorità assoluta
2614 e questo finisce in un loop infinito, nessun altro processo potrà essere
2615 eseguito, ed esso sarà mantenuto in esecuzione permanentemente assorbendo
2616 tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
2617 sistema. Per questo motivo è sempre opportuno, quando si lavora con processi
2618 che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
2619 massima priorità assoluta, in modo da poter essere comunque in grado di
2620 rientrare nel sistema.
2622 Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
2623 esecuzione prima di ogni processo normale. In caso di più processi sarà
2624 eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
2625 processi con la stessa priorità assoluta questi vengono tenuti in una coda e
2626 tocca al kernel decidere quale deve essere eseguito. Il meccanismo con cui
2627 vengono gestiti questi processi dipende dalla politica di scheduling che si è
2628 scelta; lo standard ne prevede due:
2629 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
2630 \item[\textsf{FIFO}] \textit{First In First Out}. Il processo viene eseguito
2631 fintanto che non cede volontariamente la CPU (con \func{sched\_yield}), si
2632 blocca, finisce o viene interrotto da un processo a priorità più alta. Se il
2633 processo viene interrotto da uno a priorità più alta esso resterà in cima
2634 alla lista e sarà il primo ad essere eseguito quando i processi a priorità
2635 più alta diverranno inattivi. Se invece lo si blocca volontariamente sarà
2636 posto in coda alla lista (ed altri processi con la stessa priorità potranno
2638 \item[\textsf{RR}] \textit{Round Robin}. Il comportamento è del tutto analogo
2639 a quello precedente, con la sola differenza che ciascun processo viene
2640 eseguito al massimo per un certo periodo di tempo (la cosiddetta
2641 \textit{time-slice}) dopo di che viene automaticamente posto in fondo alla
2642 coda dei processi con la stessa priorità. In questo modo si ha comunque una
2643 esecuzione a turno di tutti i processi, da cui il nome della politica. Solo
2644 i processi con la stessa priorità ed in stato \textbf{Runnable} entrano nel
2648 Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare
2649 le politiche di scheduling, passando da real-time a ordinarie o viceversa, che
2650 di specificare, in caso di politiche real-time, la eventuale priorità statica;
2651 la funzione è \funcd{sched\_setscheduler} ed il suo prototipo è:
2652 \begin{prototype}{sched.h}
2653 {int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)}
2654 Imposta priorità e politica di scheduling.
2656 \bodydesc{La funzione ritorna 0 in caso di successo e $-$1 in caso di
2657 errore, nel qual caso \var{errno} può assumere i valori:
2659 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2660 \item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il
2661 relativo valore di \param{p} non è valido.
2662 \item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
2667 La funzione esegue l'impostazione per il processo specificato dall'argomento
2668 \param{pid}; un valore nullo di questo argomento esegue l'impostazione per il
2669 processo corrente. La politica di scheduling è specificata
2670 dall'argomento \param{policy} i cui possibili valori sono riportati in
2671 tab.~\ref{tab:proc_sched_policy}; la parte alta della tabella indica le
2672 politiche real-time, quella bassa le politiche ordinarie. Un valore negativo
2673 per \param{policy} mantiene la politica di scheduling corrente.
2678 \begin{tabular}[c]{|l|l|}
2680 \textbf{Policy} & \textbf{Significato} \\
2683 \const{SCHED\_FIFO} & Scheduling real-time con politica \textit{FIFO}. \\
2684 \const{SCHED\_RR} & Scheduling real-time con politica \textit{Round
2687 \const{SCHED\_OTHER}& Scheduling ordinario.\\
2688 \const{SCHED\_BATCH}& Scheduling ordinario con l'assunzione ulteriore di
2689 lavoro \textit{CPU intensive}.\footnotemark\\
2690 \const{SCHED\_IDLE} & Scheduling di priorità estremamente
2691 bassa.\footnotemark\\
2694 \caption{Valori dell'argomento \param{policy} per la funzione
2695 \func{sched\_setscheduler}.}
2696 \label{tab:proc_sched_policy}
2699 \footnotetext[44]{introdotto con il kernel 2.6.16.}
2700 \footnotetext{introdotto con il kernel 2.6.23.}
2702 Con le versioni più recenti del kernel sono state introdotte anche delle
2703 varianti sulla politica di scheduling tradizionale per alcuni carichi di
2704 lavoro specifici, queste due nuove politiche sono specifiche di Linux e non
2705 devono essere usate se si vogliono scrivere programmi portabili.
2707 La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
2708 la sola differenza che i processi ad essa soggetti non ottengono, nel calcolo
2709 delle priorità dinamiche fatto dallo scheduler, il cosiddetto bonus di
2710 interattività che mira a favorire i processi che si svegliano dallo stato di
2711 \textbf{Sleep}.\footnote{cosa che accade con grande frequenza per i processi
2712 interattivi, dato che essi sono per la maggior parte del tempo in attesa di
2713 dati in ingresso da parte dell'utente.} La si usa pertanto, come indica il
2714 nome, per processi che usano molta CPU (come programmi di calcolo) che in
2715 questo modo sono leggermente sfavoriti rispetto ai processi interattivi che
2716 devono rispondere a dei dati in ingresso, pur non perdendo il loro valore di
2719 La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
2720 si desidera siano eseguiti con la più bassa priorità possibile, ancora più
2721 bassa di un processo con il minimo valore di \textit{nice}. In sostanza la si
2722 può utilizzare per processi che devono essere eseguiti se non c'è niente altro
2723 da fare. Va comunque sottolineato che anche un processo \const{SCHED\_IDLE}
2724 avrà comunque una sua possibilità di utilizzo della CPU, sia pure in
2725 percentuale molto bassa.
2727 Qualora si sia richiesta una politica real-time il valore della priorità
2728 statica viene impostato attraverso la struttura \struct{sched\_param},
2729 riportata in fig.~\ref{fig:sig_sched_param}, il cui solo campo attualmente
2730 definito è \var{sched\_priority}. Il campo deve contenere il valore della
2731 priorità statica da assegnare al processo; lo standard prevede che questo
2732 debba essere assegnato all'interno di un intervallo fra un massimo ed un
2733 minimo che nel caso di Linux sono rispettivamente 1 e 99.
2735 \begin{figure}[!htbp]
2736 \footnotesize \centering
2737 \begin{minipage}[c]{\textwidth}
2738 \includestruct{listati/sched_param.c}
2741 \caption{La struttura \structd{sched\_param}.}
2742 \label{fig:sig_sched_param}
2745 I processi con politica di scheduling ordinaria devono sempre specificare un
2746 valore nullo di \var{sched\_priority} altrimenti si avrà un errore
2747 \errcode{EINVAL}, questo valore infatti non ha niente a che vedere con la
2748 priorità dinamica determinata dal valore di \textit{nice}, che deve essere
2749 impostato con le funzioni viste in precedenza.
2751 Lo standard POSIX.1b prevede comunque che i due valori della massima e minima
2752 priorità statica possano essere ottenuti, per ciascuna delle politiche di
2753 scheduling \textit{real-time}, tramite le due funzioni
2754 \funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
2759 \funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore
2760 massimo della priorità statica per la politica di scheduling \param{policy}.
2763 \funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo
2764 della priorità statica per la politica di scheduling \param{policy}.
2766 \bodydesc{La funzioni ritornano il valore della priorità in caso di successo
2767 e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
2769 \item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
2773 Si tenga presente che quando si imposta una politica di scheduling real-time
2774 per un processo o se ne cambia la priorità statica questo viene messo in cima
2775 alla lista dei processi con la stessa priorità; questo comporta che verrà
2776 eseguito subito, interrompendo eventuali altri processi con la stessa priorità
2777 in quel momento in esecuzione.
2779 Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
2780 esegue sempre il primo della lista, mentre un nuovo processo che torna in
2781 stato \textbf{Runnable} viene sempre inserito in coda alla lista. Se la
2782 politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
2783 automaticamente rimesso in coda alla lista, e la sua esecuzione continua
2784 fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
2785 volontariamente la CPU (in tal caso, tornando nello stato \textbf{Runnable}
2786 sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo
2787 nel caso che esso sia stato interrotto da un processo a priorità più alta.
2789 Solo un processo con i privilegi di amministratore\footnote{più precisamente
2790 con la \itindex{capabilities} capacità \const{CAP\_SYS\_NICE}, vedi
2791 sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
2792 assolute diverse da zero o politiche \const{SCHED\_FIFO} e
2793 \const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
2794 processi che gli appartengono; è cioè richiesto che l'user-ID effettivo del
2795 processo chiamante corrisponda all'user-ID reale o effettivo del processo
2796 indicato con \param{pid}.
2798 Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche
2799 real-time o modificare la eventuale priorità statica di un loro processo. A
2800 partire da questa versione è divenuto possibile anche per gli utenti normali
2801 usare politiche real-time fintanto che la priorità assoluta che si vuole
2802 impostare è inferiore al limite \const{RLIMIT\_RTPRIO} (vedi
2803 sez.~\ref{sec:sys_resource_limit}) ad essi assegnato. Unica eccezione a questa
2804 possibilità sono i processi \const{SCHED\_IDLE}, che non possono cambiare
2805 politica di scheduling indipendentemente dal valore di
2806 \const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto ad una
2807 politica real-time, un utente può sempre, indipendentemente dal valore di
2808 \const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una politica
2811 Se si intende operare solo sulla priorità statica di un processo si possono
2812 usare le due funzioni \funcd{sched\_setparam} e \funcd{sched\_getparam} che
2813 consentono rispettivamente di impostarne e leggerne il valore, i loro
2818 \funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *param)}
2819 Imposta la priorità statica del processo \param{pid}.
2821 \funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)}
2822 Legge la priorità statica del processo \param{pid}.
2824 \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e $-1$ in
2825 caso di errore, nel qual caso \var{errno} può assumere i valori:
2827 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2828 \item[\errcode{EINVAL}] il valore di \param{param} non ha senso per la
2829 politica usata dal processo.
2830 \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
2835 L'uso di \func{sched\_setparam}, compresi i controlli di accesso che vi si
2836 applicano, è del tutto equivalente a quello di \func{sched\_setscheduler} con
2837 argomento \param{policy} uguale a -1. Come per \func{sched\_setscheduler}
2838 specificando 0 come valore dell'argomento \param{pid} si opera sul processo
2839 corrente. Benché la funzione sia utilizzabile anche con processi sottoposti a
2840 politica ordinaria essa ha senso soltanto per quelli real-time, dato che per i
2841 primi la priorità statica può essere soltanto nulla. La disponibilità di
2842 entrambe le funzioni può essere verificata controllando la macro
2843 \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'header
2846 Se invece si vuole sapere quale è politica di scheduling di un processo si può
2847 usare la funzione \funcd{sched\_getscheduler}, il cui prototipo è:
2848 \begin{prototype}{sched.h}
2849 {int sched\_getscheduler(pid\_t pid)}
2850 Legge la politica di scheduling per il processo \param{pid}.
2852 \bodydesc{La funzione ritorna la politica di scheduling in caso di successo
2853 e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori:
2855 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2856 \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
2861 La funzione restituisce il valore, secondo quanto elencato in
2862 tab.~\ref{tab:proc_sched_policy}, della politica di scheduling per il processo
2863 specificato; se l'argomento \param{pid} è nullo viene restituito il valore
2864 relativo al processo chiamante.
2866 L'ultima funzione che permette di leggere le informazioni relative ai processi
2867 real-time è \funcd{sched\_rr\_get\_interval}, che permette di ottenere la
2868 lunghezza della \textit{time-slice} usata dalla politica \textit{round robin};
2870 \begin{prototype}{sched.h}
2871 {int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in
2872 \param{tp} la durata della \textit{time-slice} per il processo \param{pid}.
2874 \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
2875 nel qual caso \var{errno} può assumere i valori:
2877 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2878 \item[\errcode{ENOSYS}] la \textit{system call} non è stata implementata.
2882 La funzione restituisce il valore dell'intervallo di tempo usato per la
2883 politica \textit{round robin} in una struttura \struct{timespec}, (la cui
2884 definizione si può trovare in fig.~\ref{fig:sys_timeval_struct}). In realtà
2885 dato che in Linux questo intervallo di tempo è prefissato e non modificabile,
2886 questa funzione ritorna sempre un valore di 150 millisecondi, e non importa
2887 specificare il PID di un processo reale.
2889 Come accennato ogni processo può rilasciare volontariamente la CPU in modo da
2890 consentire agli altri processi di essere eseguiti; la funzione che consente di
2891 fare tutto ciò è \funcd{sched\_yield}, il cui prototipo è:
2892 \begin{prototype}{sched.h}
2893 {int sched\_yield(void)}
2895 Rilascia volontariamente l'esecuzione.
2897 \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
2898 nel qual caso \var{errno} viene impostata opportunamente.}
2901 Questa funzione ha un utilizzo effettivo soltanto quando si usa lo scheduling
2902 real-time, e serve a far sì che il processo corrente rilasci la CPU, in modo
2903 da essere rimesso in coda alla lista dei processi con la stessa priorità per
2904 permettere ad un altro di essere eseguito; se però il processo è l'unico ad
2905 essere presente sulla coda l'esecuzione non sarà interrotta. In genere usano
2906 questa funzione i processi con politica \const{SCHED\_FIFO}, per permettere
2907 l'esecuzione degli altri processi con pari priorità quando la sezione più
2910 La funzione può essere utilizzata anche con processi che usano lo scheduling
2911 ordinario, ma in questo caso il comportamento non è ben definito, e dipende
2912 dall'implementazione. Fino al kernel 2.6.23 questo comportava che i processi
2913 venissero messi in fondo alla coda di quelli attivi, con la possibilità di
2914 essere rimessi in esecuzione entro breve tempo, con l'introduzione del
2915 \textit{Completely Fair Scheduler} questo comportamento è cambiato ed un
2916 processo che chiama la funzione viene inserito nella lista dei processi
2917 inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
2918 ripristinare un comportamento analogo al precedente scrivendo il valore 1
2919 nel file \texttt{/proc/sys/kernel/sched\_compat\_yield}.}
2923 \subsection{Il controllo dello \textit{scheduler} per i sistemi
2925 \label{sec:proc_sched_multiprocess}
2927 Infine con il supporto dei sistemi multiprocessore sono state introdotte delle
2928 funzioni che permettono di controllare in maniera più dettagliata la scelta di
2929 quale processore utilizzare per eseguire un certo programma. Uno dei problemi
2930 che si pongono nei sistemi multiprocessore è infatti quello del cosiddetto
2931 \index{effetto~ping-pong} \textsl{effetto ping-pong}. Può accadere cioè che lo
2932 scheduler, quando riavvia un processo precedentemente interrotto scegliendo il
2933 primo processore disponibile, lo faccia eseguire da un processore diverso
2934 rispetto a quello su cui era stato eseguito in precedenza. Se il processo
2935 passa da un processore all'altro in questo modo (cosa che avveniva abbastanza
2936 di frequente con i kernel della seria 2.4.x) si ha l'\textsl{effetto
2939 Questo tipo di comportamento può generare dei seri problemi di prestazioni;
2940 infatti tutti i processori moderni utilizzano una memoria interna (la
2941 \textit{cache}) contenente i dati più usati, che permette di evitare di
2942 eseguire un accesso (molto più lento) alla memoria principale sulla scheda
2943 madre. Chiaramente un processo sarà favorito se i suoi dati sono nella cache
2944 del processore, ma è ovvio che questo può essere vero solo per un processore
2945 alla volta, perché in presenza di più copie degli stessi dati su più
2946 processori, non si potrebbe determinare quale di questi ha la versione dei
2947 dati aggiornata rispetto alla memoria principale.
2949 Questo comporta che quando un processore inserisce un dato nella sua cache,
2950 tutti gli altri processori che hanno lo stesso dato devono invalidarlo, e
2951 questa operazione è molto costosa in termini di prestazioni. Il problema
2952 diventa serio quando si verifica l'\textsl{effetto ping-pong}, in tal caso
2953 infatti un processo \textsl{rimbalza} continuamente da un processore all'altro
2954 e si ha una continua invalidazione della cache, che non diventa mai
2957 \itindbeg{CPU~affinity}
2959 Per ovviare a questo tipo di problemi è nato il concetto di \textsl{affinità
2960 di processore} (o \textit{CPU affinity}); la possibilità cioè di far sì che
2961 un processo possa essere assegnato per l'esecuzione sempre allo stesso
2962 processore. Lo scheduler dei kernel della serie 2.4.x aveva una scarsa
2963 \textit{CPU affinity}, e \index{effetto~ping-pong} l'effetto ping-pong era
2964 comune; con il nuovo scheduler dei kernel della 2.6.x questo problema è stato
2965 risolto ed esso cerca di mantenere il più possibile ciascun processo sullo
2968 In certi casi però resta l'esigenza di poter essere sicuri che un processo sia
2969 sempre eseguito dallo stesso processore,\footnote{quella che viene detta
2970 \textit{hard CPU affinity}, in contrasto con quella fornita dallo scheduler,
2971 detta \textit{soft CPU affinity}, che di norma indica solo una preferenza,
2972 non un requisito assoluto.} e per poter risolvere questo tipo di
2973 problematiche nei nuovi kernel\footnote{le due \textit{system call} per la
2974 gestione della \textit{CPU affinity} sono state introdotte nel kernel 2.5.8,
2975 e le funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
2976 l'opportuna infrastruttura ed una nuova \textit{system call} che permette di
2977 impostare su quali processori far eseguire un determinato processo attraverso
2978 una \textsl{maschera di affinità}. La corrispondente funzione di libreria è
2979 \funcd{sched\_setaffinity} ed il suo prototipo è:
2980 \begin{prototype}{sched.h}
2981 {int sched\_setaffinity (pid\_t pid, unsigned int cpusetsize, const
2982 cpu\_set\_t *cpuset)}
2983 Imposta la maschera di affinità del processo \param{pid}.
2985 \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
2986 nel qual caso \var{errno} può assumere i valori:
2988 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2989 \item[\errcode{EINVAL}] il valore di \param{cpuset} contiene riferimenti a
2990 processori non esistenti nel sistema.
2991 \item[\errcode{EPERM}] il processo non ha i privilegi sufficienti per
2992 eseguire l'operazione.
2994 ed inoltre anche \errval{EFAULT}.}
2998 Questa funzione e la corrispondente \func{sched\_setaffinity} hanno una storia
2999 abbastanza complessa, la \textit{system call} prevede l'uso di due ulteriori
3000 argomenti di tipo \texttt{unsigned int len} e \texttt{unsigned long *mask},
3001 che corrispondono al fatto che la implementazione effettiva usa una semplice
3002 maschera binaria. Quando le funzioni vennero incluse nelle \acr{glibc}
3003 assunsero invece il prototipo appena mostrato. A complicare la cosa si
3004 aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} l'argomento
3005 \param{cpusetsize} è stato eliminato, per poi essere ripristinato nella
3006 versione 2.3.4.\footnote{pertanto se la vostra pagina di manuale non è
3007 aggiornata, o usate quella particolare versione delle \acr{glibc}, potrete
3008 trovare indicazioni diverse, il prototipo illustrato è quello riportato
3009 nella versione corrente (maggio 2008) delle pagine di manuale e
3010 corrispondente alla definizione presente in \file{sched.h}.}
3012 La funzione imposta, con l'uso del valore contenuto all'indirizzo
3013 \param{cpuset}, l'insieme dei processori sui quali deve essere eseguito il
3014 processo identificato tramite il valore passato in \param{pid}. Come in
3015 precedenza il valore nullo di \param{pid} indica il processo corrente. Per
3016 poter utilizzare questa funzione sono richiesti i privilegi di amministratore
3017 (è necessaria la capacità \const{CAP\_SYS\_NICE}) altrimenti essa fallirà con
3018 un errore di \errcode{EPERM}. Una volta impostata una maschera di affinità,
3019 questa viene ereditata attraverso una \func{fork}, in questo modo diventa
3020 possibile legare automaticamente un gruppo di processi ad un singolo
3023 Nell'uso comune, almeno con i kernel della serie 2.6.x, l'uso di questa
3024 funzione non è necessario, in quanto è lo scheduler stesso che provvede a
3025 mantenere al meglio l'affinità di processore. Esistono però esigenze
3026 particolari, ad esempio quando un processo (o un gruppo di processi) è
3027 utilizzato per un compito importante (ad esempio per applicazioni real-time o
3028 la cui risposta è critica) e si vuole la massima velocità, con questa
3029 interfaccia diventa possibile selezionare gruppi di processori utilizzabili in
3030 maniera esclusiva. Lo stesso dicasi quando l'accesso a certe risorse (memoria
3031 o periferiche) può avere un costo diverso a seconda del processore, come
3032 avviene nelle architetture NUMA (\textit{Non-Uniform Memory Access}).
3034 Infine se un gruppo di processi accede alle stesse risorse condivise (ad
3035 esempio una applicazione con più \itindex{thread} \textit{thread}) può avere
3036 senso usare lo stesso processore in modo da sfruttare meglio l'uso della sua
3037 cache; questo ovviamente riduce i benefici di un sistema multiprocessore
3038 nell'esecuzione contemporanea dei \itindex{thread} \textit{thread}, ma in
3039 certi casi (quando i \itindex{thread} \textit{thread} sono inerentemente
3040 serializzati nell'accesso ad una risorsa) possono esserci sufficienti vantaggi
3041 nell'evitare la perdita della cache da rendere conveniente l'uso dell'affinità
3044 Per facilitare l'uso dell'argomento \param{cpuset} le \acr{glibc} hanno
3045 introdotto un apposito dato di tipo, \type{cpu\_set\_t},\footnote{questa è una
3046 estensione specifica delle \acr{glibc}, da attivare definendo la macro
3047 \macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per
3048 questo tipo di interfaccia e POSIX al momento non prevede nulla al
3049 riguardo.} che permette di identificare un insieme di processori. Il dato è
3050 una maschera binaria: in generale è un intero a 32 bit in cui ogni bit
3051 corrisponde ad un processore, ma dato che per architetture particolari il
3052 numero di bit di un intero può non essere sufficiente, è stata creata questa
3053 che è una interfaccia generica che permette di usare a basso livello un tipo
3054 di dato qualunque rendendosi indipendenti dal numero di bit e dalla loro
3057 Questa interfaccia, oltre alla definizione del tipo di dato apposito, prevede
3058 anche una serie di macro di preprocessore per la manipolazione dello stesso,
3059 che consentono di svuotare un insieme, aggiungere o togliere un processore da
3060 esso o verificare se vi è già presente:
3063 \funcdecl{void \macro{CPU\_ZERO}(cpu\_set\_t *set)}
3064 Inizializza l'insieme (vuoto).
3066 \funcdecl{void \macro{CPU\_SET}(int cpu, cpu\_set\_t *set)}
3067 Inserisce il processore \param{cpu} nell'insieme.
3069 \funcdecl{void \macro{CPU\_CLR}(int cpu, cpu\_set\_t *set)}
3070 Rimuove il processore \param{cpu} nell'insieme.
3072 \funcdecl{int \macro{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
3073 Controlla se il processore \param{cpu} è nell'insieme.
3076 Oltre a queste macro, simili alle analoghe usate per gli insiemi di file
3077 descriptor (vedi sez.~\ref{sec:file_select}) è definita la costante
3078 \const{CPU\_SETSIZE} che indica il numero massimo di processori che possono
3079 far parte dell'insieme, e che costituisce un limite massimo al valore
3080 dell'argomento \param{cpu}.
3082 In generale la maschera di affinità è preimpostata in modo che un processo
3083 possa essere eseguito su qualunque processore, se può comunque leggere il
3084 valore per un processo specifico usando la funzione
3085 \funcd{sched\_getaffinity}, il suo prototipo è:
3086 \begin{prototype}{sched.h}
3087 {int sched\_getaffinity (pid\_t pid, unsigned int cpusetsize,
3088 const cpu\_set\_t *cpuset)}
3089 Legge la maschera di affinità del processo \param{pid}.
3091 \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore,
3092 nel qual caso \var{errno} può assumere i valori:
3094 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3095 \item[\errcode{EFAULT}] il valore di \param{cpuset} non è un indirizzo
3100 La funzione restituirà all'indirizzo specificato da \param{cpuset} il valore
3101 della maschera di affinità del processo, così da poterla riutilizzare per una
3102 successiva reimpostazione. In questo caso non sono necessari privilegi
3105 È chiaro che queste funzioni per la gestione dell'affinità hanno significato
3106 soltanto su un sistema multiprocessore, esse possono comunque essere
3107 utilizzate anche in un sistema con un processore singolo, nel qual caso però
3108 non avranno alcun risultato effettivo.
3110 \itindend{scheduler}
3111 \itindend{CPU~affinity}
3114 \subsection{Le priorità per le operazioni di I/O}
3115 \label{sec:io_priority}
3117 A lungo l'unica priorità usata per i processi è stata quella relativa
3118 all'assegnazione dell'uso del processore. Ma il processore non è l'unica
3119 risorsa che i processi devono contendersi, un'altra, altrettanto importante
3120 per le prestazioni, è quella dell'accesso a disco. Per questo motivo sono
3121 stati introdotti diversi \textit{I/O scheduler} in grado di distribuire in
3122 maniera opportuna questa risorsa ai vari processi. Fino al kernel 2.6.17 era
3123 possibile soltanto differenziare le politiche generali di gestione, scegliendo
3124 di usare un diverso \textit{I/O scheduler}; a partire da questa versione, con
3125 l'introduzione dello scheduler CFQ (\textit{Completely Fair Queuing}) è
3126 divenuto possibile, qualora si usi questo scheduler, impostare anche delle
3127 diverse priorità di accesso per i singoli processi.\footnote{al momento
3128 (kernel 2.6.31), le priorità di I/O sono disponibili soltanto per questo
3131 La scelta dello scheduler di I/O si può fare in maniera generica a livello di
3132 avvio del kernel assegnando il nome dello stesso al parametro
3133 \texttt{elevator}, mentre se ne può indicare uno per l'accesso al singolo
3134 disco scrivendo nel file \texttt{/sys/block/\textit{dev}/queue/scheduler}
3135 (dove \texttt{\textit{dev}} è il nome del dispositivo associato al disco); gli
3136 scheduler disponibili sono mostrati dal contenuto dello stesso file che
3137 riporta fra parentesi quadre quello attivo, il default in tutti i kernel
3138 recenti è proprio il \texttt{cfq},\footnote{nome con cui si indica appunto lo
3139 scheduler \textit{Completely Fair Queuing}.} che supporta le priorità. Per i
3140 dettagli sulle caratteristiche specifiche degli altri scheduler, la cui
3141 discussione attiene a problematiche di ambito sistemistico, si consulti la
3142 documentazione nella directory \texttt{Documentation/block/} dei sorgenti del
3145 Una volta che si sia impostato lo scheduler CFQ ci sono due specifiche system
3146 call, specifiche di Linux, che consentono di leggere ed impostare le priorità
3147 di I/O.\footnote{se usate in corrispondenza ad uno scheduler diverso il loro
3148 utilizzo non avrà alcun effetto.} Dato che non esiste una interfaccia
3149 diretta nelle \acr{glibc} per queste due funzioni occorrerà invocarle tramite
3150 la funzione \func{syscall} (come illustrato in
3151 sez.~\ref{sec:proc_syscall}). Le due funzioni sono \funcd{ioprio\_get} ed
3152 \funcd{ioprio\_set}; i rispettivi prototipi sono:
3154 \headdecl{linux/ioprio.h}
3155 \funcdecl{int ioprio\_get(int which, int who)}
3156 \funcdecl{int ioprio\_set(int which, int who, int ioprio)}
3158 Rileva o imposta la priorità di I/O di un processo.
3160 \bodydesc{Le funzioni ritornano rispettivamente un intero positivo
3161 (indicante la priorità) o 0 in caso di successo e $-1$ in caso di errore,
3162 nel qual caso \var{errno} può assumere i valori:
3164 \item[\errcode{ESRCH}] non esiste il processo indicato.
3165 \item[\errcode{EINVAL}] i valori di \param{which} e \param{who} non sono
3167 \item[\errcode{EPERM}] non si hanno i privilegi per eseguire
3168 l'impostazione (solo per \func{ioprio\_set}).
3172 Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione
3173 dei due argomenti \param{which} e \param{who} che hanno lo stesso significato
3174 già visto per gli omonimi argomenti di \func{getpriority} e
3175 \func{setpriority}. Anche in questo caso si deve specificare il valore
3176 di \param{which} tramite le opportune costanti riportate in
3177 tab.~\ref{tab:ioprio_args} che consentono di indicare un singolo processo, i
3178 processi di un \textit{process group} (tratteremo questo argomento in
3179 sez.~\ref{sec:sess_proc_group}) o tutti o processi di un utente.
3184 \begin{tabular}[c]{|c|c|l|}
3186 \param{which} & \param{who} & \textbf{Significato} \\
3189 \const{IPRIO\_WHO\_PROCESS} & \type{pid\_t} & processo\\
3190 \const{IPRIO\_WHO\_PRGR} & \type{pid\_t} & \itindex{process~group}
3191 \textit{process group}\\
3192 \const{IPRIO\_WHO\_USER} & \type{uid\_t} & utente\\
3195 \caption{Legenda del valore dell'argomento \param{which} e del tipo
3196 dell'argomento \param{who} delle funzioni \func{ioprio\_get} e
3197 \func{ioprio\_set} per le tre possibili scelte.}
3198 \label{tab:ioprio_args}
3201 In caso di successo \func{ioprio\_get} restituisce un intero positivo che
3202 esprime il valore della priorità di I/O, questo valore è una maschera binaria
3203 composta da due parti, una che esprime la \textsl{classe} di scheduling di I/O
3204 del processo, l'altra che esprime, quando la classe di scheduling lo prevede,
3205 la priorità del processo all'interno della classe stessa. Questo stesso
3206 formato viene utilizzato per indicare il valore della priorità da impostare
3207 con l'argomento \param{ioprio} di \func{ioprio\_set}.
3209 Per la gestione dei valori che esprimono le priorità di I/O sono state
3210 definite delle opportune macro di preprocessore, riportate in
3211 tab.~\ref{tab:IOsched_class_macro}. I valori delle priorità si ottengono o si
3212 impostano usando queste macro. Le prime due si usano con il valore restituito
3213 da \func{ioprio\_get} e per ottenere rispettivamente la classe di
3214 scheduling\footnote{restituita dalla macro con i valori di
3215 tab.~\ref{tab:IOsched_class}.} e l'eventuale valore della priorità. La terza
3216 macro viene invece usata per creare un valore di priorità da usare come
3217 argomento di \func{ioprio\_set} per eseguire una impostazione.
3222 \begin{tabular}[c]{|l|p{8cm}|}
3224 \textbf{Macro} & \textbf{Significato}\\
3227 \macro{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
3228 & dato il valore di una priorità come
3229 restituito da \func{ioprio\_get} estrae il
3230 valore della classe.\\
3231 \macro{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
3232 & dato il valore di una priorità come
3233 restituito da \func{ioprio\_get} estrae il
3234 valore della priorità.\\
3235 \macro{IOPRIO\_PRIO\_VALUE}\texttt{(\textit{class},\textit{prio})}
3236 & dato un valore di priorità ed una classe
3237 ottiene il valore numerico da passare a
3238 \func{ioprio\_set}.\\
3241 \caption{Le macro per la gestione dei valori numerici .}
3242 \label{tab:IOsched_class_macro}
3245 Le classi di scheduling previste dallo scheduler CFQ sono tre, e ricalcano tre
3246 diverse modalità di distribuzione delle risorse analoghe a quelle già adottate
3247 anche nel funzionamento dello scheduler del processore. Ciascuna di esse è
3248 identificata tramite una opportuna costante, secondo quanto riportato in
3249 tab.~\ref{tab:IOsched_class}.
3251 La classe di priorità più bassa è \const{IOPRIO\_CLASS\_IDLE}; i processi in
3252 questa classe riescono ad accedere a disco soltanto quando nessun altro
3253 processo richiede l'accesso. Occorre pertanto usarla con molta attenzione,
3254 perché un processo in questa classe può venire completamente bloccato quando
3255 ci sono altri processi in una qualunque delle altre due classi che stanno
3256 accedendo al disco. Quando si usa questa classe non ha senso indicare un
3257 valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la
3258 priorità è identica, la minima possibile, per tutti i processi.
3263 \begin{tabular}[c]{|l|l|}
3265 \textbf{Classe} & \textbf{Significato} \\
3268 \const{IOPRIO\_CLASS\_RT} & Scheduling di I/O \textit{real time}.\\
3269 \const{IOPRIO\_CLASS\_BE} & Scheduling di I/O ordinario.\\
3270 \const{IOPRIO\_CLASS\_IDLE}& Scheduling di I/O di priorità minima.\\
3273 \caption{Costanti che identificano le classi di scheduling di I/O.}
3274 \label{tab:IOsched_class}
3277 La seconda classe di priorità di I/O è \const{IOPRIO\_CLASS\_BE} (il nome sta
3278 per \textit{best-effort}) che è quella usata ordinariamente da tutti
3279 processi. In questo caso esistono priorità diverse che consentono di
3280 assegnazione di una maggiore banda passante nell'accesso a disco ad un
3281 processo rispetto agli altri, con meccanismo simile a quello dei valori di
3282 \textit{nice} in cui si evita che un processo a priorità più alta possa
3283 bloccare indefinitamente quelli a priorità più bassa. In questo caso però le
3284 diverse priorità sono soltanto otto, indicate da un valore numerico fra 0 e 7
3285 e come per \textit{nice} anche in questo caso un valore più basso indica una
3289 Infine la classe di priorità di I/O \textit{real-time}
3290 \const{IOPRIO\_CLASS\_RT} ricalca le omonime priorità di processore: un
3291 processo in questa classe ha sempre la precedenza nell'accesso a disco
3292 rispetto a tutti i processi delle altre classi e di un processo nella stessa
3293 classe ma con priorità inferiore, ed è pertanto in grado di bloccare
3294 completamente tutti gli altri. Anche in questo caso ci sono 8 priorità diverse
3295 con un valore numerico fra 0 e 7, con una priorità più elevata per valori più
3298 In generale nel funzionamento ordinario la priorità di I/O di un processo
3299 viene impostata in maniera automatica nella classe \const{IOPRIO\_CLASS\_BE}
3300 con un valore ottenuto a partire dal corrispondente valore di \textit{nice}
3301 tramite la formula: $\mathtt{\mathit{prio}}=(\mathtt{\mathit{nice}}+20)/5$. Un
3302 utente ordinario può modificare con \func{ioprio\_set} soltanto le priorità
3303 dei processi che gli appartengono,\footnote{per la modifica delle priorità di
3304 altri processi occorrono privilegi amministrativi, ed in particolare la
3305 capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
3306 cioè quelli il cui user-ID reale corrisponde all'user-ID reale o effettivo del
3307 chiamante. Data la possibilità di ottenere un blocco totale del sistema, solo
3308 l'amministratore\footnote{o un processo con la capacità
3309 \const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
3310 impostare un processo ad una priorità di I/O nella classe
3311 \const{IOPRIO\_CLASS\_RT}, lo stesso privilegio era richiesto anche per la
3312 classe \const{IOPRIO\_CLASS\_IDLE} fino al kernel 2.6.24, ma dato che in
3313 questo caso non ci sono effetti sugli altri processi questo limite è stato
3314 rimosso a partire dal kernel 2.6.25.
3316 %TODO verificare http://lwn.net/Articles/355987/
3318 %TODO trattare le funzionalità per il NUMA
3319 % vedi man numa e le pagine di manuale relative
3320 % vedere anche dove metterle...
3323 \section{Funzioni di gestione avanzata}
3324 \label{sec:proc_advanced_control}
3326 Nelle precedenti sezioni si sono trattate la gran parte delle funzioni che
3327 attengono alla gestione ordinaria dei processi e delle loro proprietà più
3328 comuni. Tratteremo qui alcune \textit{system call} dedicate alla gestione di
3329 funzionalità dei processi molto specifiche ed avanzate, il cui uso è in genere
3330 piuttosto ridotto. Trattandosi di problematiche abbastanza complesse, che
3331 spesso presuppongono la conoscenza di altri argomenti trattati nel seguito
3332 della guida, si può saltare questa sezione in una prima lettura, tornando su
3333 di essa in un secondo tempo.
3335 \subsection{La \textit{system call} \func{clone}}
3336 \label{sec:process_clone}
3338 La funzione tradizionale con cui creare un nuovo processo in un sistema
3339 Unix-like, come illustrato in sez.~\ref{sec:proc_fork}, è \func{fork}, ma con
3340 l'introduzione del supporto del kernel per i \textit{thread} (vedi
3341 cap.~\ref{cha:threads}), si è avuta la necessità di una interfaccia che
3342 consentisse un maggiore controllo sulla modalità con cui vengono creati nuovi
3343 processi, che poi è stata utilizzata anche per fornire supporto per le
3344 tecnologie di virtualizzazione dei processi (i cosiddetti \textit{container}).
3346 Per questo l'interfaccia per la creazione di un nuovo processo è stata
3347 delegata ad una nuova \textit{system call}, \func{sys\_clone}, che consente di
3348 reimplementare anche la tradizionale \func{fork}. In realtà in questo caso più
3349 che di nuovi processi si può parlare della creazioni di nuovi
3350 ``\textit{task}'' del kernel che possono assumere la veste sia di un processo
3351 classico come quelli trattati finora, che di un \textit{thread}, come quelli
3352 che vedremo in sez.~\ref{sec:linux_thread}, in cui la memoria viene condivisa
3353 fra il processo chiamante ed il nuovo processo creato. Per evitare confusione
3354 fra \textit{thread} e processi ordinari, abbiamo deciso di usare la
3355 nomenclatura \textit{task} per indicare la unità di esecuzione generica messa
3356 a disposizione del kernel che \texttt{sys\_clone} permette di creare.
3358 Oltre a questo la funzione consente, ad uso delle nuove funzionalità di
3359 virtualizzazione dei processi, di creare nuovi \textit{namespace} per una
3360 serie di proprietà generali dei processi (come l'elenco dei PID, l'albero dei
3361 file, dei \textit{mount point}, della rete, ecc.), che consentono di creare
3362 gruppi di processi che vivono in una sorta di spazio separato dagli altri, che
3363 costituisce poi quello che viene chiamato un \textit{container}.
3365 La \textit{system call} richiede soltanto due argomenti: il
3366 primo, \param{flags}, consente di controllare le modalità di creazione del
3367 nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo
3368 dello \itindex{stack} \textit{stack} per il nuovo \textit{task}, e deve essere
3369 indicato quando si intende creare un \textit{thread}. L'esecuzione del
3370 programma creato da \func{sys\_clone} riprende, come per \func{fork}, da
3371 dopo l'esecuzione della stessa.
3373 La necessità di avere uno \itindex{stack} \textit{stack} alternativo c'è solo
3374 quando si intende creare un \textit{thread}, in tal caso infatti il nuovo
3375 \textit{task} vede esattamente la stessa memoria del \textit{task}
3376 ``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente
3377 il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task}
3378 da essa creato, senza nessuna delle implicazioni che il concetto ha per i
3379 processi.} e nella sua esecuzione alla prima chiamata di una funzione
3380 andrebbe a scrivere sullo \textit{stack} usato anche dal padre (si ricordi
3381 quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso dello
3384 Per evitare di doversi garantire contro la evidente possibilità di
3385 \itindex{race~condition} \textit{race condition} che questa situazione
3386 comporta (vedi sez.~\ref{sec:proc_race_cond} per una spiegazione della
3387 problematica) è necessario che il chiamante allochi preventivamente un'area di
3388 memoria. In genere lo si fa con una \func{malloc} che allochi un buffer che
3389 la funzione imposterà come \textit{stack} del nuovo processo, avendo
3390 ovviamente cura di non utilizzarlo direttamente nel processo chiamante. In
3391 questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e
3392 non si dovranno affrontare problematiche di \itindex{race~condition}
3393 \textit{race condition}. Si tenga presente inoltre che in molte architetture
3394 di processore lo \textit{stack} cresce verso il basso, pertanto in tal caso
3395 non si dovrà specificare per \param{child\_stack} il puntatore restituito da
3396 \func{malloc}, ma un puntatore alla fine del buffer da essa allocato.
3398 Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la
3399 memoria, la \textit{system call}, a differenza della funzione di libreria che
3400 vedremo a breve, consente anche di passare per \param{child\_stack} il valore
3401 \val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
3402 processo, questo ottiene un suo nuovo spazio degli indirizzi,\footnote{è
3403 sottinteso cioè che non si stia usando il flag \const{CLONE\_VM}.} ed in
3404 questo caso si applica la semantica del \itindex{copy~on~write} \textit{copy
3405 on write} illustrata in sez.~\ref{sec:proc_fork}, per cui le pagine dello
3406 \textit{stack} verranno automaticamente copiate come le altre e il nuovo
3407 processo avrà un suo \textit{stack} totalmente indipendente da quello del
3410 Dato che l'uso principale della nuova \textit{system call} è quello relativo
3411 alla creazione dei \textit{thread}, le \acr{glibc} definiscono una funzione di
3412 libreria con una sintassi diversa, orientata a questo scopo, e la
3413 \textit{system call} resta accessibile solo se invocata esplicitamente come
3414 visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa
3415 \textit{system call} non è disponibile la chiamata veloce con
3416 \texttt{vsyscall}.} La funzione di libreria si chiama semplicemente
3417 \funcd{clone} ed il suo prototipo è:
3419 \headdecl{sys/sched.h}
3421 \funcdecl{int clone(int (*fn)(void *), void *child\_stack, int
3422 flags, void *arg, ... \\
3423 /* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */)}
3425 Crea un nuovo processo o \textit{thread} eseguendo la funzione \param{fn}.
3427 \bodydesc{La funzione ritorna al chiamante il \textit{Thread ID} assegnato
3428 al nuovo processo in caso di successo e $-1$ in caso di errore, nel qual
3429 caso \var{errno} può assumere i valori:
3431 \item[\errcode{EAGAIN}] sono già in esecuzione troppi processi.
3432 \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o
3433 un valore nullo per \param{child\_stack}.
3434 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova
3435 \struct{task\_struct} o per copiare le parti del contesto del chiamante
3436 necessarie al nuovo \textit{task}.
3437 \item[\errcode{EPERM}] non si hanno i privilegi di amministratore
3438 richiesti dai flag indicati.
3443 La funzione prende come primo argomento il puntatore alla funzione che verrà
3444 messa in esecuzione nel nuovo processo, che può avere un unico argomento di
3445 tipo puntatore a \ctyp{void}, il cui valore viene passato dal terzo
3446 argomento \param{arg}; per quanto il precedente prototipo possa intimidire
3447 nella sua espressione, in realtà l'uso è molto semplice basterà definire una
3448 qualunque funzione \param{fn} del tipo indicato, e \code{fn(arg)} sarà
3449 eseguita in un nuovo processo.
3451 Il nuovo processo resterà in esecuzione fintanto che la funzione \param{fn}
3452 non ritorna, o esegue \func{exit} o viene terminata da un segnale. Il valore
3453 di ritorno della funzione (o quello specificato con \func{exit}) verrà
3454 utilizzato come stato di uscita della funzione.
3456 I tre argomenti \param{ptid}, \param{tls} e \param{ctid} sono opzionali e sono
3457 presenti solo a partire dal kernel 2.6.
3459 Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
3460 nuovo processo da essa creato, è controllato dall'argomento \param{flags},
3462 \begin{basedescript}{\desclabelstyle{\pushlabel}}
3464 \item[\const{CLONE\_CHILD\_CLEARTID}]
3465 \item[\const{CLONE\_CHILD\_SETTID}]
3466 \item[\const{CLONE\_FILES}]
3467 \item[\const{CLONE\_FS}]
3468 \item[\const{CLONE\_IO}]
3469 \item[\const{CLONE\_NEWIPC}]
3470 \item[\const{CLONE\_NEWNET}]
3471 \item[\const{CLONE\_NEWNS}]
3472 \item[\const{CLONE\_NEWPID}]
3473 \item[\const{CLONE\_NEWUTS}]
3474 \item[\const{CLONE\_PARENT}]
3475 \item[\const{CLONE\_PARENT\_SETTID}]
3476 \item[\const{CLONE\_PID}]
3477 \item[\const{CLONE\_PTRACE}]
3478 \item[\const{CLONE\_SETTLS}]
3479 \item[\const{CLONE\_SIGHAND}]
3480 \item[\const{CLONE\_STOPPED}]
3481 \item[\const{CLONE\_SYSVSEM}]
3482 \item[\const{CLONE\_THREAD}]
3483 \item[\const{CLONE\_UNTRACED}]
3484 \item[\const{CLONE\_VFORK}]
3485 \item[\const{CLONE\_VM}]
3489 \subsection{La funzione \func{prctl}}
3490 \label{sec:process_prctl}
3492 Benché la gestione ordinaria possa essere effettuata attraverso le funzioni
3493 che abbiamo già esaminato nelle sezioni precedenti, esistono una serie di
3494 proprietà e caratteristiche particolari dei processi non coperte da esse, per
3495 la cui gestione è stata predisposta una apposita \textit{system call} che
3496 fornisce una interfaccia generica per tutte le operazioni specialistiche. La
3497 funzione è \funcd{prctl} ed il suo prototipo è:\footnote{la funzione non è
3498 standardizzata ed è specifica di Linux, anche se ne esiste una analoga in
3499 IRIX; è stata introdotta con il kernel 2.1.57.}
3501 \headdecl{sys/prctl.h}
3503 \funcdecl{int prctl(int option, unsigned long arg2, unsigned long arg3,
3504 unsigned long arg4, unsigned long arg5)}
3506 Esegue una operazione speciale sul processo corrente.
3508 \bodydesc{La funzione ritorna 0 o un valore positivo dipendente
3509 dall'operazione in caso di successo e $-1$ in caso di errore, nel qual
3510 caso \var{errno} assumerà valori diversi a seconda del tipo di operazione
3511 richiesta (in genere \errval{EINVAL} o \errval{EPERM}). }
3514 La funzione ritorna un valore nullo o positivo in caso di successo e $-1$ in
3515 caso di errore; il significato degli argomenti della funzione successivi al
3516 primo, il valore di ritorno in caso di successo, il tipo di errore restituito
3517 in \var{errno} dipendono dall'operazione eseguita, indicata tramite il primo
3518 argomento, \param{option}. Questo è un valore intero che identifica
3519 l'operazione, e deve essere specificato con l'uso di una delle costanti
3520 predefinite del seguente elenco, che illustra quelle disponibili al momento:
3522 \begin{basedescript}{\desclabelstyle{\pushlabel}}
3523 \item[\const{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
3524 \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}). La funzione
3525 ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una
3526 delle costanti di tab.~\ref{tab:proc_capabilities}) è presente nel
3527 \textit{capabilities bounding set} del processo e zero altrimenti,
3528 se \param{arg2} non è un valore valido si avrà un errore di \errval{EINVAL}.
3529 Introdotta a partire dal kernel 2.6.25.
3530 \item[\const{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle
3531 \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}) dal processo e
3532 da tutti i suoi discendenti. La funzione cancella la capacità specificata
3533 nell'argomento \param{arg2} con una delle costanti di
3534 tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} del
3535 processo. L'operazione richiede i privilegi di amministratore (la capacità
3536 \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di
3537 \errval{EPERM}; se il valore di \param{arg2} non è valido o se il supporto
3538 per le \textit{file capabilities} non è stato compilato nel kernel la
3539 chiamata fallirà con un errore di \errval{EINVAL}. Introdotta a partire dal
3541 \item[\const{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la
3542 terminazione di un processo a causa di un segnale per il quale è prevista la
3543 generazione di un file di \itindex{core~dump} \textit{core dump} (vedi
3544 sez.~\ref{sec:sig_standard}) lo genera effettivamente. In genere questo flag
3545 viene attivato automaticamente, ma per evitare problemi di sicurezza (la
3546 generazione di un file da parte di processi privilegiati può essere usata
3547 per sovrascriverne altri) viene cancellato quando si mette in esecuzione un
3548 programma con i bit \acr{suid} e \acr{sgid} attivi (vedi
3549 sez.~\ref{sec:file_special_perm}) o con l'uso delle funzioni per la modifica
3550 degli \textit{user-ID} dei processi (vedi
3551 sez.~\ref{sec:proc_setuid}). L'operazione è stata introdotta a partire dal
3552 kernel 2.3.20, fino al kernel 2.6.12 e per i kernel successivi al 2.6.17 era
3553 possibile usare solo un valore 0 di \param{arg2} per disattivare il flag ed
3554 un valore 1 per attivarlo, nei kernel dal 2.6.13 al 2.6.17 è stato
3555 supportato anche il valore 2, che causava la generazione di un
3556 \itindex{core~dump} \textit{core dump} leggibile solo
3557 dall'amministratore.\footnote{la funzionalità è stata rimossa per motivi di
3558 sicurezza, in quanto consentiva ad un utente normale di creare un file di
3559 \textit{core dump} appartenente all'amministratore in directory dove
3560 l'utente avrebbe avuto permessi di accesso.}
3561 \item[\const{PR\_GET\_DUMPABLE}] Ottiene come valore di ritorno della funzione
3562 lo stato corrente del flag che controlla la effettiva generazione dei
3563 \itindex{core~dump} \textit{core dump}. Introdotta a partire dal kernel
3565 \item[\const{PR\_SET\_ENDIAN}] Imposta la \textit{endianness} del processo
3566 chiamante secondo il valore fornito in \param{arg2}. I valori possibili sono
3567 sono: \const{PR\_ENDIAN\_BIG} (\textit{big endian}),
3568 \const{PR\_ENDIAN\_LITTLE} (\textit{little endian}), e
3569 \const{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
3570 PowerPC). Introdotta a partire dal kernel 2.6.18, solo per architettura
3572 \item[\const{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianness} del
3573 processo chiamante, salvato sulla variabile puntata da \param{arg2} che deve
3574 essere passata come di tipo \ctyp{(int *)}. Introdotta a partire dal kernel
3575 2.6.18, solo su PowerPC.
3576 \item[\const{PR\_SET\_FPEMU}] Imposta i bit di controllo per l'emulazione
3577 della virgola mobile su architettura ia64, secondo il valore
3578 di \param{arg2}, si deve passare \const{PR\_FPEMU\_NOPRINT} per emulare in
3579 maniera trasparente l'accesso alle operazioni in virgola mobile, o
3580 \const{PR\_FPEMU\_SIGFPE} per non emularle ed inviare il segnale
3581 \signal{SIGFPE} (vedi sez.~\ref{sec:sig_prog_error}). Introdotta a partire
3582 dal kernel 2.4.18, solo su ia64.
3583 \item[\const{PR\_GET\_FPEMU}] Ottiene il valore dei flag di controllo
3584 dell'emulazione della virgola mobile, salvato all'indirizzo puntato
3585 da \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta a
3586 partire dal kernel 2.4.18, solo su ia64.
3587 \item[\const{PR\_SET\_FPEXC}] Imposta la modalità delle eccezioni in virgola
3588 mobile (\textit{floating-point exception mode}) al valore di \param{arg2}.
3589 I valori possibili sono: \const{PR\_FP\_EXC\_SW\_ENABLE} per usare FPEXC per
3590 le eccezioni, \const{PR\_FP\_EXC\_DIV} per la divisione per zero in virgola
3591 mobile, \const{PR\_FP\_EXC\_OVF} per gli overflow, \const{PR\_FP\_EXC\_UND}
3592 per gli underflow, \const{PR\_FP\_EXC\_RES} per risultati non esatti,
3593 \const{PR\_FP\_EXC\_INV} per operazioni invalide,
3594 \const{PR\_FP\_EXC\_DISABLED} per disabilitare le eccezioni,
3595 \const{PR\_FP\_EXC\_NONRECOV} per utilizzare la modalità di eccezione
3596 asincrona non recuperabile, \const{PR\_FP\_EXC\_ASYNC} per utilizzare la
3597 modalità di eccezione asincrona recuperabile, \const{PR\_FP\_EXC\_PRECISE}
3598 per la modalità precisa di eccezione.\footnote{trattasi di gestione
3599 specialistica della gestione delle eccezioni dei calcoli in virgola mobile
3600 che, i cui dettagli al momento vanno al di là dello scopo di questo
3601 testo.} Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
3602 \item[\const{PR\_GET\_FPEXC}] Ottiene il valore della modalità delle eccezioni
3603 delle operazioni in virgola mobile, salvata all'indirizzo
3604 puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta a
3605 partire dal kernel 2.4.21, solo su PowerPC.
3606 \item[\const{PR\_SET\_KEEPCAPS}] Consente di controllare quali
3607 \textit{capabilities} vengono cancellate quando si esegue un cambiamento di
3608 \textit{user-ID} del processo (per i dettagli si veda
3609 sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a
3610 pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default)
3611 per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano
3612 mantenute, questo valore viene sempre cancellato attraverso una \func{exec}.
3613 L'uso di questo flag è stato sostituito, a partire dal kernel 2.6.26, dal
3614 flag \const{SECURE\_KEEP\_CAPS} dei \itindex{securebits} \textit{securebits}
3615 (vedi l'uso di \const{PR\_SET\_SECUREBITS} più avanti). Introdotta a partire
3617 \item[\const{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione
3618 il valore del flag di controllo impostato con
3619 \const{PR\_SET\_KEEPCAPS}. Introdotta a partire dal kernel 2.2.18.
3620 \item[\const{PR\_SET\_NAME}] Imposta il nome del processo chiamante alla
3621 stringa puntata da \param{arg2}, che deve essere di tipo \code{(char *)}. Il
3622 nome può essere lungo al massimo 16 caratteri, e la stringa deve essere
3623 terminata da NUL se più corta. Introdotta a partire dal kernel 2.6.9.
3624 \item[\const{PR\_GET\_NAME}] Ottiene il nome del processo chiamante nella
3625 stringa puntata da \param{arg2}, che deve essere di tipo \code{(char *)}; si
3626 devono allocare per questo almeno 16 byte, e il nome sarà terminato da NUL
3627 se più corto. Introdotta a partire dal kernel 2.6.9.
3628 \item[\const{PR\_SET\_PDEATHSIG}] Consente di richiedere l'emissione di un
3629 segnale, che sarà ricevuto dal processo chiamante, in occorrenza della
3630 terminazione del proprio processo padre; in sostanza consente di invertire
3631 il ruolo di \signal{SIGCHLD}. Il valore di \param{arg2} deve indicare il
3632 numero del segnale, o 0 per disabilitare l'emissione. Il valore viene
3633 automaticamente cancellato per un processo figlio creato con \func{fork}.
3634 Introdotta a partire dal kernel 2.1.57.
3635 \item[\const{PR\_GET\_PDEATHSIG}] Ottiene il valore dell'eventuale segnale
3636 emesso alla terminazione del padre, salvato all'indirizzo
3637 puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta a
3638 partire dal kernel 2.3.15.
3639 \item[\const{PR\_SET\_SECCOMP}] Imposta il cosiddetto
3640 \itindex{secure~computing~mode} \textit{secure computing mode} per il
3641 processo corrente. Prevede come unica possibilità che \param{arg2} sia
3642 impostato ad 1. Una volta abilitato il \textit{secure computing mode} il
3643 processo potrà utilizzare soltanto un insieme estremamente limitato di
3644 \textit{system call}: \func{read}, \func{write}, \func{\_exit} e
3645 \func{sigreturn}, ogni altra \textit{system call} porterà all'emissione di
3646 un \func{SIGKILL} (vedi sez.~\ref{sec:sig_termination}). Il \textit{secure
3647 computing mode} è stato ideato per fornire un supporto per l'esecuzione di
3648 codice esterno non fidato e non verificabile a scopo di calcolo;\footnote{lo
3649 scopo è quello di poter vendere la capacità di calcolo della proprio
3650 macchina ad un qualche servizio di calcolo distribuito senza
3651 comprometterne la sicurezza eseguendo codice non sotto il proprio
3652 controllo.} in genere i dati vengono letti o scritti grazie ad un socket o
3653 una pipe, e per evitare problemi di sicurezza non sono possibili altre
3654 operazioni se non quelle citate. Introdotta a partire dal kernel 2.6.23,
3655 disponibile solo se si è abilitato il supporto nel kernel con
3656 \texttt{CONFIG\_SECCOMP}.
3657 \item[\const{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
3658 lo stato corrente del \textit{secure computing mode}, al momento attuale la
3659 funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato
3660 che la chiamata di questa funzione in \textit{secure computing mode}
3661 comporterebbe l'emissione di \texttt{SIGKILL}, è stata comunque definita per
3662 eventuali estensioni future. Introdotta a partire dal kernel 2.6.23.
3663 \item[\const{PR\_SET\_SECUREBITS}] Imposta i \itindex{securebits}
3664 \textit{securebits} per il processo chiamante al valore indicato
3665 da \param{arg2}; per i dettagli sul significato dei \textit{securebits} si
3666 veda sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di
3667 tab.~\ref{tab:securebits_values} e la relativa trattazione. L'operazione
3668 richiede i privilegi di amministratore (la capacità \const{CAP\_SETPCAP}),
3669 altrimenti la chiamata fallirà con un errore di \errval{EPERM}. Introdotta a
3670 partire dal kernel 2.6.26.
3671 \item[\const{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della
3672 funzione l'impostazione corrente per i \itindex{securebits}
3673 \textit{securebits}. Introdotta a partire dal kernel 2.6.26.
3674 \item[\const{PR\_SET\_TIMING}] Imposta il metodo di temporizzazione del
3675 processo da indicare con il valore di \param{arg2}, con
3676 \const{PR\_TIMING\_STATISTICAL} si usa il metodo statistico tradizionale,
3677 con \const{PR\_TIMING\_TIMESTAMP} il più accurato basato su dei
3678 \textit{timestamp}, quest'ultimo però non è ancora implementato ed il suo
3679 uso comporta la restituzione di un errore di \errval{EINVAL}. Introdotta a
3680 partire dal kernel 2.6.0-test4.
3681 \item[\const{PR\_GET\_TIMING}] Ottiene come valore di ritorno della funzione
3682 il metodo di temporizzazione del processo attualmente in uso. Introdotta a
3683 partire dal kernel 2.6.0-test4.
3684 \item[\const{PR\_SET\_TSC}] Imposta il flag che indica se il processo
3685 chiamante può leggere il registro di processore contenente il contatore dei
3686 \textit{timestamp} (TSC, o \textit{Time Stamp Counter}) da indicare con il
3687 valore di \param{arg2}. Si deve specificare \const{PR\_TSC\_ENABLE} per
3688 abilitare la lettura o \const{PR\_TSC\_SIGSEGV} per disabilitarla con la
3689 generazione di un segnale di \signal{SIGSEGV} (vedi
3690 sez.~\ref{sec:sig_prog_error}). La lettura viene automaticamente
3691 disabilitata se si attiva il \textit{secure computing mode}. Introdotta a
3692 partire dal kernel 2.6.26, solo su x86.
3693 \item[\const{PR\_GET\_TSC}] Ottiene il valore del flag che controlla la
3694 lettura del contattore dei \textit{timestamp}, salvato all'indirizzo
3695 puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta a
3696 partire dal kernel 2.6.26, solo su x86.
3697 % articoli sul TSC e relativi problemi: http://lwn.net/Articles/209101/,
3698 % http://blog.cr0.org/2009/05/time-stamp-counter-disabling-oddities.html,
3699 % http://en.wikipedia.org/wiki/Time_Stamp_Counter
3700 \item[\const{PR\_SET\_UNALIGN}] Imposta la modalità di controllo per l'accesso
3701 a indirizzi di memoria non allineati, che in varie architetture risultano
3702 illegali, da indicare con il valore di \param{arg2}. Si deve specificare il
3703 valore \const{PR\_UNALIGN\_NOPRINT} per ignorare gli accessi non allineati,
3704 ed il valore \const{PR\_UNALIGN\_SIGBUS} per generare un segnale di
3705 \signal{SIGBUS} (vedi sez.~\ref{sec:sig_prog_error}) in caso di accesso non
3706 allineato. Introdotta con diverse versioni su diverse architetture.
3707 \item[\const{PR\_GET\_UNALIGN}] Ottiene il valore della modalità di controllo
3708 per l'accesso a indirizzi di memoria non allineati, salvato all'indirizzo
3709 puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta con
3710 diverse versioni su diverse architetture.
3711 \item[\const{PR\_MCE\_KILL}] Imposta la politica di gestione degli errori
3712 dovuti a corruzione della memoria per problemi hardware. Questo tipo di
3713 errori vengono riportati dall'hardware di controllo della RAM e vengono
3714 gestiti dal kernel,\footnote{la funzionalità è disponibile solo sulle
3715 piattaforme più avanzate che hanno il supporto hardware per questo tipo di
3716 controlli.} ma devono essere opportunamente riportati ai processi che
3717 usano quella parte di RAM che presenta errori; nel caso specifico questo
3718 avviene attraverso l'emissione di un segnale di \signal{SIGBUS} (vedi
3719 sez.~\ref{sec:sig_prog_error}).\footnote{in particolare viene anche
3720 impostato il valore di \var{si\_code} in \struct{siginfo\_t} a
3721 \const{BUS\_MCEERR\_AO}; per il significato di tutto questo si faccia
3722 riferimento alla trattazione di sez.~\ref{sec:sig_sigaction}.}
3724 Il comportamento di default prevede che per tutti i processi si applichi la
3725 politica generale di sistema definita nel file
3726 \procfile{/proc/sys/vm/memory\_failure\_early\_kill}, ma specificando
3727 per \param{arg2} il valore \const{PR\_MCE\_KILL\_SET} è possibile impostare
3728 con il contenuto di \param{arg3} una politica specifica del processo
3729 chiamante. Si può tornare alla politica di default del sistema utilizzando
3730 invece per \param{arg2} il valore \const{PR\_MCE\_KILL\_CLEAR}. In tutti i
3731 casi, per compatibilità con eventuali estensioni future, tutti i valori
3732 degli argomenti non utilizzati devono essere esplicitamente posti a zero,
3733 pena il fallimento della chiamata con un errore di \errval{EINVAL}.
3735 In caso di impostazione di una politica specifica del processo con
3736 \const{PR\_MCE\_KILL\_SET} i valori di \param{arg3} possono essere soltanto
3737 due, che corrispondono anche al valore che si trova nell'impostazione
3738 generale di sistema di \texttt{memory\_failure\_early\_kill}, con
3739 \const{PR\_MCE\_KILL\_EARLY} si richiede l'emissione immediata di
3740 \signal{SIGBUS} non appena viene rilevato un errore, mentre con
3741 \const{PR\_MCE\_KILL\_LATE} il segnale verrà inviato solo quando il processo
3742 tenterà un accesso alla memoria corrotta. Questi due valori corrispondono
3743 rispettivamente ai valori 1 e 0 di
3744 \texttt{memory\_failure\_early\_kill}.\footnote{in sostanza nel primo caso
3745 viene immediatamente inviato il segnale a tutti i processi che hanno la
3746 memoria corrotta mappata all'interno del loro spazio degli indirizzi, nel
3747 secondo caso prima la pagina di memoria viene tolta dallo spazio degli
3748 indirizzi di ciascun processo, mentre il segnale viene inviato solo quei
3749 processi che tentano di accedervi.} Si può usare per \param{arg3} anche un
3750 terzo valore, \const{PR\_MCE\_KILL\_DEFAULT}, che corrisponde a impostare
3751 per il processo la politica di default.\footnote{si presume la politica di
3752 default corrente, in modo da non essere influenzati da un eventuale
3753 successivo cambiamento della stessa.} Introdotta a partire dal kernel
3755 \item[\const{PR\_MCE\_KILL\_GET}] Ottiene come valore di ritorno della
3756 funzione la politica di gestione degli errori dovuti a corruzione della
3757 memoria. Tutti gli argomenti non utilizzati (al momento tutti) devono essere
3758 nulli pena la ricezione di un errore di \errval{EINVAL}. Introdotta a
3759 partire dal kernel 2.6.32.
3760 \label{sec:prctl_operation}
3766 \subsection{La funzione \func{ptrace}}
3767 \label{sec:process_ptrace}
3771 % TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1
3774 \subsection{L'accesso alle porte di I/O}
3775 \label{sec:process_io_port}
3778 % TODO l'I/O sulle porte di I/O
3779 % consultare le manpage di ioperm, iopl e outb
3783 % TODO: funzioni varie sparse citate da qualche parte e da trattare forse in
3784 % una sezione a parte: sigreturn,
3787 \section{Problematiche di programmazione multitasking}
3788 \label{sec:proc_multi_prog}
3790 Benché i processi siano strutturati in modo da apparire il più possibile come
3791 indipendenti l'uno dall'altro, nella programmazione in un sistema multitasking
3792 occorre tenere conto di una serie di problematiche che normalmente non
3793 esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
3794 programma alla volta.
3796 Pur essendo questo argomento di carattere generale, ci è parso opportuno
3797 introdurre sinteticamente queste problematiche, che ritroveremo a più riprese
3798 in capitoli successivi, in questa sezione conclusiva del capitolo in cui
3799 abbiamo affrontato la gestione dei processi.
3802 \subsection{Le operazioni atomiche}
3803 \label{sec:proc_atom_oper}
3805 La nozione di \textsl{operazione atomica} deriva dal significato greco della
3806 parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
3807 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
3808 che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
3809 di interruzione in una fase intermedia.
3811 In un ambiente multitasking il concetto è essenziale, dato che un processo può
3812 essere interrotto in qualunque momento dal kernel che mette in esecuzione un
3813 altro processo o dalla ricezione di un segnale; occorre pertanto essere
3814 accorti nei confronti delle possibili \itindex{race~condition} \textit{race
3815 condition} (vedi sez.~\ref{sec:proc_race_cond}) derivanti da operazioni
3816 interrotte in una fase in cui non erano ancora state completate.
3818 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
3819 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
3820 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
3821 cap.~\ref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
3822 sez.~\ref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
3823 funzioni di libreria per compiere le operazioni necessarie è garanzia
3824 sufficiente di atomicità in quanto le \textit{system call} con cui esse sono
3825 realizzate non possono essere interrotte (o subire interferenze pericolose) da
3828 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
3829 stesso processo, e pure alcune \textit{system call}, possono essere interrotti
3830 in qualunque momento, e le operazioni di un eventuale \textit{signal handler}
3831 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
3832 il solo accesso o l'assegnazione di una variabile possono non essere più
3833 operazioni atomiche (torneremo su questi aspetti in
3834 sez.~\ref{sec:sig_adv_control}).
3836 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
3837 il cui accesso è assicurato essere atomico. In pratica comunque si può
3838 assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
3839 \ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
3840 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
3841 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
3842 le strutture. In tutti questi casi è anche opportuno marcare come
3843 \direct{volatile} le variabili che possono essere interessate ad accesso
3844 condiviso, onde evitare problemi con le ottimizzazioni del codice.
3848 \subsection{Le \textit{race condition} ed i \textit{deadlock}}
3849 \label{sec:proc_race_cond}
3851 \itindbeg{race~condition}
3853 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
3854 diversi operano su una risorsa comune, ed in cui il risultato viene a
3855 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
3856 tipico è quello di un'operazione che viene eseguita da un processo in più
3857 passi, e può essere compromessa dall'intervento di un altro processo che
3858 accede alla stessa risorsa quando ancora non tutti i passi sono stati
3861 Dato che in un sistema multitasking ogni processo può essere interrotto in
3862 qualunque momento per farne subentrare un altro in esecuzione, niente può
3863 assicurare un preciso ordine di esecuzione fra processi diversi o che una
3864 sezione di un programma possa essere eseguita senza interruzioni da parte di
3865 altri. Queste situazioni comportano pertanto errori estremamente subdoli e
3866 difficili da tracciare, in quanto nella maggior parte dei casi tutto
3867 funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
3869 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
3870 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
3871 gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
3872 \textit{race condition} si hanno quando diversi processi accedono allo stesso
3873 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
3874 condivisa. In questi casi, se non si dispone della possibilità di eseguire
3875 atomicamente le operazioni necessarie, occorre che quelle parti di codice in
3876 cui si compiono le operazioni sulle risorse condivise (le cosiddette
3877 \index{sezione~critica} \textsl{sezioni critiche}) del programma, siano
3878 opportunamente protette da meccanismi di sincronizzazione (torneremo su queste
3879 problematiche di questo tipo in cap.~\ref{cha:IPC}).
3881 \itindbeg{deadlock} Un caso particolare di \textit{race condition} sono poi i
3882 cosiddetti \textit{deadlock} (traducibile in \textsl{condizioni di stallo}),
3883 particolarmente gravi in quanto comportano spesso il blocco completo di un
3884 servizio, e non il fallimento di una singola operazione. Per definizione un
3885 \textit{deadlock} è una situazione in cui due o più processi non sono più in
3886 grado di proseguire perché ciascuno aspetta il risultato di una operazione che
3887 dovrebbe essere eseguita dall'altro.
3889 L'esempio tipico di una situazione che può condurre ad un
3890 \textit{deadlock} è quello in cui un flag di
3891 ``\textsl{occupazione}'' viene rilasciato da un evento asincrono (come un
3892 segnale o un altro processo) fra il momento in cui lo si è controllato
3893 (trovandolo occupato) e la successiva operazione di attesa per lo sblocco. In
3894 questo caso, dato che l'evento di sblocco del flag è avvenuto senza che ce ne
3895 accorgessimo proprio fra il controllo e la messa in attesa, quest'ultima
3896 diventerà perpetua (da cui il nome di \textit{deadlock}).
3898 In tutti questi casi è di fondamentale importanza il concetto di atomicità
3899 visto in sez.~\ref{sec:proc_atom_oper}; questi problemi infatti possono essere
3900 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
3901 eseguire in maniera atomica le operazioni necessarie.
3902 \itindend{race~condition}
3906 \subsection{Le funzioni rientranti}
3907 \label{sec:proc_reentrant}
3909 \index{funzioni!rientranti|(}
3911 Si dice \textsl{rientrante} una funzione che può essere interrotta in
3912 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
3913 un altro \itindex{thread} \textit{thread} di esecuzione senza che questo
3914 comporti nessun problema nell'esecuzione della stessa. La problematica è
3915 comune nella programmazione \itindex{thread} \textit{multi-thread}, ma si
3916 hanno gli stessi problemi quando si vogliono chiamare delle funzioni
3917 all'interno dei gestori dei segnali.
3919 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
3920 queste infatti vengono allocate nello \itindex{stack} \textit{stack}, ed
3921 un'altra invocazione non fa altro che allocarne un'altra copia. Una funzione
3922 può non essere rientrante quando opera su memoria che non è nello
3923 \itindex{stack} \textit{stack}. Ad esempio una funzione non è mai rientrante
3924 se usa una \index{variabili!globali} variabile globale o
3925 \index{variabili!statiche} statica.
3927 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
3928 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
3929 ogni volta e ritornato indietro la funzione può essere rientrante, se invece
3930 esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
3931 potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
3932 Allo stesso modo una funzione può non essere rientrante se usa e modifica un
3933 oggetto che le viene fornito dal chiamante: due chiamate possono interferire
3934 se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
3935 parte del programmatore.
3937 In genere le funzioni di libreria non sono rientranti, molte di esse ad
3938 esempio utilizzano \index{variabili!statiche} variabili statiche, le
3939 \acr{glibc} però mettono a disposizione due macro di compilatore,\footnote{si
3940 ricordi quanto illustrato in sez.~\ref{sec:intro_gcc_glibc_std}.}
3941 \macro{\_REENTRANT} e \macro{\_THREAD\_SAFE}, la cui definizione attiva le
3942 versioni rientranti di varie funzioni di libreria, che sono identificate
3943 aggiungendo il suffisso \code{\_r} al nome della versione normale.
3945 \index{funzioni!rientranti|)}
3948 % LocalWords: multitasking like VMS child process identifier pid sez shell fig
3949 % LocalWords: parent kernel init pstree keventd kswapd table struct linux call
3950 % LocalWords: nell'header scheduler system interrupt timer HZ asm Hertz clock
3951 % LocalWords: l'alpha tick fork wait waitpid exit exec image glibc int pgid ps
3952 % LocalWords: sid thread Ingo Molnar ppid getpid getppid sys unistd LD threads
3953 % LocalWords: void ForkTest tempnam pathname sibling cap errno EAGAIN ENOMEM
3954 % LocalWords: stack read only copy write tab client spawn forktest sleep PATH
3955 % LocalWords: source LIBRARY scheduling race condition printf descriptor dup
3956 % LocalWords: close group session tms lock vfork execve BSD stream main abort
3957 % LocalWords: SIGABRT SIGCHLD SIGHUP foreground SIGCONT termination signal ANY
3958 % LocalWords: handler kill EINTR POSIX options WNOHANG ECHILD option WUNTRACED
3959 % LocalWords: dump bits rusage getrusage heap const filename argv envp EACCES
3960 % LocalWords: filesystem noexec EPERM suid sgid root nosuid ENOEXEC ENOENT ELF
3961 % LocalWords: ETXTBSY EINVAL ELIBBAD BIG EFAULT EIO ENAMETOOLONG ELOOP ENOTDIR
3962 % LocalWords: ENFILE EMFILE argc execl path execv execle execlp execvp vector
3963 % LocalWords: list environ NULL umask pending utime cutime ustime fcntl linker
3964 % LocalWords: opendir libc interpreter FreeBSD capabilities Mandatory Access
3965 % LocalWords: Control MAC SELinux Security Modules LSM superuser uid gid saved
3966 % LocalWords: effective euid egid dell' fsuid fsgid getuid geteuid getgid SVr
3967 % LocalWords: getegid IDS NFS setuid setgid all' logout utmp screen xterm TODO
3968 % LocalWords: setreuid setregid FIXME ruid rgid seteuid setegid setresuid size
3969 % LocalWords: setresgid getresuid getresgid value result argument setfsuid DAC
3970 % LocalWords: setfsgid NGROUPS sysconf getgroups getgrouplist groups ngroups
3971 % LocalWords: setgroups initgroups patch LIDS CHOWN OVERRIDE Discrectionary PF
3972 % LocalWords: SEARCH chattr sticky NOATIME socket domain immutable append mmap
3973 % LocalWords: broadcast multicast multicasting memory locking mlock mlockall
3974 % LocalWords: shmctl ioperm iopl chroot ptrace accounting swap reboot hangup
3975 % LocalWords: vhangup mknod lease permitted inherited inheritable bounding AND
3976 % LocalWords: capability capget capset header ESRCH undef version obj clear PT
3977 % LocalWords: pag ssize length proc capgetp preemptive cache runnable Stopped
3978 % LocalWords: Uninterrutible SIGSTOP soft slice nice niceness counter which SC
3979 % LocalWords: getpriority who setpriority RTLinux RTAI Adeos fault FIFO First
3980 % LocalWords: yield Robin setscheduler policy param OTHER priority setparam to
3981 % LocalWords: min getparam getscheduler interval robin ENOSYS fifo ping long
3982 % LocalWords: affinity setaffinity unsigned mask cpu NUMA CLR ISSET SETSIZE RR
3983 % LocalWords: getaffinity assembler deadlock REENTRANT SAFE tgz MYPGRP l'OR rr
3984 % LocalWords: WIFEXITED WEXITSTATUS WIFSIGNALED WTERMSIG WCOREDUMP WIFSTOPPED
3985 % LocalWords: WSTOPSIG opt char INTERP arg SIG IGN DFL mascheck grp FOWNER RAW
3986 % LocalWords: FSETID SETPCAP BIND SERVICE ADMIN PACKET IPC OWNER MODULE RAWIO
3987 % LocalWords: PACCT RESOURCE TTY CONFIG SETFCAP hdrp datap libcap lcap text tp
3988 % LocalWords: get ncap caps CapInh CapPrm fffffeff CapEff getcap STAT dall'I
3989 % LocalWords: inc PRIO SUSv PRGR prio SysV SunOS Ultrix sched timespec len sig
3990 % LocalWords: cpusetsize cpuset atomic tickless redirezione WCONTINUED stopped
3991 % LocalWords: waitid NOCLDSTOP ENOCHLD WIFCONTINUED ifdef endif idtype siginfo
3992 % LocalWords: infop ALL WEXITED WSTOPPED WNOWAIT signo CLD EXITED KILLED page
3993 % LocalWords: CONTINUED sources forking Spawned successfully executing exiting
3994 % LocalWords: next cat for COMMAND pts bash defunct TRAPPED DUMPED Killable PR
3995 % LocalWords: SIGKILL static RLIMIT preemption PREEMPT VOLUNTARY IDLE RTPRIO
3996 % LocalWords: completely fair compat uniform CFQ queuing elevator dev cfq RT
3997 % LocalWords: documentation block syscall ioprio IPRIO CLASS class best effort
3998 % LocalWords: refresh semop dnotify MADV DONTFORK prctl WCLONE WALL big mount
3999 % LocalWords: WNOTHREAD DUMPABLE KEEPCAPS IRIX CAPBSET endianness endian flags
4000 % LocalWords: little PPC PowerPC FPEMU NOPRINT SIGFPE FPEXC point FP SW malloc
4001 % LocalWords: exception EXC ENABLE OVF overflow UND underflow RES INV DISABLED
4002 % LocalWords: NONRECOV ASYNC KEEP securebits NAME NUL PDEATHSIG SECCOMP VM FS
4003 % LocalWords: secure computing sigreturn TIMING STATISTICAL TSC MCE conditions
4004 % LocalWords: timestamp Stamp SIGSEGV UNALIGN SIGBUS MCEERR AO failure early
4005 % LocalWords: namespace vsyscall SETTID FILES NEWIPC NEWNET NEWNS NEWPID ptid
4006 % LocalWords: NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID
4008 %%% Local Variables:
4010 %%% TeX-master: "gapil"