3 %% Copyright (C) 2000-2019 by Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
12 \chapter{La gestione dei processi}
13 \label{cha:process_handling}
15 Come accennato nell'introduzione in un sistema unix-like tutte le operazioni
16 vengono svolte tramite opportuni processi. In sostanza questi ultimi vengono
17 a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
19 Nel precedente capitolo abbiamo esaminato il funzionamento di un processo come
20 unità a se stante, in questo esamineremo il funzionamento dei processi
21 all'interno del sistema. Saranno cioè affrontati i dettagli della creazione e
22 della terminazione dei processi, della gestione dei loro attributi e
23 privilegi, e di tutte le funzioni a questo connesse. Infine nella sezione
24 finale introdurremo alcune problematiche generiche della programmazione in
25 ambiente \textit{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, dove 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 ID}, o più brevemente \ids{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 generato viene chiamato \textsl{processo padre} (\textit{parent
61 process}). Questo vale per tutti i processi, con una sola eccezione; dato
62 che ci deve essere un punto di partenza esiste un processo iniziale (che
63 normalmente è \cmd{/sbin/init}), che come accennato in
64 sez.~\ref{sec:intro_kern_and_sys} viene lanciato dal kernel alla conclusione
65 della fase di avvio. Essendo questo il primo processo lanciato dal sistema ha
66 sempre \ids{PID} uguale a 1 e non è figlio di nessun altro processo.
68 Ovviamente \cmd{init} è un processo particolare che in genere si occupa di
69 lanciare 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 sistemistica e
78 trattato in sez.~5.3 di \cite{AGL}.}
83 [piccardi@gont piccardi]$ \textbf{pstree -n}
100 |-bash---startx---xinit-+-XFree86
101 | `-WindowMaker-+-ssh-agent
109 | |-wterm---bash---pstree
110 | `-wterm---bash-+-emacs
117 \caption{L'albero dei processi, così come riportato dal comando
119 \label{fig:proc_tree}
122 Dato che tutti i processi attivi nel sistema sono comunque generati da
123 \cmd{init} o da uno dei suoi figli si possono classificare i processi con la
124 relazione padre/figlio in un'organizzazione gerarchica ad albero. In
125 fig.~\ref{fig:proc_tree} si è mostrato il risultato del comando \cmd{pstree}
126 che permette di visualizzare questa struttura, alla cui base c'è \cmd{init}
127 che è progenitore di tutti gli altri processi.\footnote{in realtà questo non è
128 del tutto vero, in Linux, specialmente nelle versioni più recenti del
129 kernel, ci sono alcuni processi speciali (come \cmd{keventd}, \cmd{kswapd},
130 ecc.) che pur comparendo nei comandi come figli di \cmd{init}, o con
131 \ids{PID} successivi ad uno, sono in realtà processi interni al kernel e che
132 non rientrano in questa classificazione.}
134 \itindbeg{process~table}
136 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
137 \textit{process table}. Per ciascun processo viene mantenuta una voce in
138 questa tabella, costituita da una struttura \kstruct{task\_struct}, che
139 contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
140 usate a questo scopo sono dichiarate nell'\textit{header file}
141 \file{linux/sched.h}, ed in fig.~\ref{fig:proc_task_struct} si è riportato uno
142 schema semplificato che mostra la struttura delle principali informazioni
143 contenute nella \texttt{task\_struct}, che in seguito incontreremo a più
147 \centering \includegraphics[width=14cm]{img/task_struct}
148 \caption{Schema semplificato dell'architettura delle strutture (
149 \kstructd{task\_struct}, \kstructd{fs\_struct}, \kstructd{file\_struct})
150 usate dal kernel nella gestione dei processi.}
151 \label{fig:proc_task_struct}
154 \itindend{process~table}
156 % TODO la task_struct è cambiata per qualche dettaglio vedi anche
157 % http://www.ibm.com/developerworks/linux/library/l-linux-process-management/
158 % TODO completare la parte su quando viene chiamato lo scheduler.
162 Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \textit{scheduler} che
163 decide quale processo mettere in esecuzione; esso viene eseguito in occasione
164 di dell'invocazione di ogni \textit{system call} ed per ogni interrupt
165 dall'hardware oltre che in una serie di altre occasioni, e può essere anche
166 attivato esplicitamente. Il timer di sistema provvede comunque a che esso sia
167 invocato periodicamente, generando un interrupt periodico secondo una
168 frequenza predeterminata, specificata dalla costante \const{HZ} del kernel
169 (torneremo su questo argomento in sez.~\ref{sec:sys_unix_time}), che assicura
170 che lo \textit{scheduler} venga comunque eseguito ad intervalli regolari e
171 possa prendere le sue decisioni.
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 Ma, indipendentemente dalle motivazioni per cui questo avviene, ogni volta che
183 viene eseguito lo \textit{scheduler} effettua il calcolo delle priorità dei
184 vari processi attivi (torneremo su questo in sez.~\ref{sec:proc_priority}) e
185 stabilisce quale di essi debba essere posto in esecuzione fino alla successiva
190 \subsection{Gli identificatori dei processi}
193 \itindbeg{Process~ID~(PID)}
195 Come accennato nella sezione precedente ogni processo viene identificato dal
196 sistema da un numero identificativo univoco, il \textit{process ID} o
197 \ids{PID}. Questo è un tipo di dato standard, \type{pid\_t}, che in genere è un
198 intero con segno (nel caso di Linux e della \acr{glibc} il tipo usato è
201 Il \ids{PID} viene assegnato in forma progressiva ogni volta che un nuovo
202 processo viene creato,\footnote{in genere viene assegnato il numero successivo
203 a quello usato per l'ultimo processo creato, a meno che questo numero non
204 sia già utilizzato per un altro \ids{PID}, \acr{pgid} o \acr{sid} (vedi
205 sez.~\ref{sec:sess_proc_group}).} fino ad un limite che, essendo il
206 tradizionalmente il \ids{PID} un numero positivo memorizzato in un intero a 16
207 bit, arriva ad un massimo di 32768. Oltre questo valore l'assegnazione
208 riparte dal numero più basso disponibile a partire da un minimo di
209 300,\footnote{questi valori, fino al kernel 2.4.x, erano definiti dalla macro
210 \constd{PID\_MAX} nei file \file{threads.h} e \file{fork.c} dei sorgenti del
211 kernel, con il 2.6.x e la nuova interfaccia per i \textit{thread} anche il
212 meccanismo di allocazione dei \ids{PID} è stato modificato ed il valore
213 massimo è impostabile attraverso il file \sysctlfiled{kernel/pid\_max} e di
214 default vale 32768.} che serve a riservare i \ids{PID} più bassi ai processi
215 eseguiti direttamente dal kernel. Per questo motivo, come visto in
216 sez.~\ref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha sempre il
217 \ids{PID} uguale a uno.
219 \itindbeg{Parent~Process~ID~(PPID)}
221 Tutti i processi inoltre memorizzano anche il \ids{PID} del genitore da cui
222 sono stati creati, questo viene chiamato in genere \ids{PPID} (da
223 \textit{Parent Process ID}). Questi due identificativi possono essere
224 ottenuti usando le due funzioni di sistema \funcd{getpid} e \funcd{getppid}, i
230 \fdecl{pid\_t getpid(void)}
231 \fdesc{Restituisce il \ids{PID} del processo corrente..}
232 \fdecl{pid\_t getppid(void)}
233 \fdesc{Restituisce il \ids{PID} del padre del processo corrente.}
235 {Entrambe le funzioni non riportano condizioni di errore.}
238 \noindent esempi dell'uso di queste funzioni sono riportati in
239 fig.~\ref{fig:proc_fork_code}, nel programma \file{fork\_test.c}.
241 Il fatto che il \ids{PID} sia un numero univoco per il sistema lo rende un
242 candidato per generare ulteriori indicatori associati al processo di cui
243 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
244 funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
245 \ids{PID} per generare un \textit{pathname} univoco, che non potrà essere
246 replicato da un altro processo che usi la stessa funzione. Questo utilizzo
247 però può risultare pericoloso, un \ids{PID} infatti è univoco solo fintanto
248 che un processo è attivo, una volta terminato esso potrà essere riutilizzato
249 da un processo completamente diverso, e di questo bisogna essere ben
252 Tutti i processi figli dello stesso processo padre sono detti
253 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
254 sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
255 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
256 cap.~\ref{cha:session}, dove esamineremo gli altri identificativi associati ad
257 un processo e le varie relazioni fra processi utilizzate per definire una
260 Oltre al \ids{PID} e al \ids{PPID}, e a quelli che vedremo in
261 sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione, ad ogni
262 processo vengono associati degli ulteriori identificatori ed in particolare
263 quelli che vengono usati per il controllo di accesso. Questi servono per
264 determinare se un processo può eseguire o meno le operazioni richieste, a
265 seconda dei privilegi e dell'identità di chi lo ha posto in esecuzione;
266 l'argomento è complesso e sarà affrontato in dettaglio in
267 sez.~\ref{sec:proc_perms}.
269 \itindend{Process~ID~(PID)}
270 \itindend{Parent~Process~ID~(PPID)}
272 \subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
273 \label{sec:proc_fork}
275 La funzione di sistema \func{fork} è la funzione fondamentale della gestione
276 dei processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
277 processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
278 \textit{system call} usata da Linux per creare nuovi processi è \func{clone}
279 (vedi \ref{sec:process_clone}), anche perché a partire dalla \acr{glibc}
280 2.3.3 non viene più usata la \textit{system call} originale, ma la stessa
281 \func{fork} viene implementata tramite \func{clone}, cosa che consente una
282 migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
283 centrale tutte le volte che si devono scrivere programmi che usano il
284 \textit{multitasking}.\footnote{oggi questa rilevanza, con la diffusione
285 dell'uso dei \textit{thread}\unavref{ che tratteremo al
286 cap.~\ref{cha:threads}}, è in parte minore, ma \func{fork} resta comunque
287 la funzione principale per la creazione di processi.} Il prototipo di
292 \fdecl{pid\_t fork(void)}
293 \fdesc{Crea un nuovo processo.}
296 {La funzione ritorna in caso di successo il \ids{PID} del figlio nel padre e
297 $0$ nel figlio mentre ritorna $-1$ nel padre, senza creare il figlio, per un
298 errore, al caso \var{errno} assumerà uno dei valori:
300 \item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro
301 processo (per allocare la tabella delle pagine e le strutture del task) o
302 si è esaurito il numero di processi disponibili.
303 \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
304 strutture necessarie al kernel per creare il nuovo processo.
308 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
309 il processo figlio continuano ad essere eseguiti normalmente, a partire
310 dall'istruzione successiva alla \func{fork}. Il processo figlio è una copia
311 del padre, e riceve una copia dei segmenti di testo, dati e dello
312 \textit{stack} (vedi sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo
313 stesso codice del padre. Si tenga presente però che la memoria è copiata e non
314 condivisa, pertanto padre e figlio vedranno variabili diverse e le eventuali
315 modifiche saranno totalmente indipendenti.
317 \itindbeg{copy~on~write}
319 Per quanto riguarda la gestione della memoria, in generale il segmento di
320 testo, che è identico per i due processi, è condiviso e tenuto in sola lettura
321 per il padre e per i figli. Per gli altri segmenti Linux utilizza la tecnica
322 del \textit{copy on write}. Questa tecnica comporta che una pagina di memoria
323 viene effettivamente copiata per il nuovo processo solo quando ci viene
324 effettuata sopra una scrittura, e si ha quindi una reale differenza fra padre
325 e figlio. In questo modo si rende molto più efficiente il meccanismo della
326 creazione di un nuovo processo, non essendo più necessaria la copia di tutto
327 lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di memoria
328 che sono state modificate, e solo al momento della modifica stessa.
330 \itindend{copy~on~write}
332 La differenza che si ha nei due processi è che nel processo padre il valore di
333 ritorno della funzione \func{fork} è il \ids{PID} del processo figlio, mentre
334 nel figlio è zero; in questo modo il programma può identificare se viene
335 eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
336 due volte, una nel padre e una nel figlio.
338 La scelta di questi valori di ritorno non è casuale, un processo infatti può
339 avere più figli, ed il valore di ritorno di \func{fork} è l'unico che gli
340 permette di identificare qual è quello appena creato. Al contrario un figlio
341 ha sempre un solo padre il cui \ids{PID}, come spiegato in
342 sez.~\ref{sec:proc_pid}, può sempre essere ottenuto con \func{getppid}; per
343 questo si ritorna un valore nullo, che non è il \ids{PID} di nessun processo.
345 Normalmente la chiamata a \func{fork} può fallire solo per due ragioni: o ci
346 sono già troppi processi nel sistema, il che di solito è sintomo che
347 qualcos'altro non sta andando per il verso giusto, o si è ecceduto il limite
348 sul numero totale di processi permessi all'utente, argomento che tratteremo in
349 dettaglio in sez.~\ref{sec:sys_resource_limit}.
351 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
352 quella in cui all'interno di un programma si creano processi figli cui viene
353 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
354 ne esegue un'altra. È il caso tipico dei programmi server (il modello
355 \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}) in cui il
356 padre riceve ed accetta le richieste da parte dei programmi client, per
357 ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
358 le risposte associate al servizio.
360 La seconda modalità è quella in cui il processo vuole eseguire un altro
361 programma; questo è ad esempio il caso della shell. In questo caso il processo
362 crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
363 cui parleremo in sez.~\ref{sec:proc_exec}) subito dopo la \func{fork}.
365 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
366 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
367 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
368 scelto di mantenere questa separazione, dato che, come per la prima modalità
369 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
370 aver bisogno di eseguire una \func{exec}.
372 Inoltre, anche nel caso della seconda modalità d'uso, avere le due funzioni
373 separate permette al figlio di cambiare alcune caratteristiche del processo
374 (maschera dei segnali, redirezione dell'output, utente per conto del cui viene
375 eseguito, e molto altro su cui torneremo in seguito) prima della \func{exec},
376 rendendo così relativamente facile intervenire sulle le modalità di esecuzione
380 \footnotesize \centering
381 \begin{minipage}[c]{\codesamplewidth}
382 \includecodesample{listati/fork_test.c}
385 \caption{Esempio di codice per la creazione di nuovi processi (da
386 \file{fork\_test.c}).}
387 \label{fig:proc_fork_code}
390 In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
391 di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
392 dell'uso della funzione \func{fork}. Il programma crea un numero di figli
393 specificato da linea di comando, e prende anche alcune opzioni per indicare
394 degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
395 \func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
396 descrizione delle opzioni). Il codice completo, compresa la parte che gestisce
397 le opzioni a riga di comando, è disponibile nel file \file{fork\_test.c},
398 distribuito insieme agli altri sorgenti degli esempi della guida su
399 \url{http://gapil.gnulinux.it}.
401 Decifrato il numero di figli da creare, il ciclo principale del programma
402 (\texttt{\small 24-40}) esegue in successione la creazione dei processi figli
403 controllando il successo della chiamata a \func{fork} (\texttt{\small
404 25-29}); ciascun figlio (\texttt{\small 31-34}) si limita a stampare il
405 suo numero di successione, eventualmente attendere il numero di secondi
406 specificato e scrivere un messaggio prima di uscire. Il processo padre invece
407 (\texttt{\small 36-38}) stampa un messaggio di creazione, eventualmente
408 attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
409 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
412 Se eseguiamo il comando, che è preceduto dall'istruzione \code{export
413 LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche, senza
414 specificare attese (come si può notare in (\texttt{\small 17-19}) i valori
415 predefiniti specificano di non attendere), otterremo come risultato sul
418 [piccardi@selidor sources]$ \textbf{export LD_LIBRARY_PATH=./; ./forktest 3}
419 Process 1963: forking 3 child
420 Spawned 1 child, pid 1964
421 Child 1 successfully executing
422 Child 1, parent 1963, exiting
424 Spawned 2 child, pid 1965
425 Child 2 successfully executing
426 Child 2, parent 1963, exiting
428 Child 3 successfully executing
429 Child 3, parent 1963, exiting
430 Spawned 3 child, pid 1966
435 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
436 si può dire quale processo fra il padre ed il figlio venga eseguito per primo
437 dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei
438 primi due cicli sia stato eseguito per primo il padre (con la stampa del
439 \ids{PID} del nuovo processo) per poi passare all'esecuzione del figlio
440 (completata con i due avvisi di esecuzione ed uscita), e tornare
441 all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
442 mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
445 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
446 \textit{scheduling} usato dal kernel, dalla particolare situazione in cui si
447 trova la macchina al momento della chiamata, risultando del tutto
448 impredicibile. Eseguendo più volte il programma di prova e producendo un
449 numero diverso di figli, si sono ottenute situazioni completamente diverse,
450 compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
451 prima che uno dei figli venisse messo in esecuzione.
453 Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
454 istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
455 essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
456 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
457 rischio di incorrere nelle cosiddette \textit{race condition} (vedi
458 sez.~\ref{sec:proc_race_cond}).
460 In realtà con l'introduzione dei kernel della serie 2.6 lo \textit{scheduler}
461 è stato modificato per eseguire sempre per primo il figlio.\footnote{i
462 risultati precedenti infatti sono stati ottenuti usando un kernel della
463 serie 2.4.} Questa è una ottimizzazione adottata per evitare che il padre,
464 effettuando per primo una operazione di scrittura in memoria, attivasse il
465 meccanismo del \textit{copy on write}, operazione inutile quando il figlio
466 viene creato solo per eseguire una \func{exec} per lanciare un altro programma
467 che scarta completamente lo spazio degli indirizzi e rende superflua la copia
468 della memoria modificata dal padre. Eseguendo sempre per primo il figlio la
469 \func{exec} verrebbe effettuata subito, con la certezza di utilizzare il
470 \textit{copy on write} solo quando necessario.
472 Con il kernel 2.6.32 però il comportamento è stato nuovamente cambiato,
473 stavolta facendo eseguire per primo sempre il padre. Si è realizzato infatti
474 che l'eventualità prospettata per la scelta precedente era comunque poco
475 probabile, mentre l'esecuzione immediata del padre presenta sempre il
476 vantaggio di poter utilizzare immediatamente tutti i dati che sono nella cache
477 della CPU e nell'unità di gestione della memoria virtuale, senza doverli
478 invalidare, cosa che per i processori moderni, che hanno linee di cache
479 interne molto profonde, avrebbe un forte impatto sulle prestazioni.
481 Allora anche se quanto detto in precedenza si verifica nel comportamento
482 effettivo dei programmi soltanto per i kernel fino alla serie 2.4, per
483 mantenere la portabilità con altri kernel unix-like e con i diversi
484 comportamenti adottati dalle Linux nella sua evoluzione, è comunque opportuno
485 non fare nessuna assunzione sull'ordine di esecuzione di padre e figlio dopo
486 la chiamata a \func{fork}.
488 Si noti infine come dopo la \func{fork}, essendo i segmenti di memoria
489 utilizzati dai singoli processi completamente indipendenti, le modifiche delle
490 variabili nei processi figli, come l'incremento di \var{i} in (\texttt{\small
491 31}), sono visibili solo a loro, (ogni processo vede solo la propria copia
492 della memoria), e non hanno alcun effetto sul valore che le stesse variabili
493 hanno nel processo padre ed in eventuali altri processi figli che eseguano lo
496 Un secondo aspetto molto importante nella creazione dei processi figli è
497 quello dell'interazione dei vari processi con i file. Ne parleremo qui anche
498 se buona parte dei concetti relativi ai file verranno trattati più avanti
499 (principalmente in sez.~\ref{sec:file_unix_interface}). Per illustrare meglio
500 quello che avviene si può redirigere su un file l'output del programma di
501 test, quello che otterremo è:
503 [piccardi@selidor sources]$ \textbf{./forktest 3 > output}
504 [piccardi@selidor sources]$ \textbf{cat output}
505 Process 1967: forking 3 child
506 Child 1 successfully executing
507 Child 1, parent 1967, exiting
508 Test for forking 3 child
509 Spawned 1 child, pid 1968
511 Child 2 successfully executing
512 Child 2, parent 1967, exiting
513 Test for forking 3 child
514 Spawned 1 child, pid 1968
516 Spawned 2 child, pid 1969
518 Child 3 successfully executing
519 Child 3, parent 1967, exiting
520 Test for forking 3 child
521 Spawned 1 child, pid 1968
523 Spawned 2 child, pid 1969
525 Spawned 3 child, pid 1970
528 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
530 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
531 in gran dettaglio in sez.~\ref{sec:file_unix_interface} per l'interfaccia
532 nativa Unix ed in sez.~\ref{sec:files_std_interface} per la standardizzazione
533 adottata nelle librerie del linguaggio C, valida per qualunque sistema
536 Qui basta accennare che si sono usate le funzioni standard della libreria del
537 C che prevedono l'output bufferizzato. Il punto è che questa bufferizzazione
538 (che tratteremo in dettaglio in sez.~\ref{sec:file_buffering}) varia a seconda
539 che si tratti di un file su disco, in cui il buffer viene scaricato su disco
540 solo quando necessario, o di un terminale, in cui il buffer viene scaricato ad
541 ogni carattere di ``a capo''.
543 Nel primo esempio allora avevamo che, essendovi un a capo nella stringa
544 stampata, ad ogni chiamata a \func{printf} il buffer veniva scaricato, per cui
545 le singole righe comparivano a video subito dopo l'esecuzione della
546 \func{printf}. Ma con la redirezione su file la scrittura non avviene più alla
547 fine di ogni riga e l'output resta nel buffer.
549 Dato che ogni figlio riceve una copia della memoria del padre, esso riceverà
550 anche quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte
551 dal padre fino allora. Così quando il buffer viene scritto su disco all'uscita
552 del figlio, troveremo nel file anche tutto quello che il processo padre aveva
553 scritto prima della sua creazione. E alla fine del file (dato che in questo
554 caso il padre esce per ultimo) troveremo anche l'output completo del padre.
556 L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
557 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
558 solo processi diversi possono scrivere in contemporanea sullo stesso file
559 (l'argomento dell'accesso concorrente ai file è trattato in dettaglio in
560 sez.~\ref{sec:file_shared_access}), ma anche che, a differenza di quanto
561 avviene per le variabili in memoria, la posizione corrente sul file è
562 condivisa fra il padre e tutti i processi figli.
564 Quello che succede è che quando lo \textit{standard output}\footnote{si chiama
565 così il file su cui di default un programma scrive i suoi dati in uscita,
566 tratteremo l'argomento in dettaglio in sez.~\ref{sec:file_fd}.} del padre
567 viene rediretto come si è fatto nell'esempio, lo stesso avviene anche per
568 tutti i figli. La funzione \func{fork} infatti ha la caratteristica di
569 duplicare nei processi figli tutti i \textit{file descriptor} (vedi
570 sez.~\ref{sec:file_fd}) dei file aperti nel processo padre (allo stesso modo
571 in cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}). Ciò
572 fa sì che padre e figli condividano le stesse voci della \textit{file table}
573 (tratteremo in dettaglio questi termini in sez.~\ref{sec:file_fd} e
574 sez.~\ref{sec:file_shared_access}) fra le quali c'è anche la posizione
577 Quando un processo scrive su un file la posizione corrente viene aggiornata
578 sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
579 \textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
580 casi come quello appena mostrato in cui diversi figli scrivono sullo stesso
581 file usato dal padre, che una scrittura eseguita in un secondo tempo da un
582 processo vada a sovrapporsi a quelle precedenti: l'output potrà risultare
583 mescolato, ma non ci saranno parti perdute per via di una sovrascrittura.
585 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
586 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
587 scrivono sullo stesso file. Un caso tipico di questo comportamento è la shell
588 quando lancia un programma. In questo modo, anche se lo standard output viene
589 rediretto, il padre potrà sempre continuare a scrivere in coda a quanto
590 scritto dal figlio in maniera automatica; se così non fosse ottenere questo
591 comportamento sarebbe estremamente complesso, necessitando di una qualche
592 forma di comunicazione fra i due processi per far riprendere al padre la
593 scrittura al punto giusto.
595 In generale comunque non è buona norma far scrivere più processi sullo stesso
596 file senza una qualche forma di sincronizzazione in quanto, come visto anche
597 con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
598 una sequenza impredicibile. Per questo le modalità con cui in genere si usano
599 i file dopo una \func{fork} sono sostanzialmente due:
601 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
602 è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
603 della posizione corrente dopo eventuali operazioni di lettura e scrittura
604 effettuate dal figlio è automatica.
605 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
606 ciascuno dei due processi deve chiudere i file che non gli servono una volta
607 che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
610 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
611 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
612 comune dopo l'esecuzione di una \func{fork} è la seguente:
614 \item i file aperti e gli eventuali flag di \textit{close-on-exec} impostati
615 (vedi sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_shared_access});
616 \item gli identificatori per il controllo di accesso: l'\textsl{user-ID
617 reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
618 \textsl{group-ID effettivo} ed i \textsl{group-ID supplementari} (vedi
619 sez.~\ref{sec:proc_access_id});
620 \item gli identificatori per il controllo di sessione: il \textit{process
621 group-ID} e il \textit{session id} ed il terminale di controllo (vedi
622 sez.~\ref{sec:sess_proc_group});
623 \item la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la
624 directory radice (vedi sez.~\ref{sec:file_chroot});
625 \item la maschera dei permessi di creazione dei file (vedi
626 sez.~\ref{sec:file_perm_management});
627 \item la maschera dei segnali bloccati (vedi
628 sez.~\ref{sec:sig_sigmask}) e le azioni installate (vedi
629 sez.~\ref{sec:sig_gen_beha});
630 \item i segmenti di memoria condivisa agganciati al processo (vedi
631 sez.~\ref{sec:ipc_sysv_shm});
632 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
633 \item il valori di \textit{nice}, le priorità \textit{real-time} e le affinità
634 di processore (vedi sez.~\ref{sec:proc_sched_stand},
635 sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
636 \item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
637 \item l'insieme dei descrittori associati alle code di messaggi POSIX (vedi
638 sez.~\ref{sec:ipc_posix_mq}) che vengono copiate come i \textit{file
639 descriptor}, questo significa che entrambi condivideranno gli stessi flag.
642 Oltre a quelle relative ad un diverso spazio degli indirizzi (e una memoria
643 totalmente indipendente) le differenze fra padre e figlio dopo l'esecuzione di
644 una \func{fork} invece sono:\footnote{a parte le ultime quattro, relative a
645 funzionalità specifiche di Linux, le altre sono esplicitamente menzionate
646 dallo standard POSIX.1-2001.}
648 \item il valore di ritorno di \func{fork};
649 \item il \ids{PID} (\textit{process id}), quello del figlio viene assegnato ad
650 un nuovo valore univoco;
651 \item il \ids{PPID} (\textit{parent process id}), quello del figlio viene
652 impostato al \ids{PID} del padre;
653 \item i valori dei tempi di esecuzione (vedi sez.~\ref{sec:sys_cpu_times}) e
654 delle risorse usate (vedi sez.~\ref{sec:sys_resource_use}), che nel figlio
656 \item i \textit{lock} sui file (vedi sez.~\ref{sec:file_locking}) e sulla
657 memoria (vedi sez.~\ref{sec:proc_mem_lock}), che non vengono ereditati dal
659 \item gli allarmi, i timer (vedi sez.~\ref{sec:sig_alarm_abort}) ed i segnali
660 pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che per il figlio vengono
662 \item le operazioni di I/O asincrono in corso (vedi
663 sez.~\ref{sec:file_asyncronous_io}) che non vengono ereditate dal figlio;
664 \item gli aggiustamenti fatti dal padre ai semafori con \func{semop} (vedi
665 sez.~\ref{sec:ipc_sysv_sem}).
666 \item le notifiche sui cambiamenti delle directory con \textit{dnotify} (vedi
667 sez.~\ref{sec:sig_notification}), che non vengono ereditate dal figlio;
668 \item le mappature di memoria marcate come \const{MADV\_DONTFORK} (vedi
669 sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;
670 \item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:process_prctl}) che
671 notifica al figlio la terminazione del padre viene cancellata se presente
673 \item il segnale di terminazione del figlio è sempre \signal{SIGCHLD} anche
674 qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}).
677 Una seconda funzione storica usata per la creazione di un nuovo processo è
678 \funcm{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
679 semantica e gli stessi errori; la sola differenza è che non viene creata la
680 tabella delle pagine né la struttura dei task per il nuovo processo. Il
681 processo padre è posto in attesa fintanto che il figlio non ha eseguito una
682 \func{execve} o non è uscito con una \func{\_exit}. Il figlio condivide la
683 memoria del padre (e modifiche possono avere effetti imprevedibili) e non deve
684 ritornare o uscire con \func{exit} ma usare esplicitamente \func{\_exit}.
686 Questa funzione è un rimasuglio dei vecchi tempi in cui eseguire una
687 \func{fork} comportava anche la copia completa del segmento dati del processo
688 padre, che costituiva un inutile appesantimento in tutti quei casi in cui la
689 \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
690 venne introdotta in BSD per migliorare le prestazioni.
692 Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è
693 assolutamente trascurabile, e l'uso di questa funzione, che resta un caso
694 speciale della \textit{system call} \func{clone} (che tratteremo in dettaglio
695 in sez.~\ref{sec:process_clone}) è deprecato; per questo eviteremo di
696 trattarla ulteriormente.
699 \subsection{La conclusione di un processo}
700 \label{sec:proc_termination}
702 In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
703 chiudere un programma, ma dall'interno del programma stesso. Avendo a che fare
704 con un sistema \textit{multitasking} resta da affrontare l'argomento dal punto
705 di vista di come il sistema gestisce la conclusione dei processi.
707 Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
708 programma viene terminato in maniera normale: la chiamata di \func{exit}, che
709 esegue le funzioni registrate per l'uscita e chiude gli \textit{stream} e poi
710 esegue \func{\_exit}, il ritorno dalla funzione \code{main} equivalente alla
711 chiamata di \func{exit}, e la chiamata diretta a \func{\_exit}, che passa
712 direttamente alle operazioni di terminazione del processo da parte del kernel.
714 Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
715 modalità di conclusione anomala. Queste sono in sostanza due: il programma può
716 chiamare la funzione \func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}) per
717 invocare una chiusura anomala, o essere terminato da un segnale (torneremo sui
718 segnali in cap.~\ref{cha:signals}). In realtà anche la prima modalità si
719 riconduce alla seconda, dato che \func{abort} si limita a generare il segnale
722 Qualunque sia la modalità di conclusione di un processo, il kernel esegue
723 comunque una serie di operazioni di terminazione: chiude tutti i file aperti,
724 rilascia la memoria che stava usando, e così via; l'elenco completo delle
725 operazioni eseguite alla chiusura di un processo è il seguente:
727 \item tutti i \textit{file descriptor} (vedi sez.~\ref{sec:file_fd}) sono
729 \item viene memorizzato lo stato di terminazione del processo;
730 \item ad ogni processo figlio viene assegnato un nuovo padre (in genere
732 \item viene inviato il segnale \signal{SIGCHLD} al processo padre (vedi
733 sez.~\ref{sec:sig_sigchld});
734 \item se il processo è un leader di sessione ed il suo terminale di controllo
735 è quello della sessione viene mandato un segnale di \signal{SIGHUP} a tutti i
736 processi del gruppo di \textit{foreground} e il terminale di controllo viene
737 disconnesso (vedi sez.~\ref{sec:sess_ctrl_term});
738 \item se la conclusione di un processo rende orfano un \textit{process
739 group} ciascun membro del gruppo viene bloccato, e poi gli vengono
740 inviati in successione i segnali \signal{SIGHUP} e \signal{SIGCONT}
741 (vedi ancora sez.~\ref{sec:sess_ctrl_term}).
744 \itindbeg{termination~status}
746 Oltre queste operazioni è però necessario poter disporre di un meccanismo
747 ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
748 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
749 scelto consiste nel riportare lo \textsl{stato di terminazione} (il cosiddetto
750 \textit{termination status}) al processo padre.
752 Nel caso di conclusione normale, abbiamo visto in
753 sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
754 caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
755 valore passato come argomento alle funzioni \func{exit} o \func{\_exit} o il
756 valore di ritorno per \code{main}. Ma se il processo viene concluso in
757 maniera anomala il programma non può specificare nessun \textit{exit status},
758 ed è il kernel che deve generare autonomamente il \textit{termination status}
759 per indicare le ragioni della conclusione anomala.
761 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
762 quello che contraddistingue lo stato di chiusura del processo e viene
763 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
764 sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione
765 normale il kernel usa il primo (nel codice eseguito da \func{\_exit}) per
768 La scelta di riportare al padre lo stato di terminazione dei figli, pur
769 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
770 alla sua creazione è scontato che ogni nuovo processo abbia un padre, non è
771 detto che sia così alla sua conclusione, dato che il padre potrebbe essere già
772 terminato; si potrebbe avere cioè quello che si chiama un processo
775 Questa complicazione viene superata facendo in modo che il processo orfano
776 venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \ids{PID}
777 1,\footnote{anche se, come vedremo in sez.~\ref{sec:process_prctl}, a partire
778 dal kernel 3.4 è diventato possibile delegare questo compito anche ad un
779 altro processo.} cioè quello lanciato direttamente dal kernel all'avvio, che
780 sta alla base dell'albero dei processi visto in sez.~\ref{sec:proc_hierarchy}
781 e che anche per questo motivo ha un ruolo essenziale nel sistema e non può mai
782 terminare.\footnote{almeno non senza un blocco completo del sistema, in caso
783 di terminazione o di non esecuzione di \cmd{init} infatti il kernel si
784 blocca con un cosiddetto \textit{kernel panic}, dato che questo è un errore
787 Come già accennato quando un processo termina, il kernel controlla se è il
788 padre di altri processi in esecuzione: in caso positivo allora il \ids{PPID}
789 di tutti questi processi verrà sostituito dal kernel con il \ids{PID} di
790 \cmd{init}, cioè con 1. In questo modo ogni processo avrà sempre un padre (nel
791 caso possiamo parlare di un padre \textsl{adottivo}) cui riportare il suo
792 stato di terminazione.
794 Come verifica di questo comportamento possiamo eseguire il nostro programma
795 \cmd{forktest} imponendo a ciascun processo figlio due secondi di attesa prima
796 di uscire, il risultato è:
798 [piccardi@selidor sources]$ \textbf{./forktest -c2 3}
799 Process 1972: forking 3 child
800 Spawned 1 child, pid 1973
801 Child 1 successfully executing
803 Spawned 2 child, pid 1974
804 Child 2 successfully executing
806 Child 3 successfully executing
807 Spawned 3 child, pid 1975
810 [piccardi@selidor sources]$ Child 3, parent 1, exiting
811 Child 2, parent 1, exiting
812 Child 1, parent 1, exiting
814 come si può notare in questo caso il processo padre si conclude prima dei
815 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
816 secondi dopo viene stampato a video anche l'output dei tre figli che
817 terminano, e come si può notare in questo caso, al contrario di quanto visto
818 in precedenza, essi riportano 1 come \ids{PPID}.
820 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
821 perché non è detto che il padre sia in esecuzione e possa ricevere
822 immediatamente lo stato di terminazione, quindi il kernel deve comunque
823 conservare una certa quantità di informazioni riguardo ai processi che sta
826 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
827 memorizzando alcuni dati essenziali, come il \ids{PID}, i tempi di CPU usati
828 dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
829 mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente.
833 I processi che sono terminati, ma il cui stato di terminazione non è stato
834 ancora ricevuto dal padre sono chiamati \textit{zombie}, essi restano presenti
835 nella tabella dei processi ed in genere possono essere identificati
836 dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella colonna che ne
837 indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando il padre
838 effettuerà la lettura dello stato di terminazione anche questa informazione,
839 non più necessaria, verrà scartata ed il processo potrà considerarsi
840 completamente concluso.
842 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
843 condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi
844 sez.~\ref{sec:sess_job_control}), indicando al processo padre di aspettare 10
845 secondi prima di uscire. In questo caso, usando \cmd{ps} sullo stesso
846 terminale (prima dello scadere dei 10 secondi) otterremo:
848 [piccardi@selidor sources]$ \textbf{ps T}
849 PID TTY STAT TIME COMMAND
850 419 pts/0 S 0:00 bash
851 568 pts/0 S 0:00 ./forktest -e10 3
852 569 pts/0 Z 0:00 [forktest <defunct>]
853 570 pts/0 Z 0:00 [forktest <defunct>]
854 571 pts/0 Z 0:00 [forktest <defunct>]
855 572 pts/0 R 0:00 ps T
858 e come si vede, dato che non si è fatto nulla per riceverne lo stato di
859 terminazione, i tre processi figli sono ancora presenti pur essendosi
860 conclusi, con lo stato di \textit{zombie} e l'indicazione che sono terminati
861 (la scritta \texttt{defunct}).
863 La possibilità di avere degli \textit{zombie} deve essere tenuta sempre
864 presente quando si scrive un programma che deve essere mantenuto in esecuzione
865 a lungo e creare molti processi figli. In questo caso si deve sempre avere
866 cura di far leggere al programma l'eventuale stato di uscita di tutti i
867 figli. Una modalità comune di farlo è attraverso l'utilizzo di un apposito
868 \textit{signal handler} che chiami la funzione \func{wait}, (vedi
869 sez.~\ref{sec:proc_wait}), ne esamineremo in dettaglio un esempio
870 (fig.~\ref{fig:sig_sigchld_handl}) in sez.~\ref{sec:sig_sigchld}.
872 La lettura degli stati di uscita è necessaria perché anche se gli
873 \textit{zombie} non consumano risorse di memoria o processore, occupano
874 comunque una voce nella tabella dei processi e se li si lasciano accumulare a
875 lungo quest'ultima potrebbe esaurirsi, con la conseguente impossibilità di
876 lanciare nuovi processi.
878 Si noti tuttavia che quando un processo adottato da \cmd{init} termina, non
879 diviene mai uno \textit{zombie}. Questo perché una delle funzioni di
880 \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i processi
881 a cui fa da padre, completandone la terminazione. Questo è quanto avviene
882 anche quando, come nel caso del precedente esempio con \cmd{forktest}, il
883 padre termina con dei figli in stato di \textit{zombie}. Questi scompaiono
884 quando, alla terminazione del padre dopo i secondi programmati, tutti figli
885 che avevamo generato, e che erano diventati \textit{zombie}, vengono adottati
886 da \cmd{init}, il quale provvede a completarne la terminazione.
888 Si tenga presente infine che siccome gli \textit{zombie} sono processi già
889 terminati, non c'è modo di eliminarli con il comando \cmd{kill} o inviandogli
890 un qualunque segnale di terminazione (l'argomento è trattato in
891 sez.~\ref{sec:sig_termination}). Qualora ci si trovi in questa situazione
892 l'unica possibilità di cancellarli dalla tabella dei processi è quella di
893 terminare il processo che li ha generati e che non sta facendo il suo lavoro,
894 in modo che \cmd{init} possa adottarli e concluderne correttamente la
897 Si tenga anche presente che la presenza di \textit{zombie} nella tabella dei
898 processi non è sempre indice di un qualche malfunzionamento, in una macchina
899 con molto carico infatti può esservi una presenza temporanea dovuta al fatto
900 che il processo padre ancora non ha avuto il tempo di gestirli.
905 \subsection{Le funzioni di attesa e ricezione degli stati di uscita}
906 \label{sec:proc_wait}
908 Uno degli usi più comuni delle capacità \textit{multitasking} di un sistema
909 unix-like consiste nella creazione di programmi di tipo server, in cui un
910 processo principale attende le richieste che vengono poi soddisfatte da una
911 serie di processi figli.
913 Si è già sottolineato al paragrafo precedente come in questo caso diventi
914 necessario gestire esplicitamente la conclusione dei figli onde evitare di
915 riempire di \textit{zombie} la tabella dei processi. Tratteremo in questa
916 sezione le funzioni di sistema deputate a questo compito; la prima è
917 \funcd{wait} ed il suo prototipo è:
922 \fdecl{pid\_t wait(int *status)}
923 \fdesc{Attende la terminazione di un processo.}
925 {La funzione ritorna il \ids{PID} del figlio in caso di successo e $-1$ per un
926 errore, nel qual caso \var{errno} assumerà uno dei valori:
928 \item[\errcode{ECHILD}] il processo non ha nessun figlio di cui attendere
929 uno stato di terminazione.
930 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
934 Questa funzione è presente fin dalle prime versioni di Unix ed è quella usata
935 tradizionalmente per attendere la terminazione dei figli. La funzione sospende
936 l'esecuzione del processo corrente e ritorna non appena un qualunque processo
937 figlio termina. Se un figlio è già terminato prima della sua chiamata la
938 funzione ritorna immediatamente, se più processi figli sono già terminati
939 occorrerà continuare a chiamare la funzione più volte fintanto che non si è
940 recuperato lo stato di terminazione di tutti quanti.
942 Al ritorno della funzione lo stato di terminazione del figlio viene salvato
943 (come \textit{value result argument}) nella variabile puntata
944 da \param{status} e tutte le risorse del kernel relative al processo (vedi
945 sez.~\ref{sec:proc_termination}) vengono rilasciate. Nel caso un processo
946 abbia più figli il valore di ritorno della funzione sarà impostato al
947 \ids{PID} del processo di cui si è ricevuto lo stato di terminazione, cosa che
948 permette di identificare qual è il figlio che è terminato.
950 \itindend{termination~status}
952 Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
953 all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
954 necessario attendere la conclusione di uno specifico processo fra tutti quelli
955 esistenti occorre predisporre un meccanismo che tenga conto di tutti processi
956 che sono terminati, e provveda a ripetere la chiamata alla funzione nel caso
957 il processo cercato non risulti fra questi. Se infatti il processo cercato è
958 già terminato e se è già ricevuto lo stato di uscita senza registrarlo, la
959 funzione non ha modo di accorgersene, e si continuerà a chiamarla senza
960 accorgersi che quanto interessava è già accaduto.
962 Per questo motivo lo standard POSIX.1 ha introdotto una seconda funzione che
963 effettua lo stesso servizio, ma dispone di una serie di funzionalità più
964 ampie, legate anche al controllo di sessione (si veda
965 sez.~\ref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
966 comportamento di \func{wait}\footnote{in effetti il codice
967 \code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
968 \&status, 0)}.} si consiglia di utilizzare sempre questa nuova funzione di
969 sistema, \funcd{waitpid}, il cui prototipo è:
974 \fdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
975 \fdesc{Attende il cambiamento di stato di un processo figlio.}
977 {La funzione ritorna il \ids{PID} del processo che ha cambiato stato in caso
978 di successo, o 0 se è stata specificata l'opzione \const{WNOHANG} e il
979 processo non è uscito e $-1$ per un errore, nel qual caso \var{errno}
980 assumerà uno dei valori:
982 \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
983 non è figlio del processo chiamante.
984 \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
985 la funzione è stata interrotta da un segnale.
986 \item[\errcode{EINVAL}] si è specificato un valore non valido per
987 l'argomento \param{options}.
991 La prima differenza fra le due funzioni è che con \func{waitpid} si può
992 specificare in maniera flessibile quale processo attendere, sulla base del
993 valore fornito dall'argomento \param{pid}. Questo può assumere diversi valori,
994 secondo lo specchietto riportato in tab.~\ref{tab:proc_waidpid_pid}, dove si
995 sono riportate anche le costanti definite per indicare alcuni di essi.
1000 \begin{tabular}[c]{|c|c|p{8cm}|}
1002 \textbf{Valore} & \textbf{Costante} &\textbf{Significato}\\
1005 $<-1$& -- & Attende per un figlio il cui \textit{process
1006 group} (vedi sez.~\ref{sec:sess_proc_group}) è
1007 uguale al valore assoluto di \param{pid}.\\
1008 $-1$&\constd{WAIT\_ANY} & Attende per un figlio qualsiasi, usata in
1009 questa maniera senza specificare nessuna opzione
1010 è equivalente a \func{wait}.\\
1011 $ 0$&\constd{WAIT\_MYPGRP}&Attende per un figlio il cui \textit{process
1012 group} (vedi sez.~\ref{sec:sess_proc_group}) è
1013 uguale a quello del processo chiamante.\\
1014 $>0$& -- & Attende per un figlio il cui \ids{PID} è uguale
1015 al valore di \param{pid}.\\
1018 \caption{Significato dei valori dell'argomento \param{pid} della funzione
1020 \label{tab:proc_waidpid_pid}
1023 Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
1024 funzione delle opportune opzioni tramite l'argomento \param{options}; questo
1025 deve essere specificato come maschera binaria delle costanti riportati nella
1026 prima parte in tab.~\ref{tab:proc_waitpid_options} che possono essere
1027 combinate fra loro con un OR aritmetico. Nella seconda parte della stessa
1028 tabella si sono riportati anche alcune opzioni non standard specifiche di
1029 Linux, che consentono un controllo più dettagliato per i processi creati con
1030 la \textit{system call} generica \func{clone} (vedi
1031 sez.~\ref{sec:process_clone}) e che vengono usati principalmente per la
1032 gestione della terminazione dei \textit{thread}\unavref{ (vedi
1033 sez.~\ref{sec:thread_xxx})}.
1038 \begin{tabular}[c]{|l|p{8cm}|}
1040 \textbf{Costante} & \textbf{Descrizione}\\
1043 \const{WNOHANG} & La funzione ritorna immediatamente anche se non è
1044 terminato nessun processo figlio.\\
1045 \const{WUNTRACED} & Ritorna anche quando un processo figlio è stato
1047 \const{WCONTINUED}& Ritorna anche quando un processo figlio che era stato
1048 fermato ha ripreso l'esecuzione (dal kernel 2.6.10).\\
1050 \constd{\_\_WCLONE}& Attende solo per i figli creati con \func{clone}
1051 (vedi sez.~\ref{sec:process_clone}), vale a dire
1052 processi che non emettono nessun segnale
1053 o emettono un segnale diverso da \signal{SIGCHLD} alla
1054 terminazione, il default è attendere soltanto i
1055 processi figli ordinari ignorando quelli creati da
1057 \constd{\_\_WALL} & Attende per qualunque figlio, sia ordinario che creato
1058 con \func{clone}, se specificata con
1059 \const{\_\_WCLONE} quest'ultima viene ignorata. \\
1060 \constd{\_\_WNOTHREAD}& Non attende per i figli di altri \textit{thread}
1061 dello stesso \textit{thread group}, questo era il
1062 comportamento di default del kernel 2.4 che non
1063 supportava la possibilità, divenuta il default a
1064 partire dal 2.6, di attendere un qualunque figlio
1065 appartenente allo stesso \textit{thread group}. \\
1068 \caption{Costanti che identificano i bit dell'argomento \param{options}
1069 della funzione \func{waitpid}.}
1070 \label{tab:proc_waitpid_options}
1075 L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della
1076 funzione qualora nessun figlio sia uscito o non si siano verificate le altre
1077 condizioni per l'uscita della funzione. in tal caso. In tal caso la funzione,
1078 invece di restituire il \ids{PID} del processo (che è sempre un intero
1079 positivo) ritornerà un valore nullo.
1082 \constbeg{WUNTRACED}
1083 \constbeg{WCONTINUED}
1085 Le altre due opzioni, \const{WUNTRACED} e \const{WCONTINUED}, consentono
1086 rispettivamente di tracciare non la terminazione di un processo, ma il fatto
1087 che esso sia stato fermato, o fatto ripartire, e sono utilizzate per la
1088 gestione del controllo di sessione (vedi sez.~\ref{sec:sess_job_control}).
1090 Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \ids{PID},
1091 quando un processo figlio entra nello stato \textit{stopped}\footnote{in
1092 realtà viene notificato soltanto il caso in cui il processo è stato fermato
1093 da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in
1094 cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace}\unavref{
1095 (vedi sez.~\ref{sec:process_ptrace})}.} (vedi
1096 tab.~\ref{tab:proc_proc_states}), mentre con \const{WCONTINUED} la funzione
1097 ritorna quando un processo in stato \textit{stopped} riprende l'esecuzione per
1098 la ricezione del segnale \signal{SIGCONT} (l'uso di questi segnali per il
1099 controllo di sessione è trattato in sez.~\ref{sec:sess_ctrl_term}).
1101 \constend{WUNTRACED}
1102 \constend{WCONTINUED}
1104 La terminazione di un processo figlio (così come gli altri eventi osservabili
1105 con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
1106 di un programma e può avvenire in un qualunque momento. Per questo motivo,
1107 come accennato nella sezione precedente, una delle azioni prese dal kernel
1108 alla conclusione di un processo è quella di mandare un segnale di
1109 \signal{SIGCHLD} al padre. L'azione predefinita per questo segnale (si veda
1110 sez.~\ref{sec:sig_base}) è di essere ignorato, ma la sua generazione
1111 costituisce il meccanismo di comunicazione asincrona con cui il kernel avverte
1112 il processo padre che uno dei suoi figli è terminato.
1114 Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4
1115 al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello
1116 standard POSIX.1-2001 e come da esso richiesto se \signal{SIGCHLD} viene
1117 ignorato, o se si imposta il flag di \const{SA\_NOCLDSTOP} nella ricezione
1118 dello stesso (si veda sez.~\ref{sec:sig_sigaction}) i processi figli che
1119 terminano non diventano \textit{zombie} e sia \func{wait} che \func{waitpid}
1120 si bloccano fintanto che tutti i processi figli non sono terminati, dopo di
1121 che falliscono con un errore di \errcode{ENOCHLD}.\footnote{questo è anche il
1122 motivo per cui le opzioni \const{WUNTRACED} e \const{WCONTINUED} sono
1123 utilizzabili soltanto qualora non si sia impostato il flag di
1124 \const{SA\_NOCLDSTOP} per il segnale \signal{SIGCHLD}.}
1126 Con i kernel della serie 2.4 e tutti i kernel delle serie precedenti entrambe
1127 le funzioni di attesa ignorano questa prescrizione e si comportano sempre
1128 nello stesso modo,\footnote{lo standard POSIX.1 originale infatti lascia
1129 indefinito il comportamento di queste funzioni quando \signal{SIGCHLD} viene
1130 ignorato.} indipendentemente dal fatto \signal{SIGCHLD} sia ignorato o meno:
1131 attendono la terminazione di un processo figlio e ritornano il relativo
1132 \ids{PID} e lo stato di terminazione nell'argomento \param{status}.
1134 In generale in un programma non si vuole essere forzati ad attendere la
1135 conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
1136 questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente
1137 la presenza di \textit{zombie}). Per questo la modalità più comune di
1138 chiamare queste funzioni è quella di utilizzarle all'interno di un
1139 \textit{signal handler} (vedremo un esempio di come gestire \signal{SIGCHLD}
1140 con i segnali in sez.~\ref{sec:sig_example}). In questo caso infatti, dato che
1141 il segnale è generato dalla terminazione di un figlio, avremo la certezza che
1142 la chiamata a \func{waitpid} non si bloccherà.
1144 Come accennato sia \func{wait} che \func{waitpid} restituiscono lo stato di
1145 terminazione del processo tramite il puntatore \param{status}, e se non
1146 interessa memorizzarlo si può passare un puntatore nullo. Il valore restituito
1147 da entrambe le funzioni dipende dall'implementazione, ma tradizionalmente gli
1148 8 bit meno significativi sono riservati per memorizzare lo stato di uscita del
1149 processo, e gli altri per indicare il segnale che ha causato la terminazione
1150 (in caso di conclusione anomala), uno per indicare se è stato generato un
1151 \textit{core dump} (vedi sez.~\ref{sec:sig_standard}), ecc.\footnote{le
1152 definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
1153 questo file non deve mai essere usato direttamente, esso viene incluso
1154 attraverso \file{<sys/wait.h>}.}
1159 \begin{tabular}[c]{|l|p{10cm}|}
1161 \textbf{Macro} & \textbf{Descrizione}\\
1164 \macrod{WIFEXITED}\texttt{(s)} & Condizione vera (valore non nullo) per
1165 un processo figlio che sia terminato
1167 \macrod{WEXITSTATUS}\texttt{(s)} & Restituisce gli otto bit meno
1168 significativi dello stato di uscita del
1169 processo (passato attraverso
1170 \func{\_exit}, \func{exit} o come valore
1171 di ritorno di \code{main}); può essere
1172 valutata solo se \val{WIFEXITED} ha
1173 restituito un valore non nullo.\\
1174 \macrod{WIFSIGNALED}\texttt{(s)} & Condizione vera se il processo figlio è
1175 terminato in maniera anomala a causa di
1176 un segnale che non è stato catturato
1177 (vedi sez.~\ref{sec:sig_notification}).\\
1178 \macrod{WTERMSIG}\texttt{(s)} & Restituisce il numero del segnale che ha
1179 causato la terminazione anomala del
1180 processo; può essere valutata solo se
1181 \val{WIFSIGNALED} ha restituito un
1183 \macrod{WCOREDUMP}\texttt{(s)} & Vera se il processo terminato ha
1185 \textit{core dump}; può essere valutata
1186 solo se \val{WIFSIGNALED} ha restituito
1187 un valore non nullo.\footnotemark \\
1188 \macrod{WIFSTOPPED}\texttt{(s)} & Vera se il processo che ha causato il
1189 ritorno di \func{waitpid} è bloccato;
1190 l'uso è possibile solo con
1191 \func{waitpid} avendo specificato
1192 l'opzione \const{WUNTRACED}.\\
1193 \macrod{WSTOPSIG}\texttt{(s)} & Restituisce il numero del segnale che ha
1194 bloccato il processo; può essere
1195 valutata solo se \val{WIFSTOPPED} ha
1196 restituito un valore non nullo. \\
1197 \macrod{WIFCONTINUED}\texttt{(s)}& Vera se il processo che ha causato il
1198 ritorno è stato riavviato da un
1199 \signal{SIGCONT} (disponibile solo a
1200 partire dal kernel 2.6.10).\\
1203 \caption{Descrizione delle varie macro di preprocessore utilizzabili per
1204 verificare lo stato di terminazione \var{s} di un processo.}
1205 \label{tab:proc_status_macro}
1208 \footnotetext{questa macro non è definita dallo standard POSIX.1-2001, ma è
1209 presente come estensione sia in Linux che in altri Unix, deve essere
1210 pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un
1211 blocco \texttt{\#ifdef WCOREDUMP ... \#endif}.}
1213 Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per
1214 analizzare lo stato di uscita. Esse sono definite sempre in
1215 \file{<sys/wait.h>} ed elencate in tab.~\ref{tab:proc_status_macro}. Si tenga
1216 presente che queste macro prevedono che gli si passi come parametro la
1217 variabile di tipo \ctyp{int} puntata dall'argomento \param{status} restituito
1218 da \func{wait} o \func{waitpid}.
1220 Si tenga conto che nel caso di conclusione anomala il valore restituito da
1221 \val{WTERMSIG} può essere confrontato con le costanti che identificano i
1222 segnali definite in \headfile{signal.h} ed elencate in
1223 tab.~\ref{tab:sig_signal_list}, e stampato usando le apposite funzioni
1224 trattate in sez.~\ref{sec:sig_strsignal}.
1226 A partire dal kernel 2.6.9, sempre in conformità allo standard POSIX.1-2001, è
1227 stata introdotta una nuova funzione di attesa che consente di avere un
1228 controllo molto più preciso sui possibili cambiamenti di stato dei processi
1229 figli e più dettagli sullo stato di uscita; la funzione di sistema è
1230 \funcd{waitid} ed il suo prototipo è:
1235 \fdecl{int waitid(idtype\_t idtype, id\_t id, siginfo\_t *infop, int options)}
1236 \fdesc{Attende il cambiamento di stato di un processo figlio.}
1238 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1239 caso \var{errno} assumerà uno dei valori:
1241 \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
1242 non è figlio del processo chiamante.
1243 \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
1244 la funzione è stata interrotta da un segnale.
1245 \item[\errcode{EINVAL}] si è specificato un valore non valido per
1246 l'argomento \param{options}.
1250 La funzione prevede che si specifichi quali processi si intendono osservare
1251 usando i due argomenti \param{idtype} ed \param{id}; il primo indica se ci si
1252 vuole porre in attesa su un singolo processo, un gruppo di processi o un
1253 processo qualsiasi, e deve essere specificato secondo uno dei valori di
1254 tab.~\ref{tab:proc_waitid_idtype}; il secondo indica, a seconda del valore del
1255 primo, quale processo o quale gruppo di processi selezionare.
1260 \begin{tabular}[c]{|l|p{8cm}|}
1262 \textbf{Valore} & \textbf{Descrizione}\\
1265 \constd{P\_PID} & Indica la richiesta di attendere per un processo figlio
1266 il cui \ids{PID} corrisponda al valore dell'argomento
1268 \constd{P\_PGID}& Indica la richiesta di attendere per un processo figlio
1269 appartenente al \textit{process group} (vedi
1270 sez.~\ref{sec:sess_proc_group}) il cui \acr{pgid}
1271 corrisponda al valore dell'argomento \param{id}.\\
1272 \constd{P\_ALL} & Indica la richiesta di attendere per un processo figlio
1273 generico, il valore dell'argomento \param{id} viene
1277 \caption{Costanti per i valori dell'argomento \param{idtype} della funzione
1279 \label{tab:proc_waitid_idtype}
1282 % TODO: documentare P_PIDFD per attendere un pidfd (per pidfd vedi
1283 % https://lwn.net/Articles/794707/) introdotta con il 5.4
1285 Come per \func{waitpid} anche il comportamento di \func{waitid} è
1286 controllato dall'argomento \param{options}, da specificare come maschera
1287 binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
1288 alcuni di questi siano identici come significato ed effetto ai precedenti di
1289 tab.~\ref{tab:proc_waitpid_options}, ci sono delle differenze significative:
1290 in questo caso si dovrà specificare esplicitamente l'attesa della terminazione
1291 di un processo impostando l'opzione \const{WEXITED}, mentre il precedente
1292 \const{WUNTRACED} è sostituito da \const{WSTOPPED}. Infine è stata aggiunta
1293 l'opzione \const{WNOWAIT} che consente una lettura dello stato mantenendo il
1294 processo in attesa di ricezione, così che una successiva chiamata possa di
1295 nuovo riceverne lo stato.
1300 \begin{tabular}[c]{|l|p{8cm}|}
1302 \textbf{Valore} & \textbf{Descrizione}\\
1305 \constd{WEXITED} & Ritorna quando un processo figlio è terminato.\\
1306 \constd{WNOHANG} & Ritorna immediatamente anche se non c'è niente da
1308 \constd{WSTOPPED} & Ritorna quando un processo figlio è stato fermato.\\
1309 \const{WCONTINUED} & Ritorna quando un processo figlio che era stato
1310 fermato ha ripreso l'esecuzione.\\
1311 \constd{WNOWAIT} & Lascia il processo ancora in attesa di ricezione, così
1312 che una successiva chiamata possa di nuovo riceverne
1316 \caption{Costanti che identificano i bit dell'argomento \param{options}
1317 della funzione \func{waitid}.}
1318 \label{tab:proc_waitid_options}
1321 La funzione \func{waitid} restituisce un valore nullo in caso di successo, e
1322 $-1$ in caso di errore; viene restituito un valore nullo anche se è stata
1323 specificata l'opzione \const{WNOHANG} e la funzione è ritornata immediatamente
1324 senza che nessun figlio sia terminato. Pertanto per verificare il motivo del
1325 ritorno della funzione occorre analizzare le informazioni che essa
1326 restituisce; queste, al contrario delle precedenti \func{wait} e
1327 \func{waitpid} che usavano un semplice valore numerico, sono ritornate in una
1328 struttura di tipo \struct{siginfo\_t} (vedi fig.~\ref{fig:sig_siginfo_t})
1329 all'indirizzo puntato dall'argomento \param{infop}.
1331 Tratteremo nei dettagli la struttura \struct{siginfo\_t} ed il significato dei
1332 suoi vari campi in sez.~\ref{sec:sig_sigaction}, per quanto ci interessa qui
1333 basta dire che al ritorno di \func{waitid} verranno avvalorati i seguenti
1335 \begin{basedescript}{\desclabelwidth{1.8cm}}
1336 \item[\var{si\_pid}] con il \ids{PID} del figlio.
1337 \item[\var{si\_uid}] con l'\textsl{user-ID reale} (vedi
1338 sez.~\ref{sec:proc_perms}) del figlio.
1339 \item[\var{si\_signo}] con \signal{SIGCHLD}.
1340 \item[\var{si\_status}] con lo stato di uscita del figlio o con il segnale che
1341 lo ha terminato, fermato o riavviato.
1342 \item[\var{si\_code}] con uno fra \const{CLD\_EXITED}, \const{CLD\_KILLED},
1343 \const{CLD\_STOPPED}, \const{CLD\_CONTINUED}, \const{CLD\_TRAPPED} e
1344 \const{CLD\_DUMPED} a indicare la ragione del ritorno della funzione, il cui
1345 significato è, nell'ordine: uscita normale, terminazione da segnale,
1346 processo fermato, processo riavviato, processo terminato in
1347 \textit{core dump} (vedi sez.~\ref{sec:sig_standard}).
1350 Infine Linux, seguendo un'estensione di BSD, supporta altre due funzioni per
1351 la lettura dello stato di terminazione di un processo, analoghe alle
1352 precedenti ma che prevedono un ulteriore argomento attraverso il quale il
1353 kernel può restituire al padre informazioni sulle risorse (vedi
1354 sez.~\ref{sec:sys_res_limits}) usate dal processo terminato e dai vari figli.
1355 Le due funzioni di sistema sono \funcd{wait3} e \funcd{wait4}, che diventano
1356 accessibili definendo la macro \macro{\_USE\_BSD}, i loro prototipi sono:
1361 \fhead{sys/resource.h}
1363 \fdecl{int wait3(int *status, int options, struct rusage *rusage)}
1364 \fdecl{int wait4(pid\_t pid, int *status, int options, struct rusage *rusage)}
1365 \fdesc{Attende il cambiamento di stato di un processo figlio, riportando l'uso
1368 {La funzione ha gli stessi valori di ritorno e codici di errore di
1372 La funzione \func{wait4} è identica \func{waitpid} sia nel comportamento che
1373 per i valori dei primi tre argomenti, ma in più restituisce nell'argomento
1374 aggiuntivo \param{rusage} un sommario delle risorse usate dal processo. Questo
1375 argomento è una struttura di tipo \struct{rusage} definita in
1376 \headfile{sys/resource.h}, che viene utilizzata anche dalla funzione
1377 \func{getrusage} per ottenere le risorse di sistema usate da un processo. La
1378 sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct} e ne
1379 tratteremo in dettaglio il significato sez.~\ref{sec:sys_resource_use}. La
1380 funzione \func{wait3} è semplicemente un caso particolare di (e con Linux
1381 viene realizzata con la stessa \textit{system call}), ed è equivalente a
1382 chiamare \code{wait4(-1, \&status, opt, rusage)}, per questo motivo è ormai
1383 deprecata in favore di \func{wait4}.
1387 \subsection{La famiglia delle funzioni \func{exec} per l'esecuzione dei
1389 \label{sec:proc_exec}
1391 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
1392 processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene
1393 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
1394 processo chiama una di queste funzioni esso viene completamente sostituito dal
1395 nuovo programma, il \ids{PID} del processo non cambia, dato che non viene
1396 creato un nuovo processo, la funzione semplicemente rimpiazza lo
1397 \textit{stack}, i dati ed il testo del processo corrente con un nuovo
1398 programma letto da disco, eseguendo il \textit{link-loader} con gli effetti
1399 illustrati in sez.~\ref{sec:proc_main}.
1401 \begin{figure}[!htb]
1402 \centering \includegraphics[width=8cm]{img/exec_rel}
1403 \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
1404 \label{fig:proc_exec_relat}
1407 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
1408 famiglia di funzioni) che possono essere usate per questo compito, in realtà
1409 (come mostrato in fig.~\ref{fig:proc_exec_relat}), tutte queste funzioni sono
1410 tutte varianti che consentono di invocare in modi diversi, semplificando il
1411 passaggio degli argomenti, la funzione di sistema \funcd{execve}, il cui
1416 \fdecl{int execve(const char *filename, char *const argv[], char *const envp[])}
1417 \fdesc{Esegue un programma.}
1419 {La funzione ritorna solo in caso di errore, restituendo $-1$, nel qual
1420 caso \var{errno} assumerà uno dei valori:
1422 \item[\errcode{EACCES}] il file o l'interprete non file ordinari, o non sono
1423 eseguibili, o il file è su un filesystem montato con l'opzione
1424 \cmd{noexec}, o manca il permesso di attraversamento di una delle
1425 directory del \textit{pathname}.
1426 \item[\errcode{EAGAIN}] dopo un cambio di \ids{UID} si è ancora sopra il
1427 numero massimo di processi consentiti per l'utente (dal kernel 3.1, per i
1428 dettagli vedi sez.~\ref{sec:proc_setuid}).
1429 \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
1430 \const{PT\_INTERP}, cioè chiede di essere eseguito da più di un
1432 \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
1434 \item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
1435 necessari per eseguirlo non esistono.
1436 \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
1437 riconosciuto come tale, o compilato per un'altra architettura.
1438 \item[\errcode{EPERM}] il file ha i bit \acr{suid} o \acr{sgid} e l'utente
1439 non è root, ed il processo viene tracciato, oppure il filesystem è montato
1440 con l'opzione \cmd{nosuid}.
1441 \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
1443 \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
1445 ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{EISDIR}, \errval{ELOOP},
1446 \errval{EMFILE}, \errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOMEM},
1447 \errval{ENOTDIR} nel loro significato generico. }
1450 La funzione \func{execve} esegue il programma o lo script indicato dal
1451 \textit{pathname} \param{filename}, passandogli la lista di argomenti indicata
1452 da \param{argv} e come ambiente la lista di stringhe indicata
1453 da \param{envp}. Entrambe le liste devono essere terminate da un puntatore
1454 nullo. I vettori degli argomenti e dell'ambiente possono essere acceduti dal
1455 nuovo programma quando la sua funzione \code{main} è dichiarata nella forma
1456 \code{main(int argc, char *argv[], char *envp[])}. Si tenga presente per il
1457 passaggio degli argomenti e dell'ambiente esistono comunque dei limiti, su cui
1458 torneremo in sez.~\ref{sec:sys_res_limits}).
1459 % TODO aggiungere la parte sul numero massimo di argomenti, da man execve
1461 In caso di successo la funzione non ritorna, in quanto al posto del programma
1462 chiamante viene eseguito il nuovo programma indicato da \param{filename}. Se
1463 il processo corrente è tracciato con \func{ptrace}\unavref{ (vedi
1464 sez.~\ref{sec:process_ptrace})} in caso di successo viene emesso il segnale
1467 Le altre funzioni della famiglia (\funcd{execl}, \funcd{execv},
1468 \funcd{execle}, \funcd{execlp}, \funcd{execvp}) servono per fornire all'utente
1469 una serie di possibili diverse interfacce nelle modalità di passaggio degli
1470 argomenti all'esecuzione del nuovo programma. I loro prototipi sono:
1474 \fdecl{int execl(const char *path, const char *arg, ...)}
1475 \fdecl{int execv(const char *path, char *const argv[])}
1476 \fdecl{int execle(const char *path, const char *arg, ..., char * const envp[])}
1477 \fdecl{int execlp(const char *file, const char *arg, ...)}
1478 \fdecl{int execvp(const char *file, char *const argv[])}
1479 \fdesc{Eseguono un programma.}
1481 {Le funzioni ritornano solo in caso di errore, restituendo $-1$, i codici di
1482 errore sono gli stessi di \func{execve}.
1486 Tutte le funzioni mettono in esecuzione nel processo corrente il programma
1487 indicati nel primo argomento. Gli argomenti successivi consentono di
1488 specificare gli argomenti e l'ambiente che saranno ricevuti dal nuovo
1489 processo. Per capire meglio le differenze fra le funzioni della famiglia si può
1490 fare riferimento allo specchietto riportato in
1491 tab.~\ref{tab:proc_exec_scheme}. La relazione fra le funzioni è invece
1492 illustrata in fig.~\ref{fig:proc_exec_relat}.
1497 \begin{tabular}[c]{|l|c|c|c||c|c|c|}
1499 \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
1500 \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
1502 &\func{execl}\texttt{ }&\func{execlp}&\func{execle}
1503 &\func{execv}\texttt{ }& \func{execvp}& \func{execve} \\
1506 argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
1507 argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
1509 filename completo &$\bullet$&&$\bullet$&$\bullet$&&$\bullet$\\
1510 ricerca su \var{PATH} &&$\bullet$&&&$\bullet$& \\
1512 ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
1513 uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
1516 \caption{Confronto delle caratteristiche delle varie funzioni della
1517 famiglia \func{exec}.}
1518 \label{tab:proc_exec_scheme}
1521 La prima differenza fra le funzioni riguarda le modalità di passaggio dei
1522 valori che poi andranno a costituire gli argomenti a linea di comando (cioè i
1523 valori di \param{argv} e \param{argc} visti dalla funzione \code{main} del
1524 programma chiamato). Queste modalità sono due e sono riassunte dagli mnemonici
1525 ``\texttt{v}'' e ``\texttt{l}'' che stanno rispettivamente per \textit{vector}
1528 Nel primo caso gli argomenti sono passati tramite il vettore di puntatori
1529 \var{argv[]} a stringhe terminate con zero che costituiranno gli argomenti a
1530 riga di comando, questo vettore \emph{deve} essere terminato da un puntatore
1531 nullo. Nel secondo caso le stringhe degli argomenti sono passate alla funzione
1532 come lista di puntatori, nella forma:
1533 \includecodesnip{listati/char_list.c}
1534 che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
1535 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
1536 per indicare il nome del file che contiene il programma che verrà eseguito.
1538 La seconda differenza fra le funzioni riguarda le modalità con cui si
1539 specifica il programma che si vuole eseguire. Con lo mnemonico ``\texttt{p}''
1540 si indicano le due funzioni che replicano il comportamento della shell nello
1541 specificare il comando da eseguire; quando l'argomento \param{file} non
1542 contiene una ``\texttt{/}'' esso viene considerato come un nome di programma,
1543 e viene eseguita automaticamente una ricerca fra i file presenti nella lista
1544 di directory specificate dalla variabile di ambiente \envvar{PATH}. Il file
1545 che viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
1546 relativo a permessi di accesso insufficienti (cioè l'esecuzione della
1547 sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
1548 proseguita nelle eventuali ulteriori directory indicate in \envvar{PATH}; solo
1549 se non viene trovato nessun altro file viene finalmente restituito
1550 \errcode{EACCES}. Le altre quattro funzioni si limitano invece a cercare di
1551 eseguire il file indicato dall'argomento \param{path}, che viene interpretato
1552 come il \textit{pathname} del programma.
1554 La terza differenza è come viene passata la lista delle variabili di ambiente.
1555 Con lo mnemonico ``\texttt{e}'' vengono indicate quelle funzioni che
1556 necessitano di un vettore di parametri \var{envp[]} analogo a quello usato per
1557 gli argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre
1558 usano il valore della variabile \var{environ} (vedi
1559 sez.~\ref{sec:proc_environ}) del processo di partenza per costruire
1562 Oltre a mantenere lo stesso \ids{PID}, il nuovo programma fatto partire da una
1563 delle funzioni della famiglia \func{exec} mantiene la gran parte delle
1564 proprietà del processo chiamante; una lista delle più significative è la
1567 \item il \textit{process id} (\ids{PID}) ed il \textit{parent process id}
1569 \item l'\textsl{user-ID reale}, il \textsl{group-ID reale} ed i
1570 \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
1571 \item la directory radice (vedi sez.~\ref{sec:file_chroot}) e la directory di
1572 lavoro corrente (vedi sez.~\ref{sec:file_work_dir});
1573 \item la maschera di creazione dei file (\textit{umask}, vedi
1574 sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
1575 sez.~\ref{sec:file_locking});
1576 \item il valori di \textit{nice}, le priorità real-time e le affinità di
1577 processore (vedi sez.~\ref{sec:proc_sched_stand};
1578 sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
1579 \item il \textit{session ID} (\acr{sid}) ed il \textit{process group ID}
1580 (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group};
1581 \item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term});
1582 \item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
1583 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
1584 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime};
1585 \var{tms\_cutime}, \var{tms\_ustime} (vedi sez.~\ref{sec:sys_cpu_times});
1586 \item la maschera dei segnali (si veda sez.~\ref{sec:sig_sigmask});
1587 \item l'insieme dei segnali pendenti (vedi sez.~\ref{sec:sig_gen_beha}).
1590 Una serie di proprietà del processo originale, che non avrebbe senso mantenere
1591 in un programma che esegue un codice completamente diverso in uno spazio di
1592 indirizzi totalmente indipendente e ricreato da zero, vengono perse con
1593 l'esecuzione di una \func{exec}. Lo standard POSIX.1-2001 prevede che le
1594 seguenti proprietà non vengano preservate:
1596 \item gli eventuali stack alternativi per i segnali (vedi
1597 sez.~\ref{sec:sig_specific_features});
1598 \item i \textit{directory stream} (vedi sez.~\ref{sec:file_dir_read}), che
1600 \item le mappature dei file in memoria (vedi sez.~\ref{sec:file_memory_map});
1601 \item i segmenti di memoria condivisa SysV (vedi sez.~\ref{sec:ipc_sysv_shm})
1602 e POSIX (vedi sez.~\ref{sec:ipc_posix_shm});
1603 \item i \textit{memory lock} (vedi sez.~\ref{sec:proc_mem_lock});
1604 \item le funzioni registrate all'uscita (vedi sez.~\ref{sec:proc_atexit});
1605 \item i semafori e le code di messaggi POSIX (vedi
1606 sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq});
1607 \item i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}).
1610 Inoltre i segnali che sono stati impostati per essere ignorati nel processo
1611 chiamante mantengono la stessa impostazione pure nel nuovo programma, ma tutti
1612 gli altri segnali, ed in particolare quelli per i quali è stato installato un
1613 gestore vengono impostati alla loro azione predefinita (vedi
1614 sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \signal{SIGCHLD}
1615 che, quando impostato a \const{SIG\_IGN}, potrebbe anche essere reimpostato a
1616 \const{SIG\_DFL}. Lo standard POSIX.1-2001 prevede che questo comportamento
1617 sia deciso dalla singola implementazione, quella di Linux è di non modificare
1618 l'impostazione precedente.
1620 Oltre alle precedenti, che sono completamente generali e disponibili anche su
1621 altri sistemi unix-like, esistono altre proprietà dei processi, attinenti alle
1622 caratteristiche specifiche di Linux, che non vengono preservate
1623 nell'esecuzione della funzione \func{exec}, queste sono:
1625 \item le operazioni di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io})
1626 pendenti vengono cancellate;
1627 \item le \textit{capabilities} vengono modificate come
1628 illustrato in sez.~\ref{sec:proc_capabilities};
1629 \item tutti i \textit{thread} tranne il chiamante\unavref{ (vedi
1630 sez.~\ref{sec:thread_xxx})} vengono cancellati e tutti gli oggetti ad essi
1631 relativi\unavref{ (vedi sez.~\ref{sec:thread_xxx})} sono rimossi;
1632 \item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi
1633 sez.~\ref{sec:process_prctl}) a meno che il programma da eseguire non sia
1634 \acr{suid} o \acr{sgid} (vedi sez.~\ref{sec:proc_access_id} e
1635 sez.~\ref{sec:file_special_perm});
1636 \item il flag \const{PR\_SET\_KEEPCAPS} di \func{prctl} (vedi
1637 sez.~\ref{sec:process_prctl}) viene cancellato;
1638 \item il nome del processo viene impostato al nome del file contenente il
1639 programma messo in esecuzione;
1640 \item il segnale di terminazione viene reimpostato a \signal{SIGCHLD};
1641 \item l'ambiente viene reinizializzato impostando le variabili attinenti alla
1642 localizzazione al valore di default POSIX.
1645 \itindbeg{close-on-exec}
1646 La gestione dei file aperti nel passaggio al nuovo programma lanciato con
1647 \func{exec} dipende dal valore che ha il flag di \textit{close-on-exec} per
1648 ciascun \textit{file descriptor} (vedi sez.~\ref{sec:file_shared_access}). I
1649 file per cui è impostato vengono chiusi, tutti gli altri file restano
1650 aperti. Questo significa che il comportamento predefinito è che i file restano
1651 aperti attraverso una \func{exec}, a meno di non aver impostato esplicitamente
1652 (in apertura o con \func{fnctl}) il suddetto flag. Per le directory, lo
1653 standard POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec},
1654 in genere questo è fatto dalla funzione \func{opendir} (vedi
1655 sez.~\ref{sec:file_dir_read}) che effettua da sola l'impostazione del flag di
1656 \textit{close-on-exec} sulle directory che apre, in maniera trasparente
1658 \itindend{close-on-exec}
1660 Il comportamento della funzione in relazione agli identificatori relativi al
1661 controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms},
1662 qui è sufficiente anticipare (si faccia riferimento a
1663 sez.~\ref{sec:proc_access_id} per la definizione di questi identificatori)
1664 come l'\textsl{user-ID reale} ed il \textsl{group-ID reale} restano sempre gli
1665 stessi, mentre l'\textsl{user-ID salvato} ed il \textsl{group-ID salvato}
1666 vengono impostati rispettivamente all'\textsl{user-ID effettivo} ed il
1667 \textsl{group-ID effettivo}. Questi ultimi normalmente non vengono modificati,
1668 a meno che il file di cui viene chiesta l'esecuzione non abbia o il \acr{suid}
1669 bit o lo \acr{sgid} bit impostato (vedi sez.~\ref{sec:file_special_perm}), in
1670 questo caso l'\textsl{user-ID effettivo} ed il \textsl{group-ID effettivo}
1671 vengono impostati rispettivamente all'utente o al gruppo cui il file
1674 Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
1675 condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
1676 del programma per caricare le librerie necessarie ed effettuare il link
1677 dell'eseguibile; il formato è ormai in completo disuso, per cui è molto
1678 probabile che non il relativo supporto non sia disponibile. Se il programma è
1679 in formato ELF per caricare le librerie dinamiche viene usato l'interprete
1680 indicato nel segmento \constd{PT\_INTERP} previsto dal formato stesso, in
1681 genere questo è \sysfiled{/lib/ld-linux.so.1} per programmi collegati con la
1682 \acr{libc5}, e \sysfiled{/lib/ld-linux.so.2} per programmi collegati con la
1685 Infine nel caso il programma che si vuole eseguire sia uno script e non un
1686 binario, questo deve essere un file di testo che deve iniziare con una linea
1689 #!/path/to/interpreter [argomenti]
1691 dove l'interprete indicato deve essere un eseguibile binario e non un altro
1692 script, che verrà chiamato come se si fosse eseguito il comando
1693 \cmd{interpreter [argomenti] filename}.
1695 Si tenga presente che con Linux quanto viene scritto come \texttt{argomenti}
1696 viene passato all'interprete come un unico argomento con una unica stringa di
1697 lunghezza massima di 127 caratteri e se questa dimensione viene ecceduta la
1698 stringa viene troncata; altri Unix hanno dimensioni massime diverse, e diversi
1699 comportamenti, ad esempio FreeBSD esegue la scansione della riga e la divide
1700 nei vari argomenti e se è troppo lunga restituisce un errore di
1701 \errval{ENAMETOOLONG}; una comparazione dei vari comportamenti sui diversi
1702 sistemi unix-like si trova su
1703 \url{http://www.in-ulm.de/~mascheck/various/shebang/}.
1705 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
1706 basata la gestione tradizionale dei processi in Unix: con \func{fork} si crea
1707 un nuovo processo, con \func{exec} si lancia un nuovo programma, con
1708 \func{exit} e \func{wait} si effettua e verifica la conclusione dei
1709 processi. Tutte le altre funzioni sono ausiliarie e servono per la lettura e
1710 l'impostazione dei vari parametri connessi ai processi.
1714 \section{Il controllo di accesso}
1715 \label{sec:proc_perms}
1717 In questa sezione esamineremo le problematiche relative al controllo di
1718 accesso dal punto di vista dei processi; vedremo quali sono gli identificatori
1719 usati, come questi possono essere modificati nella creazione e nel lancio di
1720 nuovi processi, le varie funzioni per la loro manipolazione diretta e tutte le
1721 problematiche connesse ad una gestione accorta dei privilegi.
1724 \subsection{Gli identificatori del controllo di accesso}
1725 \label{sec:proc_access_id}
1727 Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in
1728 realtà già esistono estensioni di questo modello base, che lo rendono più
1729 flessibile e controllabile, come le \textit{capabilities} illustrate in
1730 sez.~\ref{sec:proc_capabilities}, le ACL per i file (vedi
1731 sez.~\ref{sec:file_ACL}) o il \textit{Mandatory Access Control} di
1732 \textit{SELinux}; inoltre basandosi sul lavoro effettuato con
1733 \textit{SELinux}, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
1734 infrastruttura di sicurezza, i \textit{Linux Security Modules}, o LSM, in
1735 grado di fornire diversi agganci a livello del kernel per modularizzare
1736 tutti i possibili controlli di accesso, cosa che ha permesso di realizzare
1737 diverse alternative a \textit{SELinux}.}
1738 di sicurezza di un sistema unix-like è fondato sui concetti di utente e
1739 gruppo, e sulla separazione fra l'amministratore (\textsl{root}, detto spesso
1740 anche \textit{superuser}) che non è sottoposto a restrizioni, ed il resto
1741 degli utenti, per i quali invece vengono effettuati i vari controlli di
1744 Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
1745 identificatori univoci, lo \itindex{User~ID~(UID)} \textsl{User-ID}
1746 (abbreviato in \ids{UID}) ed il \itindex{Group~ID~(GID)} \textsl{Group-ID}
1747 (abbreviato in \ids{GID}). Questi servono al kernel per identificare uno
1748 specifico utente o un gruppo di utenti, per poi poter controllare che essi
1749 siano autorizzati a compiere le operazioni richieste. Ad esempio in
1750 sez.~\ref{sec:file_access_control} vedremo come ad ogni file vengano associati
1751 un utente ed un gruppo (i suoi \textsl{proprietari}, indicati appunto tramite
1752 un \ids{UID} ed un \ids{GID}) che vengono controllati dal kernel nella
1753 gestione dei permessi di accesso.
1755 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
1756 evidente che per poter implementare un controllo sulle operazioni occorre
1757 anche poter identificare chi è che ha lanciato un certo programma, e pertanto
1758 anche a ciascun processo dovrà essere associato un utente e un gruppo.
1760 Un semplice controllo di una corrispondenza fra identificativi non garantisce
1761 però sufficiente flessibilità per tutti quei casi in cui è necessario poter
1762 disporre di privilegi diversi, o dover impersonare un altro utente per un
1763 limitato insieme di operazioni. Per questo motivo in generale tutti i sistemi
1764 unix-like prevedono che i processi abbiano almeno due gruppi di
1765 identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}
1766 (cioè \textsl{reali} ed \textsl{effettivi}). Nel caso di Linux si aggiungono
1767 poi altri due gruppi, il \textit{saved} (\textsl{salvati}) ed il
1768 \textit{filesystem} (\textsl{di filesystem}), secondo la situazione illustrata
1769 in tab.~\ref{tab:proc_uid_gid}.
1774 \begin{tabular}[c]{|c|c|l|p{7cm}|}
1776 \textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione}
1777 & \textbf{Significato} \\
1780 \texttt{uid} & \textit{real} & \textsl{user-ID reale}
1781 & Indica l'utente che ha lanciato il programma.\\
1782 \texttt{gid} & '' &\textsl{group-ID reale}
1783 & Indica il gruppo principale dell'utente che ha lanciato
1786 \texttt{euid}& \textit{effective} &\textsl{user-ID effettivo}
1787 & Indica l'utente usato nel controllo di accesso.\\
1788 \texttt{egid}& '' & \textsl{group-ID effettivo}
1789 & Indica il gruppo usato nel controllo di accesso.\\
1790 -- & -- & \textsl{group-ID supplementari}
1791 & Indicano gli ulteriori gruppi cui l'utente appartiene.\\
1793 -- & \textit{saved} & \textsl{user-ID salvato}
1794 & Mantiene una copia dell'\acr{euid} iniziale.\\
1795 -- & '' & \textsl{group-ID salvato}
1796 & Mantiene una copia dell'\acr{egid} iniziale.\\
1798 \texttt{fsuid}& \textit{filesystem} &\textsl{user-ID di filesystem}
1799 & Indica l'utente effettivo per l'accesso al filesystem. \\
1800 \texttt{fsgid}& '' & \textsl{group-ID di filesystem}
1801 & Indica il gruppo effettivo per l'accesso al filesystem.\\
1804 \caption{Identificatori di utente e gruppo associati a ciascun processo con
1805 indicazione dei suffissi usati dalle varie funzioni di manipolazione.}
1806 \label{tab:proc_uid_gid}
1809 Al primo gruppo appartengono l'\ids{UID} \textsl{reale} ed il \ids{GID}
1810 \textsl{reale}: questi vengono impostati al login ai valori corrispondenti
1811 all'utente con cui si accede al sistema (e relativo gruppo principale).
1812 Servono per l'identificazione dell'utente e normalmente non vengono mai
1813 cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile
1814 modificarli, ma solo ad un processo che abbia i privilegi di amministratore;
1815 questa possibilità è usata proprio dal programma \cmd{login} che, una volta
1816 completata la procedura di autenticazione, lancia una shell per la quale
1817 imposta questi identificatori ai valori corrispondenti all'utente che entra
1820 Al secondo gruppo appartengono l'\ids{UID} \textsl{effettivo} e il \ids{GID}
1821 \textsl{effettivo}, a cui si aggiungono gli eventuali \ids{GID}
1822 \textsl{supplementari} dei gruppi dei quali l'utente fa parte. Questi sono
1823 invece gli identificatori usati nelle verifiche dei permessi del processo e
1824 per il controllo di accesso ai file (argomento affrontato in dettaglio in
1825 sez.~\ref{sec:file_perm_overview}).
1827 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
1828 \textit{real} tranne nel caso in cui, come accennato in
1829 sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
1830 bit \acr{suid} o \acr{sgid} impostati (il significato di questi bit è
1831 affrontato in dettaglio in sez.~\ref{sec:file_special_perm}). In questo caso
1832 essi saranno impostati all'utente e al gruppo proprietari del file. Questo
1833 consente, per programmi in cui ci sia questa necessità, di dare a qualunque
1834 utente i privilegi o i permessi di un altro, compreso l'amministratore.
1836 Come nel caso del \ids{PID} e del \ids{PPID}, anche tutti questi
1837 identificatori possono essere ottenuti da un programma attraverso altrettante
1838 funzioni di sistema dedicate alla loro lettura, queste sono \funcd{getuid},
1839 \funcd{geteuid}, \funcd{getgid} e \funcd{getegid}, ed i loro prototipi sono:
1844 \fdecl{uid\_t getuid(void)}
1845 \fdesc{Legge l'\ids{UID} reale del processo corrente.}
1846 \fdecl{uid\_t geteuid(void)}
1847 \fdesc{Legge l'\ids{UID} effettivo del processo corrente.}
1848 \fdecl{gid\_t getgid(void)}
1849 \fdesc{Legge il \ids{GID} reale del processo corrente.}
1850 \fdecl{gid\_t getegid(void)}
1851 \fdesc{Legge il \ids{GID} effettivo del processo corrente.}
1853 {Le funzioni ritornano i rispettivi identificativi del processo corrente, e
1854 non sono previste condizioni di errore.}
1857 In generale l'uso di privilegi superiori, ottenibile con un \ids{UID}
1858 \textsl{effettivo} diverso da quello reale, deve essere limitato il più
1859 possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche
1860 un meccanismo che consenta ad un programma di rilasciare gli eventuali
1861 maggiori privilegi necessari, una volta che si siano effettuate le operazioni
1862 per i quali erano richiesti, e a poterli eventualmente recuperare in caso
1865 Questo in Linux viene fatto usando altri due gruppi di identificatori, il
1866 \textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
1867 SVr4, e previsto dallo standard POSIX quando è definita
1868 \macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
1869 del programma su altri Unix è buona norma controllare sempre la
1870 disponibilità di queste funzioni controllando se questa costante è
1871 definita.} il secondo gruppo è specifico di Linux e viene usato per
1872 migliorare la sicurezza con NFS (il \textit{Network File System}, protocollo
1873 che consente di accedere ai file via rete).
1875 L'\ids{UID} \textsl{salvato} ed il \ids{GID} \textsl{salvato} sono copie
1876 dell'\ids{UID} \textsl{effettivo} e del \ids{GID} \textsl{effettivo} del
1877 processo padre, e vengono impostati dalla funzione \func{exec} all'avvio del
1878 processo, come copie dell'\ids{UID} \textsl{effettivo} e del \ids{GID}
1879 \textsl{effettivo} dopo che questi sono stati impostati tenendo conto di
1880 eventuali permessi \acr{suid} o \acr{sgid} (su cui torneremo in
1881 sez.~\ref{sec:file_special_perm}). Essi quindi consentono di tenere traccia
1882 di quale fossero utente e gruppo effettivi all'inizio dell'esecuzione di un
1885 L'\ids{UID} \textsl{di filesystem} e il \ids{GID} \textsl{di filesystem} sono
1886 un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
1887 (torneremo sull'argomento in sez.~\ref{sec:proc_setuid}). Essi sono una
1888 replica dei corrispondenti identificatori del gruppo \textit{effective}, ai
1889 quali si sostituiscono per tutte le operazioni di verifica dei permessi
1890 relativi ai file (trattate in sez.~\ref{sec:file_perm_overview}). Ogni
1891 cambiamento effettuato sugli identificatori effettivi viene automaticamente
1892 riportato su di essi, per cui in condizioni normali si può tranquillamente
1893 ignorarne l'esistenza, in quanto saranno del tutto equivalenti ai precedenti.
1896 \subsection{Le funzioni di gestione degli identificatori dei processi}
1897 \label{sec:proc_setuid}
1899 Le funzioni di sistema più comuni che vengono usate per cambiare identità
1900 (cioè utente e gruppo di appartenenza) ad un processo, e che come accennato in
1901 sez.~\ref{sec:proc_access_id} seguono la semantica POSIX che prevede
1902 l'esistenza dell'\ids{UID} salvato e del \ids{GID} salvato, sono
1903 rispettivamente \funcd{setuid} e \funcd{setgid}; i loro prototipi sono:
1908 \fdecl{int setuid(uid\_t uid)}
1909 \fdesc{Imposta l'\ids{UID} del processo corrente.}
1910 \fdecl{int setgid(gid\_t gid)}
1911 \fdesc{Imposta il \ids{GID} del processo corrente.}
1913 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
1914 caso \var{errno} uno dei valori:
1916 \item[\errcode{EAGAIN}] (solo per \func{setuid}) la chiamata cambierebbe
1917 l'\ids{UID} reale ma il kernel non dispone temporaneamente delle risorse per
1918 farlo, oppure, per i kernel precedenti il 3.1, il cambiamento
1919 dell'\ids{UID} reale farebbe superare il limite per il numero dei processi
1920 \const{RLIMIT\_NPROC} (vedi sez.~\ref{sec:sys_resource_limit}).
1921 \item[\errcode{EINVAL}] il valore di dell'argomento non è valido per il
1922 \textit{namespace} corrente (vedi sez.~\ref{sec:process_namespaces}).
1923 \item[\errcode{EPERM}] non si hanno i permessi per l'operazione richiesta.
1928 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
1929 la prima, la seconda si comporta esattamente allo stesso modo facendo
1930 riferimento al \ids{GID} invece che all'\ids{UID}. Gli eventuali \ids{GID}
1931 supplementari non vengono modificati.
1933 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
1934 l'\ids{UID} effettivo è zero (cioè è quello dell'amministratore di sistema o
1935 il processo ha la capacità \const{CAP\_SETUID}) allora tutti gli
1936 identificatori (\textit{real}, \textit{effective} e \textit{saved}) vengono
1937 impostati al valore specificato da \param{uid}, altrimenti viene impostato
1938 solo l'\ids{UID} effettivo, e soltanto se il valore specificato corrisponde o
1939 all'\ids{UID} reale o all'\ids{UID} salvato, ottenendo un errore di
1940 \errcode{EPERM} negli altri casi.
1942 E' importante notare che la funzione può fallire, con
1943 \errval{EAGAIN},\footnote{non affronteremo qui l'altro caso di errore, che può
1944 avvenire solo quando si esegue la funzione all'interno di un diverso
1945 \textit{user namespace}, argomento su cui torneremo in
1946 sez.~\ref{sec:process_namespaces} ma la considerazione di controllare sempre
1947 lo stato di uscita si applica allo stesso modo.} anche quando viene invocata
1948 da un processo con privilegi di amministratore per cambiare il proprio
1949 l'\ids{UID} reale, sia per una temporanea indisponibilità di risorse del
1950 kernel, sia perché l'utente di cui si vuole assumere l'\ids{UID} andrebbe a
1951 superare un eventuale limite sul numero di processi (il limite
1952 \const{RLIMIT\_NPROC}, che tratteremo in sez.~\ref{sec:sys_resource_limit}),
1953 pertanto occorre sempre verificare lo stato di uscita della funzione.
1955 Non controllare questo tipo di errori perché si presume che la funzione abbia
1956 sempre successo quando si hanno i privilegi di amministratore può avere
1957 conseguente devastanti per la sicurezza, in particolare quando la si usa per
1958 cedere i suddetti privilegi ed eseguire un programma per conto di un utente
1961 E' per diminuire l'impatto di questo tipo di disattenzioni che a partire dal
1962 kernel 3.1 il comportamento di \func{setuid} e di tutte le analoghe funzioni
1963 che tratteremo nel seguito di questa sezione è stato modificato e nel caso di
1964 superamento del limite sulle risorse esse hanno comunque successo. Quando
1965 questo avviene il processo assume comunque il nuovo \ids{UID} ed il controllo
1966 sul superamento di \const{RLIMIT\_NPROC} viene posticipato ad una eventuale
1967 successiva invocazione di \func{execve} (essendo questo poi il caso d'uso più
1968 comune). In tal caso, se alla chiamata ancora sussiste la situazione di
1969 superamento del limite, sarà \func{execve} a fallire con un errore di
1970 \const{EAGAIN}.\footnote{che pertanto, a partire dal kernel 3.1, può
1971 restituire anche questo errore, non presente in altri sistemi
1972 \textit{unix-like}.}
1974 Come accennato l'uso principale di queste funzioni è quello di poter
1975 consentire ad un programma con i bit \acr{suid} o \acr{sgid} impostati (vedi
1976 sez.~\ref{sec:file_special_perm}) di riportare l'\ids{UID} effettivo a quello
1977 dell'utente che ha lanciato il programma, effettuare il lavoro che non
1978 necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
1980 Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
1981 viene gestito l'accesso al file \sysfiled{/var/run/utmp}. In questo file viene
1982 registrato chi sta usando il sistema al momento corrente; chiaramente non può
1983 essere lasciato aperto in scrittura a qualunque utente, che potrebbe
1984 falsificare la registrazione.
1986 Per questo motivo questo file (e l'analogo \sysfiled{/var/log/wtmp} su cui
1987 vengono registrati login e logout) appartengono ad un gruppo dedicato (in
1988 genere \acr{utmp}) ed i programmi che devono accedervi (ad esempio tutti i
1989 programmi di terminale in X, o il programma \cmd{screen} che crea terminali
1990 multipli su una console) appartengono a questo gruppo ed hanno il bit
1991 \acr{sgid} impostato.
1993 Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la
1994 situazione degli identificatori è la seguente:
1997 \textsl{group-ID reale} &=& \textrm{\ids{GID} (del chiamante)} \\
1998 \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
1999 \textsl{group-ID salvato} &=& \textrm{\acr{utmp}}
2001 in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il
2002 programma può accedere a \sysfile{/var/run/utmp} in scrittura ed aggiornarlo.
2003 A questo punto il programma può eseguire una \code{setgid(getgid())} per
2004 impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il
2005 \textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo
2006 non sarà possibile lanciare dal terminale programmi che modificano detto file,
2007 in tal caso infatti la situazione degli identificatori sarebbe:
2010 \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\
2011 \textsl{group-ID effettivo} &=& \textrm{\ids{GID}} \\
2012 \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
2014 e ogni processo lanciato dal terminale avrebbe comunque \ids{GID} come
2015 \textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo
2016 aggiornare lo stato di \sysfile{/var/run/utmp} il programma eseguirà una
2017 \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo
2018 \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che
2019 in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la
2020 funzione avrà successo e riporterà la situazione a:
2023 \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\
2024 \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\
2025 \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)}
2027 consentendo l'accesso a \sysfile{/var/run/utmp}.
2029 Occorre però tenere conto che tutto questo non è possibile con un processo con
2030 i privilegi di amministratore, in tal caso infatti l'esecuzione di una
2031 \func{setuid} comporta il cambiamento di tutti gli identificatori associati al
2032 processo, rendendo impossibile riguadagnare i privilegi di amministratore.
2033 Questo comportamento è corretto per l'uso che ne fa un programma come
2034 \cmd{login} una volta che crea una nuova shell per l'utente, ma quando si
2035 vuole cambiare soltanto l'\ids{UID} effettivo del processo per cedere i
2036 privilegi occorre ricorrere ad altre funzioni.
2038 Le due funzioni di sistema \funcd{setreuid} e \funcd{setregid} derivano da BSD
2039 che, non supportando (almeno fino alla versione 4.3+BSD) gli identificatori
2040 del gruppo \textit{saved}, le usa per poter scambiare fra di loro
2041 \textit{effective} e \textit{real}; i rispettivi prototipi sono:
2046 \fdecl{int setreuid(uid\_t ruid, uid\_t euid)}
2047 \fdesc{Imposta \ids{UID} reale e \ids{UID} effettivo del processo corrente.}
2048 \fdecl{int setregid(gid\_t rgid, gid\_t egid)}
2049 \fdesc{Imposta \ids{GID} reale e \ids{GID} effettivo del processo corrente.}
2051 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2052 caso \var{errno} assume i valori visti per \func{setuid}/\func{setgid}.
2056 Le due funzioni sono identiche, quanto diremo per la prima riguardo gli
2057 \ids{UID} si applica alla seconda per i \ids{GID}. La funzione
2058 \func{setreuid} imposta rispettivamente l'\ids{UID} reale e l'\ids{UID}
2059 effettivo del processo corrente ai valori specificati da \param{ruid}
2062 I processi non privilegiati possono impostare solo valori che corrispondano o
2063 al loro \ids{UID} effettivo o a quello reale o a quello salvato, valori
2064 diversi comportano il fallimento della chiamata. L'amministratore invece può
2065 specificare un valore qualunque. Specificando un argomento di valore $-1$
2066 l'identificatore corrispondente verrà lasciato inalterato.
2068 Con queste funzioni si possono scambiare fra loro gli \ids{UID} reale ed
2069 effettivo, e pertanto è possibile implementare un comportamento simile a
2070 quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
2071 scambio, e recuperandoli, una volta eseguito il lavoro non privilegiato, con
2074 In questo caso però occorre porre molta attenzione quando si creano nuovi
2075 processi nella fase intermedia in cui si sono scambiati gli identificatori, in
2076 questo caso infatti essi avranno un \ids{UID} reale privilegiato, che dovrà
2077 essere esplicitamente eliminato prima di porre in esecuzione un nuovo
2078 programma, occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e
2079 prima della \func{exec} per uniformare l'\ids{UID} reale a quello effettivo,
2080 perché in caso contrario il nuovo programma potrebbe a sua volta effettuare
2081 uno scambio e riottenere dei privilegi non previsti.
2083 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
2084 si pone anche per l'\ids{UID} salvato. Ma la funzione \func{setreuid} deriva
2085 da un'implementazione di sistema che non ne prevede la presenza, e quindi non
2086 è possibile usarla per correggere la situazione come nel caso precedente. Per
2087 questo motivo in Linux tutte le volte che si imposta un qualunque valore
2088 diverso da quello dall'\ids{UID} reale corrente, l'\ids{UID} salvato viene
2089 automaticamente uniformato al valore dell'\ids{UID} effettivo.
2091 Altre due funzioni di sistema, \funcd{seteuid} e \funcd{setegid}, sono
2092 un'estensione dello standard POSIX.1, ma sono comunque supportate dalla
2093 maggior parte degli Unix, esse vengono usate per cambiare gli identificatori
2094 del gruppo \textit{effective} ed i loro prototipi sono:
2099 \fdecl{int seteuid(uid\_t uid)}
2100 \fdesc{Imposta l'\ids{UID} effettivo del processo corrente.}
2101 \fdecl{int setegid(gid\_t gid)}
2102 \fdesc{Imposta il \ids{GID} effettivo del processo corrente.}
2104 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2105 caso \var{errno} assume i valori visti per \func{setuid}/\func{setgid}
2106 tranne \errval{EAGAIN}.
2110 Ancora una volta le due funzioni sono identiche, e quanto diremo per la prima
2111 riguardo gli \ids{UID} si applica allo stesso modo alla seconda per i
2112 \ids{GID}. Con \func{seteuid} gli utenti normali possono impostare l'\ids{UID}
2113 effettivo solo al valore dell'\ids{UID} reale o dell'\ids{UID} salvato,
2114 l'amministratore può specificare qualunque valore. Queste funzioni sono usate
2115 per permettere all'amministratore di impostare solo l'\ids{UID} effettivo,
2116 dato che l'uso normale di \func{setuid} comporta l'impostazione di tutti gli
2119 Le due funzioni di sistema \funcd{setresuid} e \funcd{setresgid} sono invece
2120 un'estensione introdotta in Linux (a partire dal kernel 2.1.44) e permettono
2121 un completo controllo su tutti e tre i gruppi di identificatori
2122 (\textit{real}, \textit{effective} e \textit{saved}), i loro prototipi sono:
2127 \fdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)}
2128 \fdesc{Imposta l'\ids{UID} reale, effettivo e salvato del processo corrente.}
2129 \fdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)}
2130 \fdesc{Imposta il \ids{GID} reale, effettivo e salvato del processo corrente.}
2132 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2133 caso \var{errno} assume i valori visti per \func{setuid}/\func{setgid}.
2137 Di nuovo le due funzioni sono identiche e quanto detto per la prima riguardo
2138 gli \ids{UID} si applica alla seconda per i \ids{GID}. La funzione
2139 \func{setresuid} imposta l'\ids{UID} reale, l'\ids{UID} effettivo e
2140 l'\ids{UID} salvato del processo corrente ai valori specificati
2141 rispettivamente dagli argomenti \param{ruid}, \param{euid} e \param{suid}. I
2142 processi non privilegiati possono cambiare uno qualunque degli \ids{UID} solo
2143 ad un valore corrispondente o all'\ids{UID} reale, o a quello effettivo o a
2144 quello salvato, l'amministratore può specificare i valori che vuole. Un valore
2145 di $-1$ per un qualunque argomento lascia inalterato l'identificatore
2148 Per queste funzioni di sistema esistono anche due controparti,
2149 \funcd{getresuid} e \funcd{getresgid},\footnote{le funzioni non sono standard,
2150 anche se appaiono in altri kernel, su Linux sono presenti dal kernel 2.1.44
2151 e con le versioni della \acr{glibc} a partire dalla 2.3.2, definendo la
2152 macro \macro{\_GNU\_SOURCE}.} che permettono di leggere in blocco i vari
2153 identificatori; i loro prototipi sono:
2158 \fdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)}
2159 \fdesc{Legge l'\ids{UID} reale, effettivo e salvato del processo corrente.}
2160 \fdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)}
2161 \fdesc{Legge il \ids{GID} reale, effettivo e salvato del processo corrente.}
2163 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
2164 caso \var{errno} può assumere solo il valore \errcode{EFAULT} se gli
2165 indirizzi delle variabili di ritorno non sono validi. }
2168 Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
2169 nessun privilegio. I valori sono restituiti negli argomenti, che vanno
2170 specificati come puntatori (è un altro esempio di \textit{value result
2171 argument}). Si noti che queste funzioni sono le uniche in grado di leggere
2172 gli identificatori del gruppo \textit{saved}.
2174 Infine le funzioni \func{setfsuid} e \func{setfsgid} servono per impostare gli
2175 identificatori del gruppo \textit{filesystem} che sono usati da Linux per il
2176 controllo dell'accesso ai file. Come già accennato in
2177 sez.~\ref{sec:proc_access_id} Linux definisce questo ulteriore gruppo di
2178 identificatori, che in circostanze normali sono assolutamente equivalenti a
2179 quelli del gruppo \textit{effective}, dato che ogni cambiamento di questi
2180 ultimi viene immediatamente riportato su di essi.
2182 C'è un solo caso in cui si ha necessità di introdurre una differenza fra gli
2183 identificatori dei gruppi \textit{effective} e \textit{filesystem}, ed è per
2184 ovviare ad un problema di sicurezza che si presenta quando si deve
2185 implementare un server NFS.
2187 Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai
2188 file per assumere l'identità del singolo utente remoto, ma se questo viene
2189 fatto cambiando l'\ids{UID} effettivo o l'\ids{UID} reale il server si espone
2190 alla ricezione di eventuali segnali ostili da parte dell'utente di cui ha
2191 temporaneamente assunto l'identità. Cambiando solo l'\ids{UID} di filesystem
2192 si ottengono i privilegi necessari per accedere ai file, mantenendo quelli
2193 originari per quanto riguarda tutti gli altri controlli di accesso, così che
2194 l'utente non possa inviare segnali al server NFS.
2196 Le due funzioni di sistema usate appositamente per cambiare questi
2197 identificatori sono \funcd{setfsuid} e \funcd{setfsgid} ovviamente sono
2198 specifiche di Linux e non devono essere usate se si intendono scrivere
2199 programmi portabili; i loro prototipi sono:
2203 \fdecl{int setfsuid(uid\_t fsuid)}
2204 \fdesc{Imposta l'\ids{UID} di filesystem del processo corrente.}
2205 \fdecl{int setfsgid(gid\_t fsgid)}
2206 \fdesc{Legge il \ids{GID} di filesystem del processo corrente.}
2209 {Le funzioni restituiscono sia in caso di successo che di errore il valore
2210 corrente dell'identificativo, e in caso di errore non viene impostato nessun
2211 codice in \var{errno}.}
2214 Le due funzioni sono analoghe ed usano il valore passato come argomento per
2215 effettuare l'impostazione dell'identificativo. Le funzioni hanno successo
2216 solo se il processo chiamante ha i privilegi di amministratore o, per gli
2217 altri utenti, se il valore specificato coincide con uno dei di quelli del
2218 gruppo \textit{real}, \textit{effective} o \textit{saved}.
2220 Il problema di queste funzioni è che non restituiscono un codice di errore e
2221 non c'è modo di sapere (con una singola chiamata) di sapere se hanno avuto
2222 successo o meno, per verificarlo occorre eseguire una chiamata aggiuntiva
2223 passando come argomento $-1$ (un valore impossibile per un identificativo),
2224 così fallendo si può di ottenere il valore corrente e verificare se è
2227 \subsection{Le funzioni per la gestione dei gruppi associati a un processo}
2228 \label{sec:proc_setgroups}
2230 Le ultime funzioni che esamineremo sono quelle che permettono di operare sui
2231 gruppi supplementari cui un utente può appartenere. Ogni processo può avere
2232 almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
2233 gruppi secondari può essere ottenuto con \func{sysconf} (vedi
2234 sez.~\ref{sec:sys_limits}), leggendo il parametro
2235 \const{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
2236 ereditati dal processo padre e possono essere cambiati con queste funzioni.
2238 La funzione di sistema che permette di leggere i gruppi supplementari
2239 associati ad un processo è \funcd{getgroups}; questa funzione è definita nello
2240 standard POSIX.1, ed il suo prototipo è:
2245 \fdecl{int getgroups(int size, gid\_t list[])}
2246 \fdesc{Legge gli identificatori dei gruppi supplementari.}
2248 {La funzione ritorna il numero di gruppi letti in caso di successo e $-1$ per
2249 un errore, nel qual caso \var{errno} assumerà uno dei valori:
2251 \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
2252 \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma
2253 minore del numero di gruppi supplementari del processo.
2257 La funzione legge gli identificatori dei gruppi supplementari del processo sul
2258 vettore \param{list} che deve essere di dimensione pari a \param{size}. Non è
2259 specificato se la funzione inserisca o meno nella lista il \ids{GID} effettivo
2260 del processo. Se si specifica un valore di \param{size} uguale a $0$ allora
2261 l'argomento \param{list} non viene modificato, ma si ottiene dal valore di
2262 ritorno il numero di gruppi supplementari.
2264 Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per
2265 ottenere tutti i gruppi a cui appartiene utente identificato per nome; il suo
2270 \fdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups, int
2272 \fdesc{Legge i gruppi cui appartiene un utente.}
2274 {La funzione ritorna il numero di gruppi ottenuto in caso di successo e $-1$
2275 per un errore, che avviene solo quando il numero di gruppi è maggiore di
2276 quelli specificati con \param{ngroups}.}
2279 La funzione esegue una scansione del database dei gruppi (si veda
2280 sez.~\ref{sec:sys_user_group}) per leggere i gruppi supplementari dell'utente
2281 specificato per nome (e non con un \ids{UID}) nella stringa passata con
2282 l'argomento \param{user}. Ritorna poi nel vettore \param{groups} la lista dei
2283 \ids{GID} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups},
2284 che in ingresso deve indicare la dimensione di \param{group}, è passato come
2285 \textit{value result argument} perché, qualora il valore specificato sia
2286 troppo piccolo, la funzione ritorna $-1$, passando comunque indietro il numero
2287 dei gruppi trovati, in modo da poter ripetere la chiamata con un vettore di
2288 dimensioni adeguate.
2290 Infine per impostare i gruppi supplementari di un processo ci sono due
2291 funzioni, che possono essere usate solo se si hanno i privilegi di
2292 amministratore.\footnote{e più precisamente se si ha la \textit{capability}
2293 \const{CAP\_SETGID}.} La prima delle due è la funzione di sistema
2294 \funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, ma a
2295 differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
2296 poterla utilizzare deve essere definita la macro \macro{\_BSD\_SOURCE}.} ed
2301 \fdecl{int setgroups(size\_t size, gid\_t *list)}
2302 \fdesc{Imposta i gruppi supplementari del processo.}
2304 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2305 caso \var{errno} assumerà uno dei valori:
2307 \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
2308 \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
2309 massimo consentito di gruppi supplementari.
2310 \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
2314 La funzione imposta i gruppi supplementari del processo corrente ai valori
2315 specificati nel vettore passato con l'argomento \param{list}, di dimensioni
2316 date dall'argomento \param{size}. Il numero massimo di gruppi supplementari
2317 che si possono impostare è un parametro di sistema, che può essere ricavato
2318 con le modalità spiegate in sez.~\ref{sec:sys_characteristics}.
2320 Se invece si vogliono impostare i gruppi supplementari del processo a quelli
2321 di un utente specifico, si può usare la funzione \funcd{initgroups} il cui
2327 \fdecl{int initgroups(const char *user, gid\_t group)}
2328 \fdesc{Inizializza la lista dei gruppi supplementari.}
2330 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2331 caso \var{errno} assumerà uno dei valori:
2333 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare lo spazio per
2334 informazioni dei gruppi.
2335 \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
2339 La funzione esegue la scansione del database dei gruppi (usualmente
2340 \conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
2341 (di nuovo specificato per nome e non per \ids{UID}) con cui costruisce una
2342 lista di gruppi supplementari, a cui aggiunge anche \param{group}, infine
2343 imposta questa lista per il processo corrente usando \func{setgroups}. Si
2344 tenga presente che sia \func{setgroups} che \func{initgroups} non sono
2345 definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle
2346 quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
2347 \cmd{-ansi}, è pertanto meglio evitarle se si vuole scrivere codice portabile.
2350 \section{La gestione della priorità dei processi}
2351 \label{sec:proc_priority}
2353 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
2354 lo \textit{scheduler} assegna la CPU ai vari processi attivi. In particolare
2355 prenderemo in esame i vari meccanismi con cui viene gestita l'assegnazione del
2356 tempo di CPU, ed illustreremo le varie funzioni di gestione. Tratteremo infine
2357 anche le altre priorità dei processi (come quelle per l'accesso a disco)
2358 divenute disponibili con i kernel più recenti.
2361 \subsection{I meccanismi di \textit{scheduling}}
2362 \label{sec:proc_sched}
2364 \itindbeg{scheduler}
2366 La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
2367 il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
2368 ed oggetto di numerose ricerche; in generale essa dipende in maniera
2369 essenziale anche dal tipo di utilizzo che deve essere fatto del sistema, per
2370 cui non esiste un meccanismo che sia valido per tutti gli usi.
2372 La caratteristica specifica di un sistema \textit{multitasking} come Linux è
2373 quella del cosiddetto \itindex{preemptive~multitasking} \textit{preemptive
2374 multitasking}: questo significa che al contrario di altri sistemi (che usano
2375 invece il cosiddetto \itindex{cooperative~multitasking} \textit{cooperative
2376 multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
2377 quando la CPU deve essere passata ad un altro processo. Come accennato in
2378 sez.~\ref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
2379 apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
2380 distribuire al meglio il tempo di CPU fra i vari processi.
2382 La cosa è resa ancora più complicata dal fatto che con le architetture
2383 multi-processore si deve anche scegliere quale sia la CPU più opportuna da
2384 utilizzare.\footnote{nei processori moderni la presenza di ampie cache può
2385 rendere poco efficiente trasferire l'esecuzione di un processo da una CPU ad
2386 un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è
2387 banale.} Tutto questo comunque appartiene alle sottigliezze
2388 dell'implementazione del kernel; dal punto di vista dei programmi che girano
2389 in \textit{user space}, anche quando si hanno più processori (e dei processi
2390 che sono eseguiti davvero in contemporanea), le politiche di
2391 \textit{scheduling} riguardano semplicemente l'allocazione della risorsa
2392 \textsl{tempo di esecuzione}, la cui assegnazione sarà governata dai
2393 meccanismi di scelta delle priorità che restano gli stessi indipendentemente
2394 dal numero di processori.
2396 Si tenga conto poi che i processi non devono solo eseguire del codice: ad
2397 esempio molto spesso saranno impegnati in operazioni di I/O, o potranno
2398 venire bloccati da un comando dal terminale, o sospesi per un certo periodo di
2399 tempo. In tutti questi casi la CPU diventa disponibile ed è compito dello
2400 kernel provvedere a mettere in esecuzione un altro processo.
2402 Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
2403 processo; in Linux un processo può trovarsi in uno degli stati riportati in
2404 tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
2405 \textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
2406 sia la sua priorità, un processo non potrà mai essere messo in esecuzione
2407 fintanto che esso si trova in uno qualunque degli altri stati.
2412 \begin{tabular}[c]{|p{2.4cm}|c|p{9cm}|}
2414 \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
2417 \textit{runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
2418 essere eseguito (in attesa che gli
2419 venga assegnata la CPU).\\
2420 \textit{sleep} & \texttt{S} & Il processo è in attesa di un
2421 risposta dal sistema, ma può essere
2422 interrotto da un segnale.\\
2423 \textit{uninterrutible sleep}& \texttt{D} & Il processo è in
2424 attesa di un risposta dal sistema (in
2425 genere per I/O), e non può essere
2426 interrotto in nessuna circostanza.\\
2427 \textit{stopped} & \texttt{T} & Il processo è stato fermato con un
2428 \signal{SIGSTOP}, o è tracciato.\\
2429 \textit{zombie} & \texttt{Z} & Il processo è terminato ma il
2430 suo stato di terminazione non è ancora
2431 stato letto dal padre.\\
2432 \textit{killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
2433 2.6.25, sostanzialmente identico
2434 all'\textit{uninterrutible sleep} con la
2435 sola differenza che il processo può
2436 terminato con \signal{SIGKILL} (usato per
2440 \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
2441 \texttt{STAT} si è riportata la corrispondente lettera usata dal comando
2442 \cmd{ps} nell'omonimo campo.}
2443 \label{tab:proc_proc_states}
2446 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
2447 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
2448 dello scopo del programma non è detto neanche che sia la più importante, dato
2449 che molti programmi dipendono in maniera molto più critica dall'I/O. Per
2450 questo motivo non è affatto detto che dare ad un programma la massima priorità
2451 di esecuzione abbia risultati significativi in termini di prestazioni.
2453 Il meccanismo tradizionale di \textit{scheduling} di Unix (che tratteremo in
2454 sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle
2455 \textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche
2456 i meno importanti, potessero ricevere un po' di tempo di CPU. In sostanza
2457 quando un processo ottiene la CPU la sua priorità viene diminuita. In questo
2458 modo alla fine, anche un processo con priorità iniziale molto bassa, finisce
2459 per avere una priorità sufficiente per essere eseguito.
2461 Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità
2462 assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione
2463 alla normale priorità dinamica), per tenere conto dei sistemi
2464 \textit{real-time},\footnote{per sistema \textit{real-time} si intende un
2465 sistema in grado di eseguire operazioni in un tempo ben determinato; in
2466 genere si tende a distinguere fra l'\textit{hard real-time} in cui è
2467 necessario che i tempi di esecuzione di un programma siano determinabili con
2468 certezza assoluta (come nel caso di meccanismi di controllo di macchine,
2469 dove uno sforamento dei tempi avrebbe conseguenze disastrose), e
2470 \textit{soft-real-time} in cui un occasionale sforamento è ritenuto
2471 accettabile.} in cui è vitale che i processi che devono essere eseguiti in
2472 un determinato momento non debbano aspettare la conclusione di altri che non
2473 hanno questa necessità.
2475 Il concetto di priorità assoluta dice che quando due processi si contendono
2476 l'esecuzione, vince sempre quello con la priorità assoluta più alta.
2477 Ovviamente questo avviene solo per i processi che sono pronti per essere
2478 eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in
2479 genere indicata con un numero intero, ed un valore più alto comporta una
2480 priorità maggiore. Su questa politica di \textit{scheduling} torneremo in
2481 sez.~\ref{sec:proc_real_time}.
2483 In generale quello che succede in tutti gli Unix moderni è che ai processi
2484 normali viene sempre data una priorità assoluta pari a zero, e la decisione di
2485 assegnazione della CPU è fatta solo con il meccanismo tradizionale della
2486 priorità dinamica. In Linux tuttavia è possibile assegnare anche una priorità
2487 assoluta, nel qual caso un processo avrà la precedenza su tutti gli altri di
2488 priorità inferiore, che saranno eseguiti solo quando quest'ultimo non avrà
2492 \subsection{Il meccanismo di \textit{scheduling} standard}
2493 \label{sec:proc_sched_stand}
2495 A meno che non si abbiano esigenze specifiche,\footnote{per alcune delle quali
2496 sono state introdotte delle varianti specifiche.} l'unico meccanismo di
2497 \textit{scheduling} con il quale si avrà a che fare è quello tradizionale, che
2498 prevede solo priorità dinamiche. È di questo che, di norma, ci si dovrà
2499 preoccupare nella programmazione. Come accennato in Linux i processi ordinari
2500 hanno tutti una priorità assoluta nulla; quello che determina quale, fra tutti
2501 i processi in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta
2502 \textsl{priorità dinamica}, quella che viene mostrata nella colonna
2503 \texttt{PR} del comando \texttt{top}, che è chiamata così proprio perché varia
2504 nel corso dell'esecuzione di un processo.
2506 Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
2507 dipende strettamente dalla versione di kernel; in particolare a partire
2508 dalla serie 2.6.x lo \textit{scheduler} è stato riscritto completamente, con
2509 molte modifiche susseguitesi per migliorarne le prestazioni, per un certo
2510 periodo ed è stata anche introdotta la possibilità di usare diversi
2511 algoritmi, selezionabili sia in fase di compilazione, che, nelle versioni
2512 più recenti, all'avvio (addirittura è stato ideato un sistema modulare che
2513 permette di cambiare lo \textit{scheduler} a sistema attivo).} ma a grandi
2514 linee si può dire che ad ogni processo è assegnata una \textit{time-slice},
2515 cioè un intervallo di tempo (letteralmente una fetta) per il quale, a meno di
2516 eventi esterni, esso viene eseguito senza essere interrotto. Inoltre la
2517 priorità dinamica viene calcolata dallo \textit{scheduler} a partire da un
2518 valore iniziale che viene \textsl{diminuito} tutte le volte che un processo è
2519 in stato \textit{runnable} ma non viene posto in esecuzione.\footnote{in
2520 realtà il calcolo della priorità dinamica e la conseguente scelta di quale
2521 processo mettere in esecuzione avviene con un algoritmo molto più
2522 complicato, che tiene conto anche della \textsl{interattività} del processo,
2523 utilizzando diversi fattori, questa è una brutale semplificazione per
2524 rendere l'idea del funzionamento, per una trattazione più dettagliata dei
2525 meccanismi di funzionamento dello \textit{scheduler}, anche se non
2526 aggiornatissima, si legga il quarto capitolo di \cite{LinKernDev}.}
2528 Lo \textit{scheduler} infatti mette sempre in esecuzione, fra tutti i processi
2529 in stato \textit{runnable}, quello che ha il valore di priorità dinamica più
2530 basso; con le priorità dinamiche il significato del valore numerico ad esse
2531 associato è infatti invertito, un valore più basso significa una priorità
2532 maggiore. Il fatto che questo valore venga diminuito quando un processo non
2533 viene posto in esecuzione pur essendo pronto, significa che la priorità dei
2534 processi che non ottengono l'uso del processore viene progressivamente
2535 incrementata, così che anche questi alla fine hanno la possibilità di essere
2538 Sia la dimensione della \textit{time-slice} che il valore di partenza della
2539 priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o
2540 \textit{niceness}) del processo.\footnote{questa è una delle tante proprietà
2541 che ciascun processo si porta dietro, essa viene ereditata dai processi
2542 figli e mantenuta attraverso una \func{exec}; fino alla serie 2.4 essa era
2543 mantenuta nell'omonimo campo \texttt{nice} della \texttt{task\_struct}, con
2544 la riscrittura dello \textit{scheduler} eseguita nel 2.6 viene mantenuta nel
2545 campo \texttt{static\_prio} come per le priorità statiche.} L'origine del
2546 nome di questo parametro sta nel fatto che generalmente questo viene usato per
2547 \textsl{diminuire} la priorità di un processo, come misura di cortesia nei
2548 confronti degli altri. I processi infatti vengono creati dal sistema con un
2549 valore nullo e nessuno è privilegiato rispetto agli altri. Specificando un
2550 valore di \textit{nice} positivo si avrà una \textit{time-slice} più breve ed
2551 un valore di priorità dinamica iniziale più alto, mentre un valore negativo
2552 darà una \textit{time-slice} più lunga ed un valore di priorità dinamica
2555 Esistono diverse funzioni che consentono di indicare un valore di
2556 \textit{nice} di un processo; la più semplice è \funcd{nice}, che opera sul
2557 processo corrente, il suo prototipo è:
2561 \fdecl{int nice(int inc)}
2562 \fdesc{Aumenta il valore di \textit{nice} del processo corrente.}
2564 {La funzione ritorna il nuovo valore di \textit{nice} in caso di successo e
2565 $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
2567 \item[\errcode{EPERM}] non si ha il permesso di specificare un valore
2568 di \param{inc} negativo.
2572 \constbeg{PRIO\_MIN}
2573 \constbeg{PRIO\_MAX}
2575 L'argomento \param{inc} indica l'incremento da effettuare rispetto al valore
2576 di \textit{nice} corrente, che può assumere valori compresi fra
2577 \const{PRIO\_MIN} e \const{PRIO\_MAX}; nel caso di Linux sono fra $-20$ e
2578 $19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di
2579 kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere
2580 anche l'intervallo fra $-20$ e $20$.} ma per \param{inc} si può specificare
2581 un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare
2582 il risultato nell'intervallo consentito. Valori positivi comportano maggiore
2583 \textit{cortesia} e cioè una diminuzione della priorità, valori negativi
2584 comportano invece un aumento della priorità. Con i kernel precedenti il 2.6.12
2585 solo l'amministratore\footnote{o un processo con la \textit{capability}
2586 \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} può
2587 specificare valori negativi di \param{inc} che permettono di aumentare la
2588 priorità di un processo, a partire da questa versione è consentito anche agli
2589 utenti normali alzare (entro certi limiti, che vedremo in
2590 sez.~\ref{sec:sys_resource_limit}) la priorità dei propri processi.
2592 \constend{PRIO\_MIN}
2593 \constend{PRIO\_MAX}
2595 Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
2596 di \textit{nice} del processo; tuttavia la \textit{system call} di Linux non
2597 segue questa convenzione e restituisce sempre $0$ in caso di successo e $-1$
2598 in caso di errore; questo perché $-1$ è anche un valore di \textit{nice}
2599 legittimo e questo comporta una confusione con una eventuale condizione di
2600 errore. La \textit{system call} originaria inoltre non consente, se non dotati
2601 di adeguati privilegi, di diminuire un valore di \textit{nice} precedentemente
2604 Fino alla \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
2605 risultato dalla \textit{system call}, violando lo standard, per cui per
2606 ottenere il nuovo valore occorreva una successiva chiamata alla funzione
2607 \func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
2608 reimplementata e non viene più chiamata la omonima \textit{system call}, con
2609 questa versione viene restituito come valore di ritorno il valore di
2610 \textit{nice}, come richiesto dallo standard.\footnote{questo viene fatto
2611 chiamando al suo interno \func{setpriority}, che tratteremo a breve.} In
2612 questo caso l'unico modo per rilevare in maniera affidabile una condizione di
2613 errore è quello di azzerare \var{errno} prima della chiamata della funzione e
2614 verificarne il valore quando \func{nice} restituisce $-1$.
2616 Per leggere il valore di \textit{nice} di un processo occorre usare la
2617 funzione di sistema \funcd{getpriority}, derivata da BSD; il suo prototipo è:
2621 \fhead{sys/resource.h}
2622 \fdecl{int getpriority(int which, int who)}
2623 \fdesc{Legge un valore di \textit{nice}.}
2625 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2626 caso \var{errno} assumerà uno dei valori:
2628 \item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
2629 elencati in tab.~\ref{tab:proc_getpriority}.
2630 \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2631 \param{which} e \param{who}.
2635 La funzione permette, a seconda di quanto specificato nell'argomento
2636 \param{which}, di leggere il valore di \textit{nice} o di un processo, o di un
2637 gruppo di processi (vedi sez.~\ref{sec:sess_proc_group}) o di un utente,
2638 indicati con l'argomento \param{who}. Nelle vecchie versioni può essere
2639 necessario includere anche \headfiled{sys/time.h}, questo non è più necessario
2640 con versioni recenti delle librerie, ma è comunque utile per portabilità.
2642 I valori possibili per \param{which}, ed il tipo di valore che occorre usare
2643 in corrispondenza per \param{who}, solo elencati nella legenda di
2644 tab.~\ref{tab:proc_getpriority} insieme ai relativi significati. Usare un
2645 valore nullo per \param{who} indica, a seconda della corrispondente
2646 indicazione usata per \param{which}, il processo, il gruppo di processi o
2652 \begin{tabular}[c]{|c|c|l|}
2654 \param{which} & \param{who} & \textbf{Significato} \\
2657 \constd{PRIO\_PROCESS} & \type{pid\_t} & processo \\
2658 \constd{PRIO\_PRGR} & \type{pid\_t} & \textit{process group} (vedi
2659 sez.~\ref{sec:sess_proc_group})\\
2660 \constd{PRIO\_USER} & \type{uid\_t} & utente \\
2663 \caption{Legenda del valore dell'argomento \param{which} e del tipo
2664 dell'argomento \param{who} delle funzioni \func{getpriority} e
2665 \func{setpriority} per le tre possibili scelte.}
2666 \label{tab:proc_getpriority}
2669 In caso di una indicazione che faccia riferimento a più processi, la funzione
2670 restituisce la priorità più alta (cioè il valore più basso) fra quelle dei
2671 processi corrispondenti. Come per \func{nice}, $-1$ è un possibile valore
2672 corretto, per cui di nuovo per poter rilevare una condizione di errore è
2673 necessario cancellare sempre \var{errno} prima della chiamata alla funzione e
2674 quando si ottiene un valore di ritorno uguale a $-1$ per verificare che essa
2675 resti uguale a zero.
2677 Analoga a \func{getpriority} è la funzione di sistema \funcd{setpriority} che
2678 permette di impostare la priorità di uno o più processi; il suo prototipo è:
2682 \fhead{sys/resource.h}
2683 \fdecl{int setpriority(int which, int who, int prio)}
2684 \fdesc{Imposta un valore di \textit{nice}.}
2686 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2687 caso \var{errno} assumerà uno dei valori:
2689 \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
2690 sufficienti privilegi.
2691 \item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
2692 elencati in tab.~\ref{tab:proc_getpriority}.
2693 \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
2694 cercato di modificare la priorità di un processo di un altro utente.
2695 \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
2696 \param{which} e \param{who}.
2700 La funzione imposta la priorità dinamica al valore specificato da \param{prio}
2701 per tutti i processi indicati dagli argomenti \param{which} e \param{who}, per
2702 i quali valgono le stesse considerazioni fatte per \func{getpriority} e lo
2703 specchietto di tab.~\ref{tab:proc_getpriority}.
2705 In questo caso come valore di \param{prio} deve essere specificato il valore
2706 di \textit{nice} da assegnare nell'intervallo fra \const{PRIO\_MIN} ($-20$) e
2707 \const{PRIO\_MAX} ($19$), e non un incremento (positivo o negativo) come nel
2708 caso di \func{nice}. La funzione restituisce il valore di \textit{nice}
2709 assegnato in caso di successo e $-1$ in caso di errore, e come per \func{nice}
2710 anche in questo caso per rilevare un errore occorre sempre porre a zero
2711 \var{errno} prima della chiamata della funzione, essendo $-1$ un valore di
2712 \textit{nice} valido.
2714 Si tenga presente che solo l'amministratore\footnote{o più precisamente un
2715 processo con la \textit{capability} \const{CAP\_SYS\_NICE}, vedi
2716 sez.~\ref{sec:proc_capabilities}.} ha la possibilità di modificare
2717 arbitrariamente le priorità di qualunque processo. Un utente normale infatti
2718 può modificare solo la priorità dei suoi processi ed in genere soltanto
2719 diminuirla. Fino alla versione di kernel 2.6.12 Linux ha seguito le
2720 specifiche dello standard SUSv3, e come per tutti i sistemi derivati da SysV
2721 veniva richiesto che l'\ids{UID} reale o quello effettivo del processo
2722 chiamante corrispondessero all'\ids{UID} reale (e solo a quello) del processo
2723 di cui si intendeva cambiare la priorità. A partire dalla versione 2.6.12 è
2724 stata adottata la semantica in uso presso i sistemi derivati da BSD (SunOS,
2725 Ultrix, *BSD), in cui la corrispondenza può essere anche con l'\ids{UID}
2728 Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
2729 ordinari poter aumentare la priorità dei propri processi specificando un
2730 valore di \param{prio} negativo. Questa operazione non è possibile però in
2731 maniera indiscriminata, ed in particolare può essere effettuata solo
2732 nell'intervallo consentito dal valore del limite \const{RLIMIT\_NICE}
2733 (torneremo su questo in sez.~\ref{sec:sys_resource_limit}).
2735 Infine nonostante i valori siano sempre rimasti gli stessi, il significato del
2736 valore di \textit{nice} è cambiato parecchio nelle progressive riscritture
2737 dello \textit{scheduler} di Linux, ed in particolare a partire dal kernel
2738 2.6.23 l'uso di diversi valori di \textit{nice} ha un impatto molto più forte
2739 nella distribuzione della CPU ai processi. Infatti se viene comunque calcolata
2740 una priorità dinamica per i processi che non ricevono la CPU, così che anche
2741 essi possano essere messi in esecuzione, un alto valore di \textit{nice}
2742 corrisponde comunque ad una \textit{time-slice} molto piccola che non cresce
2743 comunque, per cui un processo a bassa priorità avrà davvero scarse possibilità
2744 di essere eseguito in presenza di processi attivi a priorità più alta.
2747 \subsection{Il meccanismo di \textit{scheduling real-time}}
2748 \label{sec:proc_real_time}
2750 Come spiegato in sez.~\ref{sec:proc_sched} lo standard POSIX.1b ha introdotto
2751 le priorità assolute per permettere la gestione di processi
2752 \textit{real-time}. In realtà nel caso di Linux non si tratta di un vero
2753 \textit{hard real-time}, in quanto in presenza di eventuali interrupt il
2754 kernel interrompe l'esecuzione di un processo, qualsiasi sia la sua
2755 priorità,\footnote{questo a meno che non si siano installate le patch di
2756 RTLinux, RTAI o Adeos, con i quali è possibile ottenere un sistema
2757 effettivamente \textit{hard real-time}. In tal caso infatti gli interrupt
2758 vengono intercettati dall'interfaccia \textit{real-time} (o nel caso di
2759 Adeos gestiti dalle code del nano-kernel), in modo da poterli controllare
2760 direttamente qualora ci sia la necessità di avere un processo con priorità
2761 più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
2762 \textit{page fault} si possono avere ritardi non previsti. Se l'ultimo
2763 problema può essere aggirato attraverso l'uso delle funzioni di controllo
2764 della memoria virtuale (vedi sez.~\ref{sec:proc_mem_lock}), il primo non è
2765 superabile e può comportare ritardi non prevedibili riguardo ai tempi di
2766 esecuzione di qualunque processo.
2768 Nonostante questo, ed in particolare con una serie di miglioramenti che sono
2769 stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire
2770 dalla versione 2.6.18 sono stati inserite nel kernel una serie di modifiche
2771 che consentono di avvicinarsi sempre di più ad un vero e proprio sistema
2772 \textit{real-time} estendendo il concetto di \textit{preemption} alle
2773 operazioni dello stesso kernel; esistono vari livelli a cui questo può
2774 essere fatto, ottenibili attivando in fase di compilazione una fra le
2775 opzioni \texttt{CONFIG\_PREEMPT\_NONE}, \texttt{CONFIG\_PREEMPT\_VOLUNTARY}
2776 e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima
2777 approssimazione di sistema \textit{real-time} usando le priorità assolute.
2778 Occorre farlo però con molta attenzione: se si dà ad un processo una priorità
2779 assoluta e questo finisce in un loop infinito, nessun altro processo potrà
2780 essere eseguito, ed esso sarà mantenuto in esecuzione permanentemente
2781 assorbendo tutta la CPU e senza nessuna possibilità di riottenere l'accesso al
2782 sistema. Per questo motivo è sempre opportuno, quando si lavora con processi
2783 che usano priorità assolute, tenere attiva una shell cui si sia assegnata la
2784 massima priorità assoluta, in modo da poter essere comunque in grado di
2785 rientrare nel sistema.
2787 Quando c'è un processo con priorità assoluta lo \textit{scheduler} lo metterà
2788 in esecuzione prima di ogni processo normale. In caso di più processi sarà
2789 eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
2790 processi con la stessa priorità assoluta questi vengono tenuti in una coda e
2791 tocca al kernel decidere quale deve essere eseguito. Il meccanismo con cui
2792 vengono gestiti questi processi dipende dalla politica di \textit{scheduling}
2793 che si è scelta; lo standard ne prevede due:
2794 \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
2795 \item[\textit{First In First Out} (FIFO)] Il processo viene eseguito
2796 fintanto che non cede volontariamente la CPU (con la funzione
2797 \func{sched\_yield}), si blocca, finisce o viene interrotto da un processo a
2798 priorità più alta. Se il processo viene interrotto da uno a priorità più
2799 alta esso resterà in cima alla lista e sarà il primo ad essere eseguito
2800 quando i processi a priorità più alta diverranno inattivi. Se invece lo si
2801 blocca volontariamente sarà posto in coda alla lista (ed altri processi con
2802 la stessa priorità potranno essere eseguiti).
2803 \item[\textit{Round Robin} (RR)] Il comportamento è del tutto analogo a quello
2804 precedente, con la sola differenza che ciascun processo viene eseguito al
2805 massimo per un certo periodo di tempo (la cosiddetta \textit{time-slice})
2806 dopo di che viene automaticamente posto in fondo alla coda dei processi con
2807 la stessa priorità. In questo modo si ha comunque una esecuzione a turno di
2808 tutti i processi, da cui il nome della politica. Solo i processi con la
2809 stessa priorità ed in stato \textit{runnable} entrano nel
2813 Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare
2814 le politiche di \textit{scheduling}, passando da \textit{real-time} a
2815 ordinarie o viceversa, che di specificare, in caso di politiche
2816 \textit{real-time}, la eventuale priorità statica; la funzione di sistema è
2817 \funcd{sched\_setscheduler} ed il suo prototipo è:
2821 \fdecl{int sched\_setscheduler(pid\_t pid, int policy, const struct
2823 \fdesc{Imposta priorità e politica di \textit{scheduling}.}
2825 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2826 caso \var{errno} assumerà uno dei valori:
2828 \item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il
2829 valore di \param{p} non è valido per la politica scelta.
2830 \item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
2832 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
2836 La funzione esegue l'impostazione per il processo specificato dall'argomento
2837 \param{pid}; un valore nullo di questo argomento esegue l'impostazione per il
2838 processo corrente. La politica di \textit{scheduling} è specificata
2839 dall'argomento \param{policy} i cui possibili valori sono riportati in
2840 tab.~\ref{tab:proc_sched_policy}; la parte alta della tabella indica le
2841 politiche \textit{real-time}, quella bassa le politiche ordinarie. Un valore
2842 negativo per \param{policy} mantiene la politica di \textit{scheduling}
2848 \begin{tabular}[c]{|l|p{6cm}|}
2850 \textbf{Politica} & \textbf{Significato} \\
2853 \constd{SCHED\_FIFO} & \textit{Scheduling real-time} con politica
2855 \constd{SCHED\_RR} & \textit{Scheduling real-time} con politica
2856 \textit{Round Robin}. \\
2858 \constd{SCHED\_OTHER}& \textit{Scheduling} ordinario.\\
2859 \constd{SCHED\_BATCH}& \textit{Scheduling} ordinario con l'assunzione
2860 ulteriore di lavoro \textit{CPU
2861 intensive} (dal kernel 2.6.16).\\
2862 \constd{SCHED\_IDLE} & \textit{Scheduling} di priorità estremamente
2863 bassa (dal kernel 2.6.23).\\
2866 \caption{Valori dell'argomento \param{policy} per la funzione
2867 \func{sched\_setscheduler}.}
2868 \label{tab:proc_sched_policy}
2871 % TODO Aggiungere SCHED_DEADLINE, sulla nuova politica di scheduling aggiunta
2872 % con il kernel 3.14, vedi anche Documentation/scheduler/sched-deadline.txt e
2873 % http://lwn.net/Articles/575497/
2874 % vedi anche man 7 sched, man sched_setattr
2875 % https://lwn.net/Articles/805317/
2877 Con le versioni più recenti del kernel sono state introdotte anche delle
2878 varianti sulla politica di \textit{scheduling} tradizionale per alcuni carichi
2879 di lavoro specifici, queste due nuove politiche sono specifiche di Linux e non
2880 devono essere usate se si vogliono scrivere programmi portabili.
2882 La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
2883 la sola differenza che i processi ad essa soggetti non ottengono, nel calcolo
2884 delle priorità dinamiche fatto dallo \textit{scheduler}, il cosiddetto bonus
2885 di interattività che mira a favorire i processi che si svegliano dallo stato
2886 di \textit{sleep}.\footnote{cosa che accade con grande frequenza per i
2887 processi interattivi, dato che essi sono per la maggior parte del tempo in
2888 attesa di dati in ingresso da parte dell'utente.} La si usa pertanto, come
2889 indica il nome, per processi che usano molta CPU (come programmi di calcolo)
2890 che in questo modo, pur non perdendo il loro valore di \textit{nice}, sono
2891 leggermente sfavoriti rispetto ai processi interattivi che devono rispondere a
2892 dei dati in ingresso.
2894 La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
2895 si desidera siano eseguiti con la più bassa priorità possibile, ancora più
2896 bassa di un processo con il minimo valore di \textit{nice}. In sostanza la si
2897 può utilizzare per processi che devono essere eseguiti se non c'è niente altro
2898 da fare. Va comunque sottolineato che anche un processo \const{SCHED\_IDLE}
2899 avrà comunque una sua possibilità di utilizzo della CPU, sia pure in
2900 percentuale molto bassa.
2902 Qualora si sia richiesta una politica \textit{real-time} il valore della
2903 priorità statica viene impostato attraverso la struttura
2904 \struct{sched\_param}, riportata in fig.~\ref{fig:sig_sched_param}, il cui
2905 solo campo attualmente definito è \var{sched\_priority}. Il campo deve
2906 contenere il valore della priorità statica da assegnare al processo; lo
2907 standard prevede che questo debba essere assegnato all'interno di un
2908 intervallo fra un massimo ed un minimo che nel caso di Linux sono
2909 rispettivamente 1 e 99.
2911 \begin{figure}[!htb]
2912 \footnotesize \centering
2913 \begin{minipage}[c]{0.5\textwidth}
2914 \includestruct{listati/sched_param.c}
2917 \caption{La struttura \structd{sched\_param}.}
2918 \label{fig:sig_sched_param}
2921 I processi con politica di \textit{scheduling} ordinaria devono sempre
2922 specificare un valore nullo di \var{sched\_priority} altrimenti si avrà un
2923 errore \errcode{EINVAL}, questo valore infatti non ha niente a che vedere con
2924 la priorità dinamica determinata dal valore di \textit{nice}, che deve essere
2925 impostato con le funzioni viste in precedenza.
2927 Lo standard POSIX.1b prevede che l'intervallo dei valori delle priorità
2928 statiche possa essere ottenuto con le funzioni di sistema
2929 \funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
2934 \fdecl{int sched\_get\_priority\_max(int policy)}
2935 \fdesc{Legge il valore massimo di una priorità statica.}
2936 \fdecl{int sched\_get\_priority\_min(int policy)}
2937 \fdesc{Legge il valore minimo di una priorità statica.}
2939 {Le funzioni ritornano il valore della priorità in caso di successo e $-1$ per
2940 un errore, nel qual caso \var{errno} assumerà il valore:
2942 \item[\errcode{EINVAL}] il valore di \param{policy} non è valido.
2946 Le funzioni ritornano rispettivamente il valore massimo e minimo usabile per
2947 la priorità statica di una delle politiche di \textit{scheduling}
2948 \textit{real-time} indicata dall'argomento \param{policy}.
2950 Si tenga presente che quando si imposta una politica di \textit{scheduling}
2951 real-time per un processo o se ne cambia la priorità statica questo viene
2952 messo in cima alla lista dei processi con la stessa priorità; questo comporta
2953 che verrà eseguito subito, interrompendo eventuali altri processi con la
2954 stessa priorità in quel momento in esecuzione.
2956 Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed
2957 esegue sempre il primo della lista, mentre un nuovo processo che torna in
2958 stato \textit{runnable} viene sempre inserito in coda alla lista. Se la
2959 politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene
2960 automaticamente rimesso in coda alla lista, e la sua esecuzione continua
2961 fintanto che non viene bloccato da una richiesta di I/O, o non rilascia
2962 volontariamente la CPU (in tal caso, tornando nello stato \textit{runnable}
2963 sarà in coda alla lista); l'esecuzione viene ripresa subito solo nel caso che
2964 esso sia stato interrotto da un processo a priorità più alta.
2966 Solo un processo con i privilegi di amministratore\footnote{più precisamente
2967 con la capacità \const{CAP\_SYS\_NICE}, vedi
2968 sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
2969 assolute diverse da zero o politiche \const{SCHED\_FIFO} e
2970 \const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
2971 processi che gli appartengono; è cioè richiesto che l'\ids{UID} effettivo del
2972 processo chiamante corrisponda all'\ids{UID} reale o effettivo del processo
2973 indicato con \param{pid}.
2975 Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche
2976 \textit{real-time} o modificare la eventuale priorità statica di un loro
2977 processo. A partire da questa versione è divenuto possibile anche per gli
2978 utenti normali usare politiche \textit{real-time} fintanto che la priorità
2979 assoluta che si vuole impostare è inferiore al limite \const{RLIMIT\_RTPRIO}
2980 (vedi sez.~\ref{sec:sys_resource_limit}) ad essi assegnato.
2982 Unica eccezione a questa possibilità sono i processi \const{SCHED\_IDLE}, che
2983 non possono cambiare politica di \textit{scheduling} indipendentemente dal
2984 valore di \const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto
2985 ad una politica \textit{real-time}, un utente può sempre, indipendentemente
2986 dal valore di \const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una
2989 Se si intende operare solo sulla priorità statica di un processo si possono
2990 usare le due funzioni di sistema \funcd{sched\_setparam} e
2991 \funcd{sched\_getparam} che consentono rispettivamente di impostarne e
2992 leggerne il valore, i loro prototipi sono:
2996 \fdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *param)}
2997 \fdesc{Imposta la priorità statica di un processo.}
2998 \fdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)}
2999 \fdesc{Legge la priorità statica di un processo.}
3001 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
3002 caso \var{errno} assumerà uno dei valori:
3004 \item[\errcode{EINVAL}] il valore di \param{param} non ha senso per la
3005 politica usata dal processo.
3006 \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
3008 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3012 Le funzioni richiedono di indicare nell'argomento \param{pid} il processo su
3013 cui operare e usano l'argomento \param{param} per mantenere il valore della
3014 priorità dinamica. Questo è ancora una struttura \struct{sched\_param} ed
3015 assume gli stessi valori già visti per \func{sched\_setscheduler}.
3017 L'uso di \func{sched\_setparam}, compresi i controlli di accesso che vi si
3018 applicano, è del tutto equivalente a quello di \func{sched\_setscheduler} con
3019 argomento \param{policy} uguale a $-1$. Come per \func{sched\_setscheduler}
3020 specificando $0$ come valore dell'argomento \param{pid} si opera sul processo
3021 corrente. Benché la funzione sia utilizzabile anche con processi sottoposti a
3022 politica ordinaria essa ha senso soltanto per quelli \textit{real-time}, dato
3023 che per i primi la priorità statica può essere soltanto nulla. La
3024 disponibilità di entrambe le funzioni può essere verificata controllando la
3025 macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'\textit{header
3026 file} \headfiled{sched.h}.
3028 Se invece si vuole sapere quale è politica di \textit{scheduling} di un
3029 processo si può usare la funzione di sistema \funcd{sched\_getscheduler}, il
3034 \fdecl{int sched\_getscheduler(pid\_t pid)}
3035 \fdesc{Legge la politica di \textit{scheduling}.}
3037 {La funzione ritorna la politica di \textit{scheduling} in caso di successo e
3038 $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
3040 \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
3042 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3046 La funzione restituisce il valore, secondo quanto elencato in
3047 tab.~\ref{tab:proc_sched_policy}, della politica di \textit{scheduling} per il
3048 processo specificato dall'argomento \param{pid}, se questo è nullo viene
3049 restituito il valore relativo al processo chiamante.
3051 L'ultima funzione di sistema che permette di leggere le informazioni relative
3052 ai processi real-time è \funcd{sched\_rr\_get\_interval}, che permette di
3053 ottenere la lunghezza della \textit{time-slice} usata dalla politica
3054 \textit{round robin}; il suo prototipo è:
3058 \fdecl{int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)}
3059 \fdesc{Legge la durata della \textit{time-slice} per lo \textit{scheduling}
3060 \textit{round robin}.}
3062 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
3063 caso \var{errno} assumerà uno dei valori:
3065 \item[\errcode{EINVAL}] l'argomento \param{pid} non è valido.
3066 \item[\errcode{ENOSYS}] la \textit{system call} non è presente (solo per
3068 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3070 ed inoltre anche \errval{EFAULT} nel suo significato generico.}
3073 La funzione restituisce nell'argomento \param{tp} come una struttura
3074 \struct{timespec}, (la cui definizione si può trovare in
3075 fig.~\ref{fig:sys_timeval_struct}) il valore dell'intervallo di tempo usato
3076 per la politica \textit{round robin} dal processo indicato da \ids{PID}. Il
3077 valore dipende dalla versione del kernel, a lungo infatti questo intervallo di
3078 tempo era prefissato e non modificabile ad un valore di 150 millisecondi,
3079 restituito indipendentemente dal \ids{PID} indicato.
3081 Con kernel recenti però è possibile ottenere una variazione della
3082 \textit{time-slice}, modificando il valore di \textit{nice} del processo
3083 (anche se questo non incide assolutamente sulla priorità statica) che come
3084 accennato in precedenza modifica il valore assegnato alla \textit{time-slice}
3085 di un processo ordinario, che però viene usato anche dai processi
3088 Come accennato ogni processo può rilasciare volontariamente la CPU in modo da
3089 consentire agli altri processi di essere eseguiti; la funzione di sistema che
3090 consente di fare tutto questo è \funcd{sched\_yield}, il cui prototipo è:
3094 \fdecl{int sched\_yield(void)}
3095 \fdesc{Rilascia volontariamente l'esecuzione.}
3097 {La funzione ritorna $0$ in caso di successo e teoricamente $-1$ per un
3098 errore, ma su Linux ha sempre successo.}
3102 Questa funzione ha un utilizzo effettivo soltanto quando si usa lo
3103 \textit{scheduling} \textit{real-time}, e serve a far sì che il processo
3104 corrente rilasci la CPU, in modo da essere rimesso in coda alla lista dei
3105 processi con la stessa priorità per permettere ad un altro di essere eseguito;
3106 se però il processo è l'unico ad essere presente sulla coda l'esecuzione non
3107 sarà interrotta. In genere usano questa funzione i processi con politica
3108 \const{SCHED\_FIFO}, per permettere l'esecuzione degli altri processi con pari
3109 priorità quando la sezione più urgente è finita.
3111 La funzione può essere utilizzata anche con processi che usano lo
3112 \textit{scheduling} ordinario, ma in questo caso il comportamento non è ben
3113 definito, e dipende dall'implementazione. Fino al kernel 2.6.23 questo
3114 comportava che i processi venissero messi in fondo alla coda di quelli attivi,
3115 con la possibilità di essere rimessi in esecuzione entro breve tempo, con
3116 l'introduzione del \textit{Completely Fair Scheduler} questo comportamento è
3117 cambiato ed un processo che chiama la funzione viene inserito nella lista dei
3118 processi inattivi, con un tempo molto maggiore.\footnote{è comunque possibile
3119 ripristinare un comportamento analogo al precedente scrivendo il valore 1
3120 nel file \sysctlfiled{kernel/sched\_compat\_yield}.}
3122 L'uso delle funzione nella programmazione ordinaria può essere utile e
3123 migliorare le prestazioni generali del sistema quando si è appena rilasciata
3124 una risorsa contesa con altri processi, e si vuole dare agli altri una
3125 possibilità di approfittarne mettendoli in esecuzione, ma chiamarla senza
3126 necessità, specie se questo avviene ripetutamente all'interno di un qualche
3127 ciclo, può avere invece un forte impatto negativo per la generazione di
3128 \textit{context switch} inutili.
3131 \subsection{Il controllo dello \textit{scheduler} per i sistemi
3133 \label{sec:proc_sched_multiprocess}
3135 \index{effetto~ping-pong|(}
3137 Con il supporto dei sistemi multiprocessore sono state introdotte delle
3138 funzioni che permettono di controllare in maniera più dettagliata la scelta di
3139 quale processore utilizzare per eseguire un certo programma. Uno dei problemi
3140 che si pongono nei sistemi multiprocessore è infatti quello del cosiddetto
3141 \textsl{effetto ping-pong}. Può accadere cioè che lo \textit{scheduler},
3142 quando riavvia un processo precedentemente interrotto scegliendo il primo
3143 processore disponibile, lo faccia eseguire da un processore diverso rispetto a
3144 quello su cui era stato eseguito in precedenza. Se il processo passa da un
3145 processore all'altro in questo modo, cosa che avveniva abbastanza di frequente
3146 con i kernel della seria 2.4.x, si ha l'effetto ping-pong.
3148 Questo tipo di comportamento può generare dei seri problemi di prestazioni;
3149 infatti tutti i processori moderni utilizzano una memoria interna (la
3150 \textit{cache}) contenente i dati più usati, che permette di evitare di
3151 eseguire un accesso (molto più lento) alla memoria principale sulla scheda
3152 madre. Chiaramente un processo sarà favorito se i suoi dati sono nella cache
3153 del processore, ma è ovvio che questo può essere vero solo per un processore
3154 alla volta, perché in presenza di più copie degli stessi dati su più
3155 processori, non si potrebbe determinare quale di questi ha la versione dei
3156 dati aggiornata rispetto alla memoria principale.
3158 Questo comporta che quando un processore inserisce un dato nella sua cache,
3159 tutti gli altri processori che hanno lo stesso dato devono invalidarlo, e
3160 questa operazione è molto costosa in termini di prestazioni. Il problema
3161 diventa serio quando si verifica l'effetto ping-pong, in tal caso infatti un
3162 processo \textsl{rimbalza} continuamente da un processore all'altro e si ha
3163 una continua invalidazione della cache, che non diventa mai disponibile.
3165 \itindbeg{CPU~affinity}
3167 Per ovviare a questo tipo di problemi è nato il concetto di \textsl{affinità
3168 di processore} (o \textit{CPU affinity}); la possibilità cioè di far sì che
3169 un processo possa essere assegnato per l'esecuzione sempre allo stesso
3170 processore. Lo \textit{scheduler} dei kernel della serie 2.4.x aveva una
3171 scarsa \textit{CPU affinity}, e l'effetto ping-pong era comune; con il nuovo
3172 \textit{scheduler} dei kernel della 2.6.x questo problema è stato risolto ed
3173 esso cerca di mantenere il più possibile ciascun processo sullo stesso
3176 \index{effetto~ping-pong|)}
3178 In certi casi però resta l'esigenza di poter essere sicuri che un processo sia
3179 sempre eseguito dallo stesso processore,\footnote{quella che viene detta
3180 \textit{hard CPU affinity}, in contrasto con quella fornita dallo
3181 \textit{scheduler}, detta \textit{soft CPU affinity}, che di norma indica
3182 solo una preferenza, non un requisito assoluto.} e per poter risolvere
3183 questo tipo di problematiche nei nuovi kernel\footnote{le due \textit{system
3184 call} per la gestione della \textit{CPU affinity} sono state introdotte
3185 nel kernel 2.5.8, e le corrispondenti funzioni di sistema nella
3186 \textsl{glibc} 2.3.} è stata introdotta l'opportuna infrastruttura ed una
3187 nuova \textit{system call} che permette di impostare su quali processori far
3188 eseguire un determinato processo attraverso una \textsl{maschera di
3189 affinità}. La corrispondente funzione di sistema è
3190 \funcd{sched\_setaffinity} ed il suo prototipo è:
3192 \index{insieme~di~processori|(}
3196 \fdecl{int sched\_setaffinity(pid\_t pid, size\_t setsize,
3198 \fdesc{Imposta la maschera di affinità di un processo.}
3200 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
3201 caso \var{errno} assumerà uno dei valori:
3203 \item[\errcode{EINVAL}] il valore di \param{mask} contiene riferimenti a
3204 processori non esistenti nel sistema o a cui non è consentito l'accesso.
3205 \item[\errcode{EPERM}] il processo non ha i privilegi sufficienti per
3206 eseguire l'operazione.
3207 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3209 ed inoltre anche \errval{EFAULT} nel suo significato generico.}
3212 Questa funzione e la corrispondente \func{sched\_getaffinity} hanno una storia
3213 abbastanza complessa, la sottostante \textit{system call} infatti prevede
3214 l'uso di due soli argomenti (per il pid e l'indicazione della maschera dei
3215 processori), che corrispondono al fatto che l'implementazione effettiva usa
3216 una semplice maschera binaria. Quando le funzioni vennero incluse nella
3217 \acr{glibc} assunsero invece un prototipo simile a quello mostrato però con il
3218 secondo argomento di tipo \ctyp{unsigned int}. A complicare la cosa si
3219 aggiunge il fatto che nella versione 2.3.3 della \acr{glibc} detto argomento
3220 venne stato eliminato, per poi essere ripristinato nella versione 2.3.4 nella
3221 forma attuale.\footnote{pertanto se la vostra pagina di manuale non è
3222 aggiornata, o usate quella particolare versione della \acr{glibc}, potrete
3223 trovare indicazioni diverse, il prototipo illustrato è quello riportato
3224 nella versione corrente (maggio 2008) delle pagine di manuale e
3225 corrispondente alla definizione presente in \headfile{sched.h}.}
3227 La funzione imposta, con l'uso del valore contenuto all'indirizzo
3228 \param{mask}, l'insieme dei processori sui quali deve essere eseguito il
3229 processo identificato tramite il valore passato in \param{pid}. Come in
3230 precedenza il valore nullo di \param{pid} indica il processo corrente. Per
3231 poter utilizzare questa funzione sono richiesti i privilegi di amministratore
3232 (è necessaria la capacità \const{CAP\_SYS\_NICE}) altrimenti essa fallirà con
3233 un errore di \errcode{EPERM}. Una volta impostata una maschera di affinità,
3234 questa viene ereditata attraverso una \func{fork}, in questo modo diventa
3235 possibile legare automaticamente un gruppo di processi ad un singolo
3238 Nell'uso comune, almeno con i kernel successivi alla serie 2.6.x, utilizzare
3239 questa funzione non è necessario, in quanto è lo \textit{scheduler} stesso che
3240 provvede a mantenere al meglio l'affinità di processore. Esistono però
3241 esigenze particolari, ad esempio quando un processo (o un gruppo di processi)
3242 è utilizzato per un compito importante (ad esempio per applicazioni
3243 \textit{real-time} o la cui risposta è critica) e si vuole la massima
3244 velocità; con questa interfaccia diventa possibile selezionare gruppi di
3245 processori utilizzabili in maniera esclusiva. Lo stesso dicasi quando
3246 l'accesso a certe risorse (memoria o periferiche) può avere un costo diverso a
3247 seconda del processore, come avviene nelle architetture NUMA
3248 (\textit{Non-Uniform Memory Access}).
3250 Infine se un gruppo di processi accede alle stesse risorse condivise (ad
3251 esempio una applicazione con più \textit{thread}) può avere senso usare lo
3252 stesso processore in modo da sfruttare meglio l'uso della sua cache; questo
3253 ovviamente riduce i benefici di un sistema multiprocessore nell'esecuzione
3254 contemporanea dei \textit{thread}, ma in certi casi (quando i \textit{thread}
3255 sono inerentemente serializzati nell'accesso ad una risorsa) possono esserci
3256 sufficienti vantaggi nell'evitare la perdita della cache da rendere
3257 conveniente l'uso dell'affinità di processore.
3259 Dato che il numero di processori può variare a seconda delle architetture, per
3260 semplificare l'uso dell'argomento \param{mask} la \acr{glibc} ha introdotto un
3261 apposito dato di tipo, \typed{cpu\_set\_t},\footnote{questa è una estensione
3262 specifica della \acr{glibc}, da attivare definendo la macro
3263 \macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per questo
3264 tipo di interfaccia e POSIX al momento non prevede nulla al riguardo.} che
3265 permette di identificare un insieme di processori. Il dato è normalmente una
3266 maschera binaria: nei casi più comuni potrebbe bastare un intero a 32 bit, in
3267 cui ogni bit corrisponde ad un processore, ma oggi esistono architetture in
3268 cui questo numero può non essere sufficiente, e per questo è stato creato
3269 questo tipo opaco e una interfaccia di gestione che permette di usare a basso
3270 livello un tipo di dato qualunque rendendosi indipendenti dal numero di bit e
3271 dalla loro disposizione. Per questo le funzioni di libreria richiedono che
3272 oltre all'insieme di processori si indichi anche la dimensione dello stesso
3273 con l'argomento \param{setsize}, per il quale, se non si usa l'allocazione
3274 dinamica che vedremo a breve, è in genere sufficiente passare il valore
3275 \code{sizeof(cpu\_set\_t)}.
3277 L'interfaccia di gestione degli insiemi di processori, oltre alla definizione
3278 del tipo \type{cpu\_set\_t}, prevede una serie di macro di preprocessore per
3279 la manipolazione degli stessi. Quelle di base, che consentono rispettivamente
3280 di svuotare un insieme, di aggiungere o togliere un processore o di verificare
3281 se esso è già presente in un insieme, sono le seguenti:
3287 \fdecl{void \macrod{CPU\_ZERO}(cpu\_set\_t *set)}
3288 \fdesc{Inizializza un insieme di processori vuoto \param{set}.}
3289 \fdecl{void \macrod{CPU\_SET}(int cpu, cpu\_set\_t *set)}
3290 \fdesc{Inserisce il processore \param{cpu} nell'insieme di
3291 processori \param{set}.}
3292 \fdecl{void \macrod{CPU\_CLR}(int cpu, cpu\_set\_t *set)}
3293 \fdesc{Rimuove il processore \param{cpu} nell'insieme di
3294 processori \param{set}.}
3295 \fdecl{int \macrod{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
3296 \fdesc{Controlla se il processore \param{cpu} è nell'insieme di
3297 processori \param{set}.}
3301 Queste macro che sono ispirate dalle analoghe usate per gli insiemi di
3302 \textit{file descriptor} (vedi sez.~\ref{sec:file_select}) e sono state
3303 introdotte con la versione 2.3.3 della \acr{glibc}. Tutte richiedono che si
3304 specifichi il numero di una CPU nell'argomento \param{cpu}, ed un insieme su
3305 cui operare. L'unica che ritorna un risultato è \macro{CPU\_ISSET}, che
3306 restituisce un intero da usare come valore logico (zero se la CPU non è
3307 presente, diverso da zero se è presente).
3309 \itindbeg{side~effects}
3310 Si tenga presente che trattandosi di macro l'argomento \param{cpu} può essere
3311 valutato più volte. Questo significa ad esempio che non si può usare al suo
3312 posto una funzione o un'altra macro, altrimenti queste verrebbero eseguite più
3313 volte; l'argomento cioè non deve avere \textsl{effetti collaterali} (in gergo
3314 \textit{side effects}).\footnote{nel linguaggio C si
3315 parla appunto di \textit{side effects} quando si usano istruzioni la cui
3316 valutazione comporta effetti al di fuori dell'istruzione stessa, come il
3317 caso indicato in cui si passa una funzione ad una macro che usa l'argomento
3318 al suo interno più volte, o si scrivono espressioni come \code{a=a++} in cui
3319 non è chiaro se prima avvenga l'incremento e poi l'assegnazione, ed il cui
3320 risultato dipende dall'implementazione del compilatore.}
3321 \itindend{side~effects}
3324 Le CPU sono numerate da zero (che indica la prima disponibile) fino ad un
3325 numero massimo che dipende dall'architettura hardware. La costante
3326 \constd{CPU\_SETSIZE} indica il numero massimo di processori che possono far
3327 parte di un insieme (al momento vale sempre 1024), e costituisce un limite
3328 massimo al valore dell'argomento \param{cpu}. Dalla versione 2.6 della
3329 \acr{glibc} alle precedenti macro è stata aggiunta, per contare il numero di
3330 processori in un insieme, l'ulteriore:
3336 \fdecl{int \macrod{CPU\_COUNT}(cpu\_set\_t *set)}
3337 \fdesc{Conta il numero di processori presenti nell'insieme \param{set}.}
3341 A partire dalla versione 2.7 della \acr{glibc} sono state introdotte altre
3342 macro che consentono ulteriori manipolazioni, in particolare si possono
3343 compiere delle operazioni logiche sugli insiemi di processori con:
3349 \fdecl{void \macrod{CPU\_AND}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
3350 \fdesc{Esegue l'AND logico di due insiemi di processori.}
3351 \fdecl{void \macrod{CPU\_OR}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
3352 \fdesc{Esegue l'OR logico di due insiemi di processori.}
3353 \fdecl{void \macrod{CPU\_XOR}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
3354 \fdesc{Esegue lo XOR logico di due insiemi di processori.}
3355 \fdecl{int \macrod{CPU\_EQUAL}(cpu\_set\_t *set1, cpu\_set\_t *set2)}
3356 \fdesc{Verifica se due insiemi di processori sono uguali.}
3360 Le prime tre macro richiedono due insiemi di partenza, \param{srcset1} e
3361 \param{srcset2} e forniscono in un terzo insieme \param{destset} (che può
3362 essere anche lo stesso di uno dei precedenti) il risultato della rispettiva
3363 operazione logica sui contenuti degli stessi. In sostanza con \macro{CPU\_AND}
3364 si otterrà come risultato l'insieme che contiene le CPU presenti in entrambi
3365 gli insiemi di partenza, con \macro{CPU\_OR} l'insieme che contiene le CPU
3366 presenti in uno qualunque dei due insiemi di partenza, e con \macro{CPU\_XOR}
3367 l'insieme che contiene le CPU presenti in uno solo dei due insiemi di
3368 partenza. Infine \macro{CPU\_EQUAL} confronta due insiemi ed è l'unica che
3369 restituisce un intero, da usare come valore logico che indica se sono identici
3372 Inoltre, sempre a partire dalla versione 2.7 della \acr{glibc}, è stata
3373 introdotta la possibilità di una allocazione dinamica degli insiemi di
3374 processori, per poterli avere di dimensioni corrispondenti al numero di CPU
3375 effettivamente in gioco, senza dover fare riferimento necessariamente alla
3376 precedente dimensione preimpostata di 1024. Per questo motivo sono state
3377 definite tre ulteriori macro, che consentono rispettivamente di allocare,
3378 disallocare ed ottenere la dimensione in byte di un insieme di processori:
3384 \fdecl{cpu\_set\_t * \macrod{CPU\_ALLOC}(num\_cpus)}
3385 \fdesc{Alloca dinamicamente un insieme di processori di dimensione voluta.}
3386 \fdecl{void \macrod{CPU\_FREE}(cpu\_set\_t *set)}
3387 \fdesc{Disalloca un insieme di processori allocato dinamicamente.}
3388 \fdecl{size\_t \macrod{CPU\_ALLOC\_SIZE}(num\_cpus)}
3389 \fdesc{Ritorna la dimensione di un insieme di processori allocato dinamicamente.}
3393 La prima macro, \macro{CPU\_ALLOC}, restituisce il puntatore ad un insieme di
3394 processori in grado di contenere almeno \param{num\_cpus} che viene allocato
3395 dinamicamente. Ogni insieme così allocato dovrà essere disallocato con
3396 \macro{CPU\_FREE} passandogli un puntatore ottenuto da una precedente
3397 \macro{CPU\_ALLOC}. La terza macro, \macro{CPU\_ALLOC\_SIZE}, consente di
3398 ottenere la dimensione in byte di un insieme allocato dinamicamente che
3399 contenga \param{num\_cpus} processori.
3401 Dato che le dimensioni effettive possono essere diverse le macro di gestione e
3402 manipolazione che abbiamo trattato in precedenza non si applicano agli insiemi
3403 allocati dinamicamente, per i quali dovranno sono state definite altrettante
3404 macro equivalenti contraddistinte dal suffisso \texttt{\_S}, che effettuano le
3405 stesse operazioni, ma richiedono in più un argomento
3406 aggiuntivo \param{setsize} che deve essere assegnato al valore ottenuto con
3407 \macro{CPU\_ALLOC\_SIZE}. Questo stesso valore deve essere usato per l'omonimo
3408 argomento delle funzioni \func{sched\_setaffinity} o \func{sched\_getaffinity}
3409 quando si vuole usare per l'argomento che indica la maschera di affinità un
3410 insieme di processori allocato dinamicamente.
3412 \index{insieme~di~processori|)}
3414 A meno di non aver utilizzato \func{sched\_setaffinity}, in condizioni
3415 ordinarie la maschera di affinità di un processo è preimpostata dal sistema in
3416 modo che esso possa essere eseguito su qualunque processore. Se ne può
3417 comunque ottenere il valore corrente usando la funzione di sistema
3418 \funcd{sched\_getaffinity}, il cui prototipo è:
3422 \fdecl{int sched\_getaffinity (pid\_t pid, size\_t setsize,
3424 \fdesc{Legge la maschera di affinità di un processo.}
3426 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
3427 caso \var{errno} assumerà uno dei valori:
3429 \item[\errcode{EINVAL}] \param{setsize} è più piccolo delle dimensioni
3430 della maschera di affinità usata dal kernel.
3431 \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
3433 ed inoltre anche \errval{EFAULT} nel suo significato generico.}
3436 La funzione restituirà all'indirizzo specificato da \param{mask} il valore
3437 della maschera di affinità del processo indicato dall'argomento \param{pid}
3438 (al solito un valore nullo indica il processo corrente) così da poterla
3439 riutilizzare per una successiva reimpostazione.
3441 È chiaro che queste funzioni per la gestione dell'affinità hanno significato
3442 soltanto su un sistema multiprocessore, esse possono comunque essere
3443 utilizzate anche in un sistema con un processore singolo, nel qual caso però
3444 non avranno alcun risultato effettivo.
3446 \itindend{scheduler}
3447 \itindend{CPU~affinity}
3450 \subsection{Le priorità per le operazioni di I/O}
3451 \label{sec:io_priority}
3453 A lungo l'unica priorità usata per i processi è stata quella relativa
3454 all'assegnazione dell'uso del processore. Ma il processore non è l'unica
3455 risorsa che i processi devono contendersi, un'altra, altrettanto importante
3456 per le prestazioni, è quella dell'accesso a disco. Per questo motivo nello
3457 sviluppo del kernel sono stati introdotti diversi \textit{I/O scheduler} in
3458 grado di distribuire in maniera opportuna questa risorsa ai vari processi.
3460 Fino al kernel 2.6.17 era possibile soltanto differenziare le politiche
3461 generali di gestione, scegliendo di usare un diverso \textit{I/O scheduler}. A
3462 partire da questa versione, con l'introduzione dello \textit{scheduler} CFQ
3463 (\textit{Completely Fair Queuing}) è divenuto possibile, qualora si usi questo
3464 \textit{scheduler}, impostare anche delle diverse priorità di accesso per i
3465 singoli processi.\footnote{al momento (kernel 2.6.31), le priorità di I/O sono
3466 disponibili soltanto per questo \textit{scheduler}.}
3468 La scelta di uno \textit{scheduler} di I/O si può fare in maniera generica per
3469 tutto il sistema all'avvio del kernel con il parametro di avvio
3470 \texttt{elevator},\footnote{per la trattazione dei parametri di avvio del
3471 kernel si rimanda al solito alla sez.~5.3 di \cite{AGL}.} cui assegnare il
3472 nome dello \textit{scheduler}, ma se ne può anche indicare uno specifico per
3473 l'accesso al singolo disco scrivendo nel file
3474 \texttt{/sys/block/\textit{<dev>}/queue/scheduler} (dove
3475 \texttt{\textit{<dev>}} è il nome del dispositivo associato al disco).
3477 Gli \textit{scheduler} disponibili sono mostrati dal contenuto dello stesso
3478 file che riporta fra parentesi quadre quello attivo, il default in tutti i
3479 kernel recenti è proprio il \texttt{cfq}, nome con cui si indica appunto lo
3480 \textit{scheduler} CFQ, che supporta le priorità. Per i dettagli sulle
3481 caratteristiche specifiche degli altri \textit{scheduler}, la cui discussione
3482 attiene a problematiche di ambito sistemistico, si consulti la documentazione
3483 nella directory \texttt{Documentation/block/} dei sorgenti del kernel.
3485 Una volta che si sia impostato lo \textit{scheduler} CFQ ci sono due
3486 specifiche \textit{system call}, specifiche di Linux, che consentono di
3487 leggere ed impostare le priorità di I/O.\footnote{se usate in corrispondenza
3488 ad uno \textit{scheduler} diverso il loro utilizzo non avrà alcun effetto.}
3489 Dato che non esiste una interfaccia diretta nella \acr{glibc} per queste due
3490 funzioni\footnote{almeno al momento della scrittura di questa sezione, con la
3491 versione 2.11 della \acr{glibc}.} occorrerà invocarle tramite la funzione
3492 \func{syscall} (come illustrato in sez.~\ref{sec:proc_syscall}). Le due
3493 \textit{system call} sono \funcd{ioprio\_get} ed \funcd{ioprio\_set}; i
3494 rispettivi prototipi sono:
3497 \fhead{linux/ioprio.h}
3498 \fdecl{int ioprio\_get(int which, int who)}
3499 \fdesc{Legge la priorità di I/O di un processo.}
3500 \fdecl{int ioprio\_set(int which, int who, int ioprio)}
3501 \fdesc{Imposta la priorità di I/O di un processo.}
3503 {Le funzioni ritornano rispettivamente un intero positivo o 0 in caso di
3504 successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
3507 \item[\errcode{EINVAL}] i valori di \param{which} o di \param{ioprio} non
3509 \item[\errcode{EPERM}] non si hanno i privilegi per eseguire
3510 l'impostazione (solo per \func{ioprio\_set}).
3511 \item[\errcode{ESRCH}] non esiste un processo corrispondente alle indicazioni.
3515 Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione
3516 dei due argomenti \param{which} e \param{who} che hanno lo stesso significato
3517 già visto per gli omonimi argomenti di \func{getpriority} e
3518 \func{setpriority}. Anche in questo caso si deve specificare il valore di
3519 \param{which} tramite le opportune costanti riportate in
3520 tab.~\ref{tab:ioprio_args} che consentono di indicare un singolo processo, i
3521 processi di un \textit{process group} (vedi sez.~\ref{sec:sess_proc_group}) o
3522 tutti i processi di un utente.
3527 \begin{tabular}[c]{|c|c|l|}
3529 \param{which} & \param{who} & \textbf{Significato} \\
3532 \constd{IPRIO\_WHO\_PROCESS} & \type{pid\_t} & processo\\
3533 \constd{IPRIO\_WHO\_PRGR} & \type{pid\_t} & \textit{process group}\\
3534 \constd{IPRIO\_WHO\_USER} & \type{uid\_t} & utente\\
3537 \caption{Legenda del valore dell'argomento \param{which} e del tipo
3538 dell'argomento \param{who} delle funzioni \func{ioprio\_get} e
3539 \func{ioprio\_set} per le tre possibili scelte.}
3540 \label{tab:ioprio_args}
3543 In caso di successo \func{ioprio\_get} restituisce un intero positivo che
3544 esprime il valore della priorità di I/O, questo valore è una maschera binaria
3545 composta da due parti, una che esprime la \textsl{classe} di
3546 \textit{scheduling} di I/O del processo, l'altra che esprime, quando la classe
3547 di \textit{scheduling} lo prevede, la priorità del processo all'interno della
3548 classe stessa. Questo stesso formato viene utilizzato per indicare il valore
3549 della priorità da impostare con l'argomento \param{ioprio} di
3555 \begin{tabular}[c]{|l|p{8cm}|}
3557 \textbf{Macro} & \textbf{Significato}\\
3560 \macrod{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
3561 & Dato il valore di una priorità come
3562 restituito da \func{ioprio\_get} estrae il
3563 valore della classe.\\
3564 \macrod{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
3565 & Dato il valore di una priorità come
3566 restituito da \func{ioprio\_get} estrae il
3567 valore della priorità.\\
3568 \macrod{IOPRIO\_PRIO\_VALUE}\texttt{(\textit{class},\textit{prio})}
3569 & Dato un valore di priorità ed una classe
3570 ottiene il valore numerico da passare a
3571 \func{ioprio\_set}.\\
3574 \caption{Le macro per la gestione dei valori numerici .}
3575 \label{tab:IOsched_class_macro}
3579 Per la gestione dei valori che esprimono le priorità di I/O sono state
3580 definite delle opportune macro di preprocessore, riportate in
3581 tab.~\ref{tab:IOsched_class_macro}. I valori delle priorità si ottengono o si
3582 impostano usando queste macro. Le prime due si usano con il valore restituito
3583 da \func{ioprio\_get} e per ottenere rispettivamente la classe di
3584 \textit{scheduling}\footnote{restituita dalla macro con i valori di
3585 tab.~\ref{tab:IOsched_class}.} e l'eventuale valore della priorità. La terza
3586 macro viene invece usata per creare un valore di priorità da usare come
3587 argomento di \func{ioprio\_set} per eseguire una impostazione.
3589 Le classi di \textit{scheduling} previste dallo \textit{scheduler} CFQ sono
3590 tre, e ricalcano tre diverse modalità di distribuzione delle risorse, analoghe
3591 a quelle già adottate anche nel funzionamento dello \textit{scheduler} del
3592 processore. Ciascuna di esse è identificata tramite una opportuna costante,
3593 secondo quanto riportato in tab.~\ref{tab:IOsched_class}.
3598 \begin{tabular}[c]{|l|l|}
3600 \textbf{Classe} & \textbf{Significato} \\
3603 \const{IOPRIO\_CLASS\_RT} & \textit{Scheduling} di I/O
3604 \textit{real-time}.\\
3605 \const{IOPRIO\_CLASS\_BE} & \textit{Scheduling} di I/O ordinario.\\
3606 \const{IOPRIO\_CLASS\_IDLE}& \textit{Scheduling} di I/O di priorità
3610 \caption{Costanti che identificano le classi di \textit{scheduling} di I/O.}
3611 \label{tab:IOsched_class}
3614 La classe di priorità più bassa è \constd{IOPRIO\_CLASS\_IDLE}; i processi in
3615 questa classe riescono ad accedere a disco soltanto quando nessun altro
3616 processo richiede l'accesso. Occorre pertanto usarla con molta attenzione,
3617 perché un processo in questa classe può venire completamente bloccato quando
3618 ci sono altri processi in una qualunque delle altre due classi che stanno
3619 accedendo al disco. Quando si usa questa classe non ha senso indicare un
3620 valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la
3621 priorità è identica, la minima possibile, per tutti i processi che la usano.
3623 La seconda classe di priorità di I/O è \constd{IOPRIO\_CLASS\_BE} (il nome sta
3624 per \textit{best-effort}), che è quella usata ordinariamente da tutti
3625 processi. In questo caso esistono priorità diverse che consentono di
3626 assegnazione di una maggiore banda passante nell'accesso a disco ad un
3627 processo rispetto agli altri, con meccanismo simile a quello dei valori di
3628 \textit{nice} in cui si evita che un processo a priorità più alta possa
3629 bloccare indefinitamente quelli a priorità più bassa. In questo caso però le
3630 diverse priorità sono soltanto otto, indicate da un valore numerico fra 0 e 7
3631 e come per \textit{nice} anche in questo caso un valore più basso indica una
3634 Infine la classe di priorità di I/O \textit{real-time}
3635 \constd{IOPRIO\_CLASS\_RT} ricalca le omonime priorità di processore: un
3636 processo in questa classe ha sempre la precedenza nell'accesso a disco
3637 rispetto a tutti i processi delle altre classi e di un processo nella stessa
3638 classe ma con priorità inferiore, ed è pertanto in grado di bloccare
3639 completamente tutti gli altri. Anche in questo caso ci sono 8 priorità diverse
3640 con un valore numerico fra 0 e 7, con una priorità più elevata per valori più
3643 In generale nel funzionamento ordinario la priorità di I/O di un processo
3644 viene impostata in maniera automatica nella classe \const{IOPRIO\_CLASS\_BE}
3645 con un valore ottenuto a partire dal corrispondente valore di \textit{nice}
3646 tramite la formula: $\mathtt{\mathit{prio}}=(\mathtt{\mathit{nice}}+20)/5$. Un
3647 utente ordinario può modificare con \func{ioprio\_set} soltanto le priorità
3648 dei processi che gli appartengono,\footnote{per la modifica delle priorità di
3649 altri processi occorrono privilegi amministrativi, ed in particolare la
3650 capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
3651 cioè quelli il cui \ids{UID} reale corrisponde all'\ids{UID} reale o effettivo
3652 del chiamante. Data la possibilità di ottenere un blocco totale del sistema,
3653 solo l'amministratore\footnote{o un processo con la capacità
3654 \const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
3655 impostare un processo ad una priorità di I/O nella classe
3656 \const{IOPRIO\_CLASS\_RT}, lo stesso privilegio era richiesto anche per la
3657 classe \const{IOPRIO\_CLASS\_IDLE} fino al kernel 2.6.24, ma dato che in
3658 questo caso non ci sono effetti sugli altri processi questo limite è stato
3659 rimosso a partire dal kernel 2.6.25.
3661 %TODO verificare http://lwn.net/Articles/355987/
3663 \section{Problematiche di programmazione \textit{multitasking}}
3664 \label{sec:proc_multi_prog}
3666 Benché i processi siano strutturati in modo da apparire il più possibile come
3667 indipendenti l'uno dall'altro, nella programmazione in un sistema
3668 \textit{multitasking} occorre tenere conto di una serie di problematiche che
3669 normalmente non esistono quando si ha a che fare con un sistema in cui viene
3670 eseguito un solo programma alla volta.
3672 Per questo motivo, essendo questo argomento di carattere generale, ci è parso
3673 opportuno introdurre sinteticamente queste problematiche, che ritroveremo a
3674 più riprese in capitoli successivi, in questa sezione conclusiva del capitolo
3675 in cui abbiamo affrontato la gestione dei processi, sottolineando come esse
3676 diventino cogenti quando invece si usano i \textit{thread}.
3679 \subsection{Le operazioni atomiche}
3680 \label{sec:proc_atom_oper}
3682 La nozione di \textsl{operazione atomica} deriva dal significato greco della
3683 parola atomo, cioè indivisibile; si dice infatti che un'operazione è atomica
3684 quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
3685 che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
3686 di interruzione in una fase intermedia.
3688 In un ambiente \textit{multitasking} il concetto è essenziale, dato che un
3689 processo può essere interrotto in qualunque momento dal kernel che mette in
3690 esecuzione un altro processo o dalla ricezione di un segnale. Occorre pertanto
3691 essere accorti nei confronti delle possibili \textit{race condition} (vedi
3692 sez.~\ref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase
3693 in cui non erano ancora state completate.
3695 Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
3696 occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
3697 fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
3698 cap.~\ref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
3699 sez.~\ref{sec:file_shared_access}). In questi casi in genere l'uso delle
3700 appropriate funzioni di libreria per compiere le operazioni necessarie è
3701 garanzia sufficiente di atomicità in quanto le \textit{system call} con cui
3702 esse sono realizzate non possono essere interrotte (o subire interferenze
3703 pericolose) da altri processi.
3705 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
3706 stesso processo, e pure alcune \textit{system call}, possono essere interrotti
3707 in qualunque momento, e le operazioni di un eventuale \textit{signal handler}
3708 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
3709 il solo accesso o l'assegnazione di una variabile possono non essere più
3710 operazioni atomiche (torneremo su questi aspetti in
3711 sez.~\ref{sec:sig_adv_control}).
3713 Qualora invece si usino i \textit{thread}, in cui lo spazio degli indirizzi è
3714 condiviso, il problema è sempre presente, perché qualunque \textit{thread} può
3715 interromperne un altro in qualunque momento e l'atomicità di qualunque
3716 operazione è messa in discussione, per cui l'assenza di eventuali \textit{race
3717 condition} (vedi sez.~\ref{sec:proc_race_cond}) deve essere sempre
3718 verificata nei minimi dettagli.
3720 In questo caso il sistema provvede un tipo di dato, il \typed{sig\_atomic\_t},
3721 il cui accesso è assicurato essere atomico. In pratica comunque si può
3722 assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
3723 \ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
3724 atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
3725 maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
3726 le strutture di dati. In tutti questi casi è anche opportuno marcare come
3727 \dirct{volatile} le variabili che possono essere interessate ad accesso
3728 condiviso, onde evitare problemi con le ottimizzazioni del codice.
3732 \subsection{Le \textit{race condition} ed i \textit{deadlock}}
3733 \label{sec:proc_race_cond}
3735 \itindbeg{race~condition}
3737 Si definiscono \textit{race condition} tutte quelle situazioni in cui processi
3738 diversi operano su una risorsa comune, ed in cui il risultato viene a
3739 dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso
3740 tipico è quello di un'operazione che viene eseguita da un processo in più
3741 passi, e può essere compromessa dall'intervento di un altro processo che
3742 accede alla stessa risorsa quando ancora non tutti i passi sono stati
3745 Dato che in un sistema \textit{multitasking} ogni processo può essere
3746 interrotto in qualunque momento per farne subentrare un altro in esecuzione,
3747 niente può assicurare un preciso ordine di esecuzione fra processi diversi o
3748 che una sezione di un programma possa essere eseguita senza interruzioni da
3749 parte di altri. Queste situazioni comportano pertanto errori estremamente
3750 subdoli e difficili da tracciare, in quanto nella maggior parte dei casi tutto
3751 funzionerà regolarmente, e solo occasionalmente si avranno degli errori.
3753 Per questo occorre essere ben consapevoli di queste problematiche, e del fatto
3754 che l'unico modo per evitarle è quello di riconoscerle come tali e prendere
3755 gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di
3756 \textit{race condition} si hanno quando diversi processi accedono allo stesso
3757 file, o nell'accesso a meccanismi di intercomunicazione come la memoria
3760 \index{sezione~critica|(}
3762 In questi casi, se non si dispone della possibilità di eseguire atomicamente
3763 le operazioni necessarie, occorre che quelle parti di codice in cui si
3764 compiono le operazioni sulle risorse condivise, quelle che in genere vengono
3765 denominate ``\textsl{sezioni critiche}'' del programma, siano opportunamente
3766 protette da meccanismi di sincronizzazione (vedremo alcune problematiche di
3767 questo tipo in cap.~\ref{cha:IPC}).
3769 \index{sezione~critica|)}
3771 Nel caso dei \textit{thread} invece la situazione è molto più delicata e
3772 sostanzialmente qualunque accesso in memoria (a buffer, variabili o altro) può
3773 essere soggetto a \textit{race condition} dato potrebbe essere interrotto in
3774 qualunque momento da un altro \textit{thread}. In tal caso occorre pianificare
3775 con estrema attenzione l'uso delle variabili ed utilizzare i vari meccanismi
3776 di sincronizzazione che anche in questo caso sono disponibili (torneremo su
3777 queste problematiche di questo tipo in cap.~\ref{sec:pthread_sync})
3781 Un caso particolare di \textit{race condition} sono poi i cosiddetti
3782 \textit{deadlock} (traducibile in \textsl{condizione di stallo}), che
3783 particolarmente gravi in quanto comportano spesso il blocco completo di un
3784 servizio, e non il fallimento di una singola operazione. Per definizione un
3785 \textit{deadlock} è una situazione in cui due o più processi non sono più in
3786 grado di proseguire perché ciascuno aspetta il risultato di una operazione che
3787 dovrebbe essere eseguita dall'altro.
3789 L'esempio tipico di una situazione che può condurre ad un
3790 \textit{deadlock} è quello in cui un flag di
3791 ``\textsl{occupazione}'' viene rilasciato da un evento asincrono (come un
3792 segnale o un altro processo) fra il momento in cui lo si è controllato
3793 (trovandolo occupato) e la successiva operazione di attesa per lo sblocco. In
3794 questo caso, dato che l'evento di sblocco del flag è avvenuto senza che ce ne
3795 accorgessimo proprio fra il controllo e la messa in attesa, quest'ultima
3796 diventerà perpetua (da cui il nome di \textit{deadlock}).
3798 In tutti questi casi è di fondamentale importanza il concetto di atomicità
3799 visto in sez.~\ref{sec:proc_atom_oper}; questi problemi infatti possono essere
3800 risolti soltanto assicurandosi, quando essa sia richiesta, che sia possibile
3801 eseguire in maniera atomica le operazioni necessarie.
3803 \itindend{race~condition}
3807 \subsection{Le funzioni rientranti}
3808 \label{sec:proc_reentrant}
3810 \index{funzioni!rientranti|(}
3812 Si dice \textsl{rientrante} una funzione che può essere interrotta in
3813 qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
3814 un altro \textit{thread} di esecuzione senza che questo comporti nessun
3815 problema nell'esecuzione della stessa. La problematica è comune nella
3816 programmazione con i \textit{thread}, ma si hanno gli stessi problemi quando
3817 si vogliono chiamare delle funzioni all'interno dei gestori dei segnali.
3819 Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
3820 queste infatti vengono allocate nello \textit{stack}, ed un'altra invocazione
3821 non fa altro che allocarne un'altra copia. Una funzione può non essere
3822 rientrante quando opera su memoria che non è nello \textit{stack}. Ad esempio
3823 una funzione non è mai rientrante se usa una variabile globale o statica.
3825 Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
3826 cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
3827 ogni volta e ritornato indietro la funzione può essere rientrante, se invece
3828 esso viene individuato dalla funzione stessa due chiamate alla stessa funzione
3829 potranno interferire quando entrambe faranno riferimento allo stesso oggetto.
3830 Allo stesso modo una funzione può non essere rientrante se usa e modifica un
3831 oggetto che le viene fornito dal chiamante: due chiamate possono interferire
3832 se viene passato lo stesso oggetto; in tutti questi casi occorre molta cura da
3833 parte del programmatore.
3835 In genere le funzioni di libreria non sono rientranti, molte di esse ad
3836 esempio utilizzano variabili statiche, la \acr{glibc} però mette a
3837 disposizione due macro di compilatore, \macro{\_REENTRANT} e
3838 \macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
3839 varie funzioni di libreria, che sono identificate aggiungendo il suffisso
3840 \code{\_r} al nome della versione normale.
3842 \index{funzioni!rientranti|)}
3845 % LocalWords: multitasking like VMS child process identifier pid sez shell fig
3846 % LocalWords: parent kernel init pstree keventd kswapd table struct linux call
3847 % LocalWords: nell'header scheduler system interrupt timer HZ asm Hertz clock
3848 % LocalWords: l'alpha tick fork wait waitpid exit exec image glibc int pgid ps
3849 % LocalWords: sid thread Ingo Molnar ppid getpid getppid sys unistd LD threads
3850 % LocalWords: void tempnam pathname sibling cap errno EAGAIN ENOMEM context
3851 % LocalWords: stack read only copy write tab client spawn forktest sleep PATH
3852 % LocalWords: source LIBRARY scheduling race condition printf descriptor dup
3853 % LocalWords: close group session tms lock vfork execve BSD stream main abort
3854 % LocalWords: SIGABRT SIGCHLD SIGHUP foreground SIGCONT termination signal ANY
3855 % LocalWords: handler kill EINTR POSIX options WNOHANG ECHILD option WUNTRACED
3856 % LocalWords: dump bits rusage getrusage heap const filename argv envp EACCES
3857 % LocalWords: filesystem noexec EPERM suid sgid root nosuid ENOEXEC ENOENT ELF
3858 % LocalWords: ETXTBSY EINVAL ELIBBAD BIG EFAULT EIO ENAMETOOLONG ELOOP ENOTDIR
3859 % LocalWords: ENFILE EMFILE argc execl path execv execle execlp execvp vector
3860 % LocalWords: list environ NULL umask utime cutime ustime fcntl linker Posix
3861 % LocalWords: opendir libc interpreter FreeBSD capabilities mandatory access
3862 % LocalWords: control MAC SELinux security modules LSM superuser uid gid saved
3863 % LocalWords: effective euid egid dell' fsuid fsgid getuid geteuid getgid SVr
3864 % LocalWords: getegid IDS NFS setuid setgid all' logout utmp screen xterm TODO
3865 % LocalWords: setreuid setregid FIXME ruid rgid seteuid setegid setresuid size
3866 % LocalWords: setresgid getresuid getresgid value result argument setfsuid DAC
3867 % LocalWords: setfsgid NGROUPS sysconf getgroups getgrouplist groups ngroups
3868 % LocalWords: setgroups initgroups patch LIDS CHOWN OVERRIDE Discrectionary
3869 % LocalWords: SEARCH chattr sticky NOATIME socket domain immutable append mmap
3870 % LocalWords: broadcast multicast multicasting memory locking mlock mlockall
3871 % LocalWords: shmctl ioperm iopl chroot ptrace accounting swap reboot hangup
3872 % LocalWords: vhangup mknod lease permitted inherited inheritable bounding AND
3873 % LocalWords: capability capget capset header ESRCH undef version obj clear PT
3874 % LocalWords: pag ssize length proc capgetp preemptive cache runnable idled
3875 % LocalWords: SIGSTOP soft slice nice niceness counter which SC switch side
3876 % LocalWords: getpriority who setpriority RTLinux RTAI Adeos fault FIFO COUNT
3877 % LocalWords: yield Robin setscheduler policy param OTHER priority setparam to
3878 % LocalWords: min getparam getscheduler interval robin ENOSYS fifo ping long
3879 % LocalWords: affinity setaffinity unsigned mask cpu NUMA CLR ISSET SETSIZE RR
3880 % LocalWords: getaffinity assembler deadlock REENTRANT SAFE tgz MYPGRP l'OR rr
3881 % LocalWords: WIFEXITED WEXITSTATUS WIFSIGNALED WTERMSIG WCOREDUMP WIFSTOPPED
3882 % LocalWords: WSTOPSIG opt char INTERP arg SIG IGN DFL mascheck grp FOWNER RAW
3883 % LocalWords: FSETID SETPCAP BIND SERVICE ADMIN PACKET IPC OWNER MODULE RAWIO
3884 % LocalWords: PACCT RESOURCE TTY CONFIG SETFCAP hdrp datap libcap lcap text tp
3885 % LocalWords: get ncap caps CapInh CapPrm fffffeff CapEff getcap STAT dall'I
3886 % LocalWords: inc PRIO SUSv PRGR prio SysV SunOS Ultrix sched timespec len sig
3887 % LocalWords: cpusetsize cpuset atomic tickless redirezione WCONTINUED stopped
3888 % LocalWords: waitid NOCLDSTOP ENOCHLD WIFCONTINUED ifdef endif idtype siginfo
3889 % LocalWords: infop ALL WEXITED WSTOPPED WNOWAIT signo CLD EXITED KILLED page
3890 % LocalWords: CONTINUED sources forking Spawned successfully executing exiting
3891 % LocalWords: next cat for COMMAND pts bash defunct TRAPPED DUMPED PR effects
3892 % LocalWords: SIGKILL static RLIMIT preemption PREEMPT VOLUNTARY IDLE RTPRIO
3893 % LocalWords: completely fair compat uniform CFQ queuing elevator dev cfq RT
3894 % LocalWords: documentation block syscall ioprio IPRIO CLASS class best effort
3895 % LocalWords: refresh semop dnotify MADV DONTFORK prctl WCLONE WALL big mount
3896 % LocalWords: WNOTHREAD DUMPABLE KEEPCAPS IRIX CAPBSET endianness endian flags
3897 % LocalWords: little PPC PowerPC FPEMU NOPRINT SIGFPE FPEXC point FP SW malloc
3898 % LocalWords: exception EXC ENABLE OVF overflow UND underflow RES INV DISABLED
3899 % LocalWords: NONRECOV ASYNC KEEP securebits NAME NUL PDEATHSIG SECCOMP VM FS
3900 % LocalWords: secure computing sigreturn TIMING STATISTICAL TSC MCE conditions
3901 % LocalWords: timestamp Stamp SIGSEGV UNALIGN SIGBUS MCEERR AO failure early
3902 % LocalWords: namespace vsyscall SETTID FILES NEWIPC NEWNET NEWNS NEWPID ptid
3903 % LocalWords: NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID panic
3904 % LocalWords: loader EISDIR SIGTRAP uninterrutible killable EQUAL sizeof XOR
3905 % LocalWords: destset srcset ALLOC num cpus setsize emacs pager getty TID
3906 % LocalWords: reaper SUBREAPER Library futex klogd named rpc statd NPROC
3907 % LocalWords: EACCESS EBADF EBUSY ENXIO EOPNOTSUPP DISABLE tracer Yama
3909 %%% Local Variables:
3911 %%% TeX-master: "gapil"