\chapter{La gestione dei processi}
\label{cha:process_handling}
-Come accennato nell'introduzione in un sistema Unix tutte le operazioni
+Come accennato nell'introduzione in un sistema unix-like tutte le operazioni
vengono svolte tramite opportuni processi. In sostanza questi ultimi vengono
a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
ambiente multitasking.
-\section{Introduzione}
-\label{sec:proc_gen}
+\section{Le funzioni di base}% della gestione dei processi}
+\label{sec:proc_handling}
-Inizieremo con un'introduzione generale ai concetti che stanno alla base della
-gestione dei processi in un sistema unix-like. Introdurremo in questa sezione
-l'architettura della gestione dei processi e le sue principali
-caratteristiche, dando una panoramica sull'uso delle principali funzioni di
-gestione.
+In questa sezione tratteremo le problematiche della gestione dei processi
+all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con una
+panoramica dell'architettura dei processi, tratteremo poi le funzioni
+elementari che permettono di leggerne gli identificatori, per poi passare alla
+spiegazione delle funzioni base che si usano per la creazione e la
+terminazione dei processi, e per la messa in esecuzione degli altri programmi.
\subsection{L'architettura della gestione dei processi}
\label{sec:proc_hierarchy}
-A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
-generazione di nuovi processi è un'operazione privilegiata) una delle
-caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
-qualunque processo può a sua volta generarne altri, detti processi figli
-(\textit{child process}). Ogni processo è identificato presso il sistema da un
-numero univoco, il cosiddetto \textit{process identifier} o, più brevemente,
-\acr{pid}, assegnato in forma progressiva (vedi sez.~\ref{sec:proc_pid})
-quando il processo viene creato.
+A differenza di quanto avviene in altri sistemi, ad esempio nel VMS la
+generazione di nuovi processi è un'operazione privilegiata, una delle
+caratteristiche fondanti di Unix, che esamineremo in dettaglio più avanti, è
+che qualunque processo può a sua volta generarne altri. Ogni processo è
+identificato presso il sistema da un numero univoco, il cosiddetto
+\textit{process identifier} o, più brevemente, \acr{pid}, assegnato in forma
+progressiva (vedi sez.~\ref{sec:proc_pid}) quando il processo viene creato.
-Una seconda caratteristica di un sistema Unix è che la generazione di un
+Una seconda caratteristica di un sistema unix-like è che la generazione di un
processo è un'operazione separata rispetto al lancio di un programma. In
genere la sequenza è sempre quella di creare un nuovo processo, il quale
eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
quello che fa la shell quando mette in esecuzione il programma che gli
indichiamo nella linea di comando.
-Una terza caratteristica è che ogni processo è sempre stato generato da un
-altro, che viene chiamato processo padre (\textit{parent process}). Questo
-vale per tutti i processi, con una sola eccezione: dato che ci deve essere un
-punto di partenza esiste un processo speciale (che normalmente è
-\cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
-di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
-\acr{pid} uguale a 1 e non è figlio di nessun altro processo.
+Una terza caratteristica del sistema è che ogni processo è sempre stato
+generato da un altro processo, il processo generato viene chiamato
+\textit{processo figlio} (\textit{child process}) mentre quello che lo ha
+viene chiamato \textsl{processo padre} (\textit{parent process}). Questo vale
+per tutti i processi, con una sola eccezione, dato che ci deve essere un punto
+di partenza esiste un processo speciale (che normalmente è \cmd{/sbin/init}),
+che come abbiamo accennato in sez.~\ref{sec:intro_kern_and_sys} viene lanciato
+dal kernel alla conclusione della fase di avvio. Essendo questo il primo
+processo lanciato dal sistema ha sempre il \acr{pid} uguale a 1 e non è figlio
+di nessun altro processo.
Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
partire tutti gli altri processi necessari al funzionamento del sistema,
struttura del sistema comunque consente di lanciare al posto di \cmd{init}
qualunque altro programma, e in casi di emergenza (ad esempio se il file di
\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
-posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
+posto.\footnote{la cosa si fa passando la riga \cmd{init=/bin/sh} come
+ parametro di avvio del kernel, l'argomento è di natura amministrativa e
+ trattato in sez.~5.3 di \cite{AGL}.}
\begin{figure}[!htb]
\footnotesize
-\begin{verbatim}
+\begin{Command}
[piccardi@gont piccardi]$ pstree -n
+\end{Command}
+\begin{Terminal}
init-+-keventd
|-kapm-idled
|-kreiserfsd
|-5*[getty]
|-snort
`-wwwoffled
-\end{verbatim} %$
+\end{Terminal}
+%$
\caption{L'albero dei processi, così come riportato dal comando
\cmd{pstree}.}
\label{fig:proc_tree}
\end{figure}
Dato che tutti i processi attivi nel sistema sono comunque generati da
-\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
- vero, in Linux ci sono alcuni processi speciali che pur comparendo come
- figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
- direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, ecc.).} si
-possono classificare i processi con la relazione padre/figlio in
-un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
-organizzati in un albero di directory (si veda
-sez.~\ref{sec:file_organization}); in fig.~\ref{fig:proc_tree} si è mostrato il
-risultato del comando \cmd{pstree} che permette di visualizzare questa
-struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
-processi.
+\cmd{init} o da uno dei suoi figli si possono classificare i processi con la
+relazione padre/figlio in un'organizzazione gerarchica ad albero. In
+fig.~\ref{fig:proc_tree} si è mostrato il risultato del comando \cmd{pstree}
+che permette di visualizzare questa struttura, alla cui base c'è \cmd{init}
+che è progenitore di tutti gli altri processi.\footnote{in realtà questo non è
+ del tutto vero, in Linux, specialmente nelle versioni più recenti del
+ kernel, ci sono alcuni processi speciali (come \cmd{keventd}, \cmd{kswapd},
+ ecc.) che pur comparendo nei comandi come figli di \cmd{init}, o con
+ \acr{pid} successivi ad uno, sono in realtà processi interni al kernel e che
+ non rientrano in questa classificazione.}
Il kernel mantiene una tabella dei processi attivi, la cosiddetta
-\itindex{process~table} \textit{process table}; per ciascun processo viene
-mantenuta una voce, costituita da una struttura \struct{task\_struct}, nella
-tabella dei processi che contiene tutte le informazioni rilevanti per quel
-processo. Tutte le strutture usate a questo scopo sono dichiarate nell'header
-file \file{linux/sched.h}, ed uno schema semplificato, che riporta la
-struttura delle principali informazioni contenute nella \struct{task\_struct}
-(che in seguito incontreremo a più riprese), è mostrato in
-fig.~\ref{fig:proc_task_struct}.
-
-\begin{figure}[htb]
- \centering
- \includegraphics[width=14cm]{img/task_struct}
+\itindex{process~table} \textit{process table}. Per ciascun processo viene
+mantenuta una voce in questa tabella, costituita da una struttura
+\struct{task\_struct}, che contiene tutte le informazioni rilevanti per quel
+processo. Tutte le strutture usate a questo scopo sono dichiarate
+nell'\textit{header file} \file{linux/sched.h}, ed uno schema semplificato,
+che riporta la struttura delle principali informazioni contenute nella
+\struct{task\_struct} (che in seguito incontreremo a più riprese), è mostrato
+in fig.~\ref{fig:proc_task_struct}.
+
+\begin{figure}[!htb]
+ \centering \includegraphics[width=14cm]{img/task_struct}
\caption{Schema semplificato dell'architettura delle strutture usate dal
kernel nella gestione dei processi.}
\label{fig:proc_task_struct}
Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
\textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
-eseguito ad ogni system call ed ad ogni interrupt,\footnote{più in una serie
- di altre occasioni.} ma può essere anche attivato esplicitamente. Il timer
-di sistema provvede comunque a che esso sia invocato periodicamente; generando
-un interrupt periodico secondo la frequenza specificata dalla costante
+eseguito ad ogni \textit{system call} ed ad ogni interrupt e in una serie di
+altre occasioni, ma può essere anche attivato esplicitamente. Il timer di
+sistema provvede comunque a che esso sia invocato periodicamente; generando un
+interrupt periodico secondo la frequenza specificata dalla costante
\const{HZ},\footnote{fino al kernel 2.4 il valore di \const{HZ} era 100 su
tutte le architetture tranne l'alpha, per cui era 1000, nel 2.6 è stato
portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di
refresh della televisione); occorre fare attenzione a non confondere questo
valore con quello dei \itindex{clock~tick} \textit{clock tick} (vedi
sez.~\ref{sec:sys_unix_time}).} definita in \file{asm/param.h}, ed il cui
-valore è espresso in Hertz.\footnote{a partire dal kernel 2.6.21 è stato
- introdotto (a cura di Ingo Molnar) un meccanismo completamente diverso,
- detto \textit{tickless}, in cui non c'è più una interruzione periodica con
- frequenza prefissata, ma ad ogni chiamata del timer viene programmata
- l'interruzione successiva sulla base di una stima; in questo modo si evita
- di dover eseguire un migliaio di interruzioni al secondo anche su macchine
- che non stanno facendo nulla, con un forte risparmio nell'uso dell'energia
- da parte del processore che può essere messo in stato di sospensione anche
- per lunghi periodi di tempo.}
-
-Ogni volta che viene eseguito, lo \itindex{scheduler} \textit{scheduler}
-effettua il calcolo delle priorità dei vari processi attivi (torneremo su
-questo in sez.~\ref{sec:proc_priority}) e stabilisce quale di essi debba
-essere posto in esecuzione fino alla successiva invocazione.
-
-
-\subsection{Una panoramica sulle funzioni fondamentali}
-\label{sec:proc_handling_intro}
-
-Tradizionalmente in un sistema unix-like i processi vengono sempre creati da
-altri processi tramite la funzione \func{fork}; il nuovo processo (che viene
-chiamato \textsl{figlio}) creato dalla \func{fork} è una copia identica del
-processo processo originale (detto \textsl{padre}), ma ha un nuovo \acr{pid} e
-viene eseguito in maniera indipendente (le differenze fra padre e figlio sono
-affrontate in dettaglio in sez.~\ref{sec:proc_fork}).
-
-Se si vuole che il processo padre si fermi fino alla conclusione del processo
-figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
-funzione \func{wait} o la funzione \func{waitpid} (si veda
-sez.~\ref{sec:proc_wait}); queste funzioni restituiscono anche un'informazione
-abbastanza limitata sulle cause della terminazione del processo figlio.
-
-Quando un processo ha concluso il suo compito o ha incontrato un errore non
-risolvibile esso può essere terminato con la funzione \func{exit} (si veda
-quanto discusso in sez.~\ref{sec:proc_conclusion}). La vita del processo però
-termina completamente solo quando la notifica della sua conclusione viene
-ricevuta dal processo padre, a quel punto tutte le risorse allocate nel
-sistema ad esso associate vengono rilasciate.
-
-Avere due processi che eseguono esattamente lo stesso codice non è molto
-utile, normalmente si genera un secondo processo per affidargli l'esecuzione
-di un compito specifico (ad esempio gestire una connessione dopo che questa è
-stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
-quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
-coi processi che è la \func{exec}.
-
-Il programma che un processo sta eseguendo si chiama immagine del processo (o
-\textit{process image}), le funzioni della famiglia \func{exec} permettono di
-caricare un altro programma da disco sostituendo quest'ultimo all'immagine
-corrente; questo fa sì che l'immagine precedente venga completamente
-cancellata. Questo significa che quando il nuovo programma termina, anche il
-processo termina, e non si può tornare alla precedente immagine.
-
-Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
-particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
-prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
-non ritorna mai (in quanto con essa viene eseguito un altro programma).
+valore è espresso in Hertz.
+A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo
+completamente diverso, detto \textit{tickless}, in cui non c'è più una
+interruzione periodica con frequenza prefissata, ma ad ogni chiamata del timer
+viene programmata l'interruzione successiva sulla base di una stima; in questo
+modo si evita di dover eseguire un migliaio di interruzioni al secondo anche
+su macchine che non stanno facendo nulla, con un forte risparmio nell'uso
+dell'energia da parte del processore che può essere messo in stato di
+sospensione anche per lunghi periodi di tempo.
-\section{Le funzioni di base}% della gestione dei processi}
-\label{sec:proc_handling}
-
-In questa sezione tratteremo le problematiche della gestione dei processi
-all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con le
-funzioni elementari che permettono di leggerne gli identificatori, per poi
-passare alla spiegazione delle funzioni base che si usano per la creazione e
-la terminazione dei processi, e per la messa in esecuzione degli altri
-programmi.
+Indipendentemente dalle motivazioni per cui questo avviene, ogni volta che
+viene eseguito lo \itindex{scheduler} \textit{scheduler} effettua il calcolo
+delle priorità dei vari processi attivi (torneremo su questo in
+sez.~\ref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
+esecuzione fino alla successiva invocazione.
\subsection{Gli identificatori dei processi}
\label{sec:proc_pid}
-Come accennato nell'introduzione, ogni processo viene identificato dal sistema
-da un numero identificativo univoco, il \textit{process ID} o \acr{pid};
-quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
+Come accennato nella sezione precedente ogni processo viene identificato dal
+sistema da un numero identificativo univoco, il \textit{process ID} o
+\acr{pid}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un
intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
\ctyp{int}).
-Il \acr{pid} viene assegnato in forma progressiva\footnote{in genere viene
- assegnato il numero successivo a quello usato per l'ultimo processo creato,
- a meno che questo numero non sia già utilizzato per un altro \acr{pid},
- \acr{pgid} o \acr{sid} (vedi sez.~\ref{sec:sess_proc_group}).} ogni volta
-che un nuovo processo viene creato, fino ad un limite che, essendo il
-\acr{pid} un numero positivo memorizzato in un intero a 16 bit, arriva ad un
-massimo di 32768. Oltre questo valore l'assegnazione riparte dal numero più
-basso disponibile a partire da un minimo di 300,\footnote{questi valori, fino
- al kernel 2.4.x, sono definiti dalla macro \const{PID\_MAX} in
- \file{threads.h} e direttamente in \file{fork.c}, con il kernel 2.5.x e la
- nuova interfaccia per i \itindex{thread} \textit{thread} creata da Ingo
- Molnar anche il meccanismo di allocazione dei \acr{pid} è stato modificato;
- il valore massimo è impostabile attraverso il file
+Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
+processo viene creato,\footnote{in genere viene assegnato il numero successivo
+ a quello usato per l'ultimo processo creato, a meno che questo numero non
+ sia già utilizzato per un altro \acr{pid}, \acr{pgid} o \acr{sid} (vedi
+ sez.~\ref{sec:sess_proc_group}).} fino ad un limite che, essendo il
+tradizionalmente il \acr{pid} un numero positivo memorizzato in un intero a 16
+bit, arriva ad un massimo di 32768. Oltre questo valore l'assegnazione
+riparte dal numero più basso disponibile a partire da un minimo di
+300,\footnote{questi valori, fino al kernel 2.4.x, erano definiti dalla macro
+ \const{PID\_MAX} nei file \file{threads.h} e \file{fork.c} dei sorgenti del
+ kernel, con il 2.6.x e la nuova interfaccia per i \itindex{thread}
+ \textit{thread} anche il meccanismo di allocazione dei \acr{pid} è stato
+ modificato ed il valore massimo è impostabile attraverso il file
\procfile{/proc/sys/kernel/pid\_max} e di default vale 32768.} che serve a
riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
Per questo motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di
\textit{parent process ID}). Questi due identificativi possono essere
ottenuti usando le due funzioni \funcd{getpid} e \funcd{getppid}, i cui
prototipi sono:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{unistd.h}
- \funcdecl{pid\_t getpid(void)}
-
- Restituisce il \acr{pid} del processo corrente.
-
- \funcdecl{pid\_t getppid(void)}
-
- Restituisce il \acr{pid} del padre del processo corrente.
-\bodydesc{Entrambe le funzioni non riportano condizioni di errore.}
-\end{functions}
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{unistd.h}
+\fdecl{pid\_t getpid(void)}
+\fdesc{Restituisce il \acr{pid} del processo corrente..}
+\fdecl{pid\_t getppid(void)}
+\fdesc{Restituisce il \acr{pid} del padre del processo corrente.}
+}
+{Entrambe le funzioni non riportano condizioni di errore.}
+\end{funcproto}
+
\noindent esempi dell'uso di queste funzioni sono riportati in
fig.~\ref{fig:proc_fork_code}, nel programma \file{ForkTest.c}.
diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
\acr{pid} per generare un \itindex{pathname} \textit{pathname} univoco, che
-non potrà essere replicato da un altro processo che usi la stessa funzione.
+non potrà essere replicato da un altro processo che usi la stessa
+funzione. Questo utilizzo però può risultare pericoloso, un \acr{pid} infatti
+è univoco solo fintanto che un processo è attivo, una volta terminato esso
+potrà essere riutilizzato da un processo completamente diverso, e di questo
+bisogna essere ben consapevoli.
Tutti i processi figli dello stesso processo padre sono detti
\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
un processo e le varie relazioni fra processi utilizzate per definire una
sessione.
-Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
-sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione), ad ogni
-processo vengono associati degli altri identificatori che vengono usati per il
-controllo di accesso. Questi servono per determinare se un processo può
-eseguire o meno le operazioni richieste, a seconda dei privilegi e
-dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
-affrontato in dettaglio in sez.~\ref{sec:proc_perms}.
+Oltre al \acr{pid} e al \acr{ppid}, e a quelli che vedremo in
+sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione, ad ogni
+processo vengono associati degli ulteriori identificatori ed in particolare
+quelli che vengono usati per il controllo di accesso. Questi servono per
+determinare se un processo può eseguire o meno le operazioni richieste, a
+seconda dei privilegi e dell'identità di chi lo ha posto in esecuzione;
+l'argomento è complesso e sarà affrontato in dettaglio in
+sez.~\ref{sec:proc_perms}.
\subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
La funzione \funcd{fork} è la funzione fondamentale della gestione dei
processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
- system call usata più comunemente da Linux per creare nuovi processi è
- \func{clone} (vedi \ref{sec:process_clone}) , anche perché a partire dalle
- \acr{glibc} 2.3.3 non viene più usata la system call originale, ma la stessa
+ \textit{system call} usata da Linux per creare nuovi processi è \func{clone}
+ (vedi \ref{sec:process_clone}), anche perché a partire dalle \acr{glibc}
+ 2.3.3 non viene più usata la \textit{system call} originale, ma la stessa
\func{fork} viene implementata tramite \func{clone}, cosa che consente una
migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
centrale tutte le volte che si devono scrivere programmi che usano il
\textit{thread} che tratteremo al cap.~\ref{cha:threads}, è in parte minore,
ma \func{fork} resta comunque la funzione principale per la creazione di
processi.} Il prototipo della funzione è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{unistd.h}
- \funcdecl{pid\_t fork(void)}
- Crea un nuovo processo.
-
- \bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
- zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
- errore; \var{errno} può assumere i valori:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{pid\_t fork(void)}
+\fdesc{Crea un nuovo processo.}
+}
+{La funzione ritorna il \acr{pid} del figlio al padre e $0$ al figlio in caso
+ di successo e $-1$ al padre senza creare il figlio per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro
processo (per allocare la tabella delle pagine e le strutture del task) o
\item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
strutture necessarie al kernel per creare il nuovo processo.
\end{errlist}}
-\end{functions}
+\end{funcproto}
Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
il processo figlio continuano ad essere eseguiti normalmente a partire
-dall'istruzione successiva alla \func{fork}; il processo figlio è però una
-copia del padre, e riceve una copia dei \index{segmento!testo} segmenti di
-testo, \itindex{stack} \textit{stack} e \index{segmento!dati} dati (vedi
+dall'istruzione successiva alla \func{fork}. Il processo figlio è una copia del
+padre, e riceve una copia dei \index{segmento!testo} segmenti di testo,
+\index{segmento!dati} dati e dello \itindex{stack} \textit{stack} (vedi
sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
-padre. Si tenga presente però che la memoria è copiata, non condivisa,
-pertanto padre e figlio vedono variabili diverse.
+padre. Si tenga presente però che la memoria è copiata e non condivisa,
+pertanto padre e figlio vedranno variabili diverse e le eventuali modifiche
+saranno totalmente indipendenti.
Per quanto riguarda la gestione della memoria, in generale il
\index{segmento!testo} segmento di testo, che è identico per i due processi, è
-condiviso e tenuto in read-only per il padre e per i figli. Per gli altri
+condiviso e tenuto in sola lettura per il padre e per i figli. Per gli altri
segmenti Linux utilizza la tecnica del \itindex{copy~on~write} \textit{copy on
- write}; questa tecnica comporta che una pagina di memoria viene
+ write}. Questa tecnica comporta che una pagina di memoria viene
effettivamente copiata per il nuovo processo solo quando ci viene effettuata
-sopra una scrittura (e si ha quindi una reale differenza fra padre e figlio).
+sopra una scrittura, e si ha quindi una reale differenza fra padre e figlio.
In questo modo si rende molto più efficiente il meccanismo della creazione di
un nuovo processo, non essendo più necessaria la copia di tutto lo spazio
degli indirizzi virtuali del padre, ma solo delle pagine di memoria che sono
ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
nel figlio è zero; in questo modo il programma può identificare se viene
eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
-\textbf{due} volte: una nel padre e una nel figlio.
+due volte, una nel padre e una nel figlio.
La scelta di questi valori di ritorno non è casuale, un processo infatti può
avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
-permette di identificare quello appena creato; al contrario un figlio ha
-sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
-\func{getppid}, vedi sez.~\ref{sec:proc_pid}) per cui si usa il valore nullo,
-che non è il \acr{pid} di nessun processo.
-
-\begin{figure}[!htb]
- \footnotesize \centering
- \begin{minipage}[c]{15cm}
- \includecodesample{listati/ForkTest.c}
- \end{minipage}
- \normalsize
- \caption{Esempio di codice per la creazione di nuovi processi.}
- \label{fig:proc_fork_code}
-\end{figure}
-
-Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
-sono già troppi processi nel sistema (il che di solito è sintomo che
-qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
-sul numero totale di processi permessi all'utente (vedi
-sez.~\ref{sec:sys_resource_limit}, ed in particolare
+permette di identificare quello appena creato. Al contrario un figlio ha
+sempre un solo padre, il cui \acr{pid} può sempre essere ottenuto con
+\func{getppid}, come spiegato in sez.~\ref{sec:proc_pid}, per cui si usa il
+valore nullo, che non è il \acr{pid} di nessun processo.
+
+Normalmente la chiamata a \func{fork} può fallire solo per due ragioni: o ci
+sono già troppi processi nel sistema, il che di solito è sintomo che
+qualcos'altro non sta andando per il verso giusto, o si è ecceduto il limite
+sul numero totale di processi permessi all'utente argomento su cui torneremo
+in sez.~\ref{sec:sys_resource_limit}, (vedi in particolare
tab.~\ref{tab:sys_rlimit_values}).
L'uso di \func{fork} avviene secondo due modalità principali; la prima è
operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
scelto di mantenere questa separazione, dato che, come per la prima modalità
d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
-aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
-seconda modalità d'uso, avere le due funzioni separate permette al figlio di
-cambiare gli attributi del processo (maschera dei segnali, redirezione
-dell'output, identificatori) prima della \func{exec}, rendendo così
-relativamente facile intervenire sulle le modalità di esecuzione del nuovo
-programma.
+aver bisogno di eseguire una \func{exec}.
+
+Inoltre, anche nel caso della seconda modalità d'uso, avere le due funzioni
+separate permette al figlio di cambiare alcune caratteristiche del processo
+(maschera dei segnali, redirezione dell'output, utente per conto del cui viene
+eseguito, e molto altro su cui torneremo in seguito) prima della \func{exec},
+rendendo così relativamente facile intervenire sulle le modalità di esecuzione
+del nuovo programma.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/ForkTest.c}
+ \end{minipage}
+ \normalsize
+ \caption{Esempio di codice per la creazione di nuovi processi.}
+ \label{fig:proc_fork_code}
+\end{figure}
In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
specificato da linea di comando, e prende anche alcune opzioni per indicare
degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
\func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
-descrizione delle opzioni); il codice completo, compresa la parte che gestisce
+descrizione delle opzioni). Il codice completo, compresa la parte che gestisce
le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
distribuito insieme agli altri sorgenti degli esempi su
-\href{http://gapil.truelite.it/gapil_source.tgz}
-{\textsf{http://gapil.truelite.it/gapil\_source.tgz}}.
+\url{http://gapil.truelite.it/gapil_source.tgz}.
Decifrato il numero di figli da creare, il ciclo principale del programma
(\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
alla conclusione del ciclo, prima di uscire, può essere specificato un altro
periodo di attesa.
-Se eseguiamo il comando\footnote{che è preceduto dall'istruzione \code{export
- LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche.}
-senza specificare attese (come si può notare in (\texttt{\small 17--19}) i
-valori predefiniti specificano di non attendere), otterremo come output sul
+Se eseguiamo il comando, che è preceduto dall'istruzione \code{export
+ LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche, senza
+specificare attese (come si può notare in (\texttt{\small 17--19}) i valori
+predefiniti specificano di non attendere), otterremo come risultato sul
terminale:
-\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
+\begin{Command}
[piccardi@selidor sources]$ export LD_LIBRARY_PATH=./; ./forktest 3
+\end{Command}
+%$
+\begin{Terminal}
Process 1963: forking 3 child
Spawned 1 child, pid 1964
Child 1 successfully executing
Child 3, parent 1963, exiting
Spawned 3 child, pid 1966
Go to next child
-\end{Verbatim}
-%$
+\end{Terminal}
Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
si può dire quale processo fra il padre ed il figlio venga eseguito per primo
rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race
condition} (vedi sez.~\ref{sec:proc_race_cond}).
-In realtà a partire dal kernel 2.5.2-pre10 il nuovo \itindex{scheduler}
-\textit{scheduler} di Ingo Molnar esegue sempre per primo il
-figlio;\footnote{i risultati precedenti sono stati ottenuti usando un kernel
- della serie 2.4.} questa è una ottimizzazione che serve a evitare che il
-padre, effettuando per primo una operazione di scrittura in memoria, attivi il
-meccanismo del \itindex{copy~on~write} \textit{copy on write}. Questa
-operazione infatti potrebbe risultare del tutto inutile qualora il figlio
-fosse stato creato solo per eseguire una \func{exec}, in tal caso infatti si
-invocherebbe un altro programma scartando completamente lo spazio degli
-indirizzi, rendendo superflua la copia della memoria modificata dal padre.
-
-% TODO spiegare l'ulteriore cambiamento in ponte con il 2.6.32, che fa girare
-% prima il padre per questioni di caching nella CPU
-
-Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata subito
-avendo così la certezza che il \itindex{copy~on~write} \textit{copy on write}
-viene utilizzato solo quando necessario. Quanto detto in precedenza vale
-allora soltanto per i kernel fino al 2.4; per mantenere la portabilità è però
-opportuno non fare affidamento su questo comportamento, che non si riscontra
-in altri Unix e nelle versioni del kernel precedenti a quella indicata.
-
-Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
-processi completamente separati, le modifiche delle variabili nei processi
-figli (come l'incremento di \var{i} in \texttt{\small 31}) sono visibili solo
-a loro (ogni processo vede solo la propria copia della memoria), e non hanno
-alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed
-in eventuali altri processi figli che eseguano lo stesso codice).
+In realtà con l'introduzione dei kernel della serie 2.6 lo \itindex{scheduler}
+\textit{scheduler} è stato modificato per eseguire sempre per primo il
+figlio.\footnote{i risultati precedenti infatti sono stati ottenuti usando un
+ kernel della serie 2.4.} Questa è una ottimizzazione adottata per evitare
+che il padre, effettuando per primo una operazione di scrittura in memoria,
+attivasse il meccanismo del \itindex{copy~on~write} \textit{copy on write},
+operazione inutile qualora il figlio venga creato solo per eseguire una
+\func{exec} su altro programma che scarta completamente lo spazio degli
+indirizzi e rende superflua la copia della memoria modificata dal
+padre. Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata
+subito, con la certezza di utilizzare \itindex{copy~on~write} \textit{copy on
+ write} solo quando necessario.
+
+Con il kernel 2.6.32 però il comportamento è stato nuovamente cambiato,
+stavolta facendo eseguire per primo sempre il padre. Si è realizzato infatti
+che l'eventualità prospettata per la scelta precedente era comunque molto
+improbabile, mentre l'esecuzione immediata del padre presenta sempre il
+vantaggio di poter utilizzare immediatamente tutti i dati che sono nella cache
+della CPU e nella unità di gestione della memoria virtuale senza doverli
+invalidare, cosa che per i processori moderni, che hanno linee di cache
+interne molto profonde, avrebbe un forte impatto sulle prestazioni.
+
+Allora anche se quanto detto in precedenza vale come comportamento effettivo
+dei programmi soltanto per i kernel fino alla serie 2.4, per mantenere la
+portabilità con altri kernel unix-like, e con i diversi comportamenti adottati
+dalle Linux nelle versioni successive, è opportuno non fare affidamento su
+nessun tipo comportamento predefinito e non dare per assunta l'esecuzione
+preventiva del padre o del figlio.
+
+Si noti poi come dopo la \func{fork}, essendo i segmenti di memoria utilizzati
+dai singoli processi completamente indipendenti, le modifiche delle variabili
+nei processi figli, come l'incremento di \var{i} in (\texttt{\small 31}), sono
+visibili solo a loro, (ogni processo vede solo la propria copia della
+memoria), e non hanno alcun effetto sul valore che le stesse variabili hanno
+nel processo padre ed in eventuali altri processi figli che eseguano lo stesso
+codice.
Un secondo aspetto molto importante nella creazione dei processi figli è
-quello dell'interazione dei vari processi con i file; per illustrarlo meglio
-proviamo a redirigere su un file l'output del nostro programma di test, quello
-che otterremo è:
-\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
+quello dell'interazione dei vari processi con i file. Ne parleremo qui anche
+se buona parte dei concetti relativi ai file verranno trattati più avanti
+(principalmente nel cap.~\ref{cha:file_unix_interface}). Per illustrare meglio
+quello che avviene si può redirigere su un file l'output del programma di
+test, quello che otterremo è:
+\begin{Command}
[piccardi@selidor sources]$ ./forktest 3 > output
[piccardi@selidor sources]$ cat output
+\end{Command}
+\begin{Terminal}
Process 1967: forking 3 child
Child 1 successfully executing
Child 1, parent 1967, exiting
Go to next child
Spawned 3 child, pid 1970
Go to next child
-\end{Verbatim}
+\end{Terminal}
che come si vede è completamente diverso da quanto ottenevamo sul terminale.
Il comportamento delle varie funzioni di interfaccia con i file è analizzato
-in gran dettaglio in cap.~\ref{cha:file_unix_interface} e in
-cap.~\ref{cha:files_std_interface}. Qui basta accennare che si sono usate le
-funzioni standard della libreria del C che prevedono l'output bufferizzato; e
-questa bufferizzazione (trattata in dettaglio in sez.~\ref{sec:file_buffering})
-varia a seconda che si tratti di un file su disco (in cui il buffer viene
-scaricato su disco solo quando necessario) o di un terminale (nel qual caso il
-buffer viene scaricato ad ogni carattere di a capo).
-
-Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
-buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
-l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
-non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
-ogni figlio riceve una copia della memoria del padre, esso riceverà anche
-quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
-padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
-figlio, troveremo nel file anche tutto quello che il processo padre aveva
-scritto prima della sua creazione. E alla fine del file (dato che in questo
-caso il padre esce per ultimo) troveremo anche l'output completo del padre.
+in gran dettaglio in cap.~\ref{cha:file_unix_interface} per l'interfaccia
+nativa Unix ed in cap.~\ref{cha:files_std_interface} per la standardizzazione
+adottata nelle librerie del linguaggio C e valida per qualunque sistema
+operativo. Qui basta accennare che si sono usate le funzioni standard della
+libreria del C che prevedono l'output bufferizzato. Il punto è che questa
+bufferizzazione (che tratteremo in dettaglio in sez.~\ref{sec:file_buffering})
+varia a seconda che si tratti di un file su disco, in cui il buffer viene
+scaricato su disco solo quando necessario, o di un terminale, in cui il buffer
+viene scaricato ad ogni carattere di a capo.
+
+Nel primo esempio allora avevamo che, essendovi un a capo nella stringa
+stampata, ad ogni chiamata a \func{printf} il buffer veniva scaricato, per cui
+le singole righe comparivano a video subito dopo l'esecuzione della
+\func{printf}. Ma con la redirezione su file la scrittura non avviene più alla
+fine di ogni riga e l'output resta nel buffer. Dato che ogni figlio riceve una
+copia della memoria del padre, esso riceverà anche quanto c'è nel buffer delle
+funzioni di I/O, comprese le linee scritte dal padre fino allora. Così quando
+il buffer viene scritto su disco all'uscita del figlio, troveremo nel file
+anche tutto quello che il processo padre aveva scritto prima della sua
+creazione. E alla fine del file (dato che in questo caso il padre esce per
+ultimo) troveremo anche l'output completo del padre.
L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
solo processi diversi possono scrivere in contemporanea sullo stesso file
(l'argomento della condivisione dei file è trattato in dettaglio in
sez.~\ref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
-le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
-i processi figli.
-
-Quello che succede è che quando lo standard output del padre viene rediretto
-come si è fatto nell'esempio, lo stesso avviene anche per tutti i figli; la
-funzione \func{fork} infatti ha la caratteristica di duplicare nei processi
-figli tutti i file descriptor aperti nel processo padre (allo stesso modo in
-cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}), il che
-comporta che padre e figli condividono le stesse voci della
-\itindex{file~table} \textit{file table} (per la spiegazione di questi termini
-si veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente
-nel file.
-
-In questo modo se un processo scrive sul file aggiornerà la posizione corrente
-sulla \itindex{file~table} \textit{file table}, e tutti gli altri processi,
-che vedono la stessa \itindex{file~table} \textit{file table}, vedranno il
-nuovo valore. In questo modo si evita, in casi come quello appena mostrato in
-cui diversi processi scrivono sullo stesso file, che l'output successivo di un
-processo vada a sovrapporsi a quello dei precedenti: l'output potrà risultare
-mescolato, ma non ci saranno parti perdute per via di una sovrascrittura.
+le variabili in memoria, la posizione corrente sul file è condivisa fra il
+padre e tutti i processi figli.
+
+Quello che succede è che quando lo \textit{standard output}\footnote{si chiama
+ così il file su cui un programma scrive i suoi dati in uscita, tratteremo
+ l'argomento in dettaglio in sez.~\ref{sec:file_std_descr}.} del padre viene
+rediretto come si è fatto nell'esempio, lo stesso avviene anche per tutti i
+figli. La funzione \func{fork} infatti ha la caratteristica di duplicare nei
+processi figli tutti i file descriptor (vedi sez.~\ref{sec:file_fd}) dei file
+aperti nel processo padre (allo stesso modo in cui lo fa la funzione
+\func{dup}, trattata in sez.~\ref{sec:file_dup}), il che comporta che padre e
+figli condividono le stesse voci della \itindex{file~table} \textit{file
+ table} (tratteremo in dettagli questi termini in
+sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente nel file.
+
+In questo modo se un processo scrive su un file aggiornerà la posizione
+corrente sulla \itindex{file~table} \textit{file table}, e tutti gli altri
+processi, che vedono la stessa \itindex{file~table} \textit{file table},
+vedranno il nuovo valore. In questo modo si evita, in casi come quello appena
+mostrato in cui diversi processi scrivono sullo stesso file, che l'output
+successivo di un processo vada a sovrapporsi a quello dei precedenti: l'output
+potrà risultare mescolato, ma non ci saranno parti perdute per via di una
+sovrascrittura.
Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
crea un figlio e attende la sua conclusione per proseguire, ed entrambi
-scrivono sullo stesso file; un caso tipico è la shell quando lancia un
-programma, il cui output va sullo standard output. In questo modo, anche se
-l'output viene rediretto, il padre potrà sempre continuare a scrivere in coda
-a quanto scritto dal figlio in maniera automatica; se così non fosse ottenere
-questo comportamento sarebbe estremamente complesso necessitando di una
-qualche forma di comunicazione fra i due processi per far riprendere al padre
-la scrittura al punto giusto.
+scrivono sullo stesso file. Un caso tipico di questo comportamento è la shell
+quando lancia un programma. In questo modo, anche se lo standard output viene
+rediretto, il padre potrà sempre continuare a scrivere in coda a quanto
+scritto dal figlio in maniera automatica; se così non fosse ottenere questo
+comportamento sarebbe estremamente complesso necessitando di una qualche forma
+di comunicazione fra i due processi per far riprendere al padre la scrittura
+al punto giusto.
In generale comunque non è buona norma far scrivere più processi sullo stesso
file senza una qualche forma di sincronizzazione in quanto, come visto anche
processore (vedi sez.~\ref{sec:proc_sched_stand},
sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
\item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
+\item l'insieme dei descrittori associati alle code di messaggi POSIX (vedi
+ sez.~\ref{sec:ipc_posix_mq}) che vengono copiate come i file descriptor,
+ questo significa che entrambi condivideranno gli stessi flag.
\end{itemize*}
-Le differenze fra padre e figlio dopo la \func{fork} invece sono:\footnote{a
- parte le ultime quattro, relative a funzionalità specifiche di Linux, le
- altre sono esplicitamente menzionate dallo standard POSIX.1-2001.}
+
+Oltre a quelle relative ad un diverso spazio degli indirizzi (e una memoria
+totalmente indipendente) le differenze fra padre e figlio dopo l'esecuzione di
+una \func{fork} invece sono:\footnote{a parte le ultime quattro, relative a
+ funzionalità specifiche di Linux, le altre sono esplicitamente menzionate
+ dallo standard POSIX.1-2001.}
\begin{itemize*}
\item il valore di ritorno di \func{fork};
-\item il \acr{pid} (\textit{process id}), assegnato ad un nuovo valore univoco;
+\item il \acr{pid} (\textit{process id}), quello del figlio viene assegnato ad
+ un nuovo valore univoco;
\item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
impostato al \acr{pid} del padre;
\item i valori dei tempi di esecuzione (vedi sez.~\ref{sec:sys_cpu_times}) e
\item le mappature di memoria marcate come \const{MADV\_DONTFORK} (vedi
sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;
\item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:process_prctl}) che
- notifica al figlio la terminazione del padre viene cancellata;
-\item il segnale di terminazione del figlio è sempre \const{SIGCHLD} anche
+ notifica al figlio la terminazione del padre viene cancellata se presente
+ nel padre;
+\item il segnale di terminazione del figlio è sempre \signal{SIGCHLD} anche
qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}).
\end{itemize*}
Dato che Linux supporta il \itindex{copy~on~write} \textit{copy on write} la
perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
-funzione, che resta un caso speciale della system call \func{clone} (che
-tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per
+funzione, che resta un caso speciale della \textit{system call} \func{clone}
+(che tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per
questo eviteremo di trattarla ulteriormente.
\label{sec:proc_termination}
In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
-chiudere un programma, ma dall'interno del programma stesso; avendo a che fare
-con un sistema multitasking resta da affrontare l'argomento dal punto di vista
-di come il sistema gestisce la conclusione dei processi.
+chiudere un programma, ma dall'interno del programma stesso. Avendo a che fare
+con un sistema \textit{multitasking} resta da affrontare l'argomento dal punto
+di vista di come il sistema gestisce la conclusione dei processi.
Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
-programma viene terminato in maniera normale: la chiamata di \func{exit} (che
-esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
-dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
-chiamata ad \func{\_exit} (che passa direttamente alle operazioni di
-terminazione del processo da parte del kernel).
+programma viene terminato in maniera normale: la chiamata di \func{exit}, che
+esegue le funzioni registrate per l'uscita e chiude i \textit{file stream} e
+poi esegue \func{\_exit}, il ritorno dalla funzione \func{main} equivalente
+alla chiamata di \func{exit}, e la chiamata diretta a \func{\_exit}, che passa
+direttamente alle operazioni di terminazione del processo da parte del kernel.
Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
-modalità di conclusione anomala; queste sono in sostanza due: il programma può
-chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
-terminato da un segnale (torneremo sui segnali in cap.~\ref{cha:signals}). In
-realtà anche la prima modalità si riconduce alla seconda, dato che
-\func{abort} si limita a generare il segnale \const{SIGABRT}.
+modalità di conclusione anomala. Queste sono in sostanza due: il programma può
+chiamare la funzione \func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}) per
+invocare una chiusura anomala, o essere terminato da un segnale (torneremo sui
+segnali in cap.~\ref{cha:signals}). In realtà anche la prima modalità si
+riconduce alla seconda, dato che \func{abort} si limita a generare il segnale
+\signal{SIGABRT}.
Qualunque sia la modalità di conclusione di un processo, il kernel esegue
-comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
-memoria che stava usando, e così via; l'elenco completo delle operazioni
-eseguite alla chiusura di un processo è il seguente:
+comunque una serie di operazioni di terminazione: chiude tutti i file aperti,
+rilascia la memoria che stava usando, e così via; l'elenco completo delle
+operazioni eseguite alla chiusura di un processo è il seguente:
\begin{itemize*}
\item tutti i file descriptor sono chiusi;
\item viene memorizzato lo stato di terminazione del processo;
\item ad ogni processo figlio viene assegnato un nuovo padre (in genere
\cmd{init});
-\item viene inviato il segnale \const{SIGCHLD} al processo padre (vedi
+\item viene inviato il segnale \signal{SIGCHLD} al processo padre (vedi
sez.~\ref{sec:sig_sigchld});
\item se il processo è un leader di sessione ed il suo terminale di controllo
- è quello della sessione viene mandato un segnale di \const{SIGHUP} a tutti i
+ è quello della sessione viene mandato un segnale di \signal{SIGHUP} a tutti i
processi del gruppo di \textit{foreground} e il terminale di controllo viene
disconnesso (vedi sez.~\ref{sec:sess_ctrl_term});
\item se la conclusione di un processo rende orfano un \textit{process
group} ciascun membro del gruppo viene bloccato, e poi gli vengono
- inviati in successione i segnali \const{SIGHUP} e \const{SIGCONT}
+ inviati in successione i segnali \signal{SIGHUP} e \signal{SIGCONT}
(vedi ancora sez.~\ref{sec:sess_ctrl_term}).
\end{itemize*}
+\itindbeg{termination~status}
+
Oltre queste operazioni è però necessario poter disporre di un meccanismo
ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
-scelto consiste nel riportare lo stato di terminazione (il cosiddetto
-\textit{termination status}) al processo padre.
+scelto consiste nel riportare lo \itindex{termination~status} \textsl{stato di
+ terminazione} (il cosiddetto \textit{termination status}) al processo padre.
Nel caso di conclusione normale, abbiamo visto in
sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
-valore passato alle funzioni \func{exit} o \func{\_exit} (o dal valore di
-ritorno per \func{main}). Ma se il processo viene concluso in maniera anomala
-il programma non può specificare nessun \textit{exit status}, ed è il kernel
-che deve generare autonomamente il \textit{termination status} per indicare le
-ragioni della conclusione anomala.
+valore passato come argomento alle funzioni \func{exit} o \func{\_exit} o il
+valore di ritorno per \func{main}. Ma se il processo viene concluso in
+maniera anomala il programma non può specificare nessun \textit{exit status},
+ed è il kernel che deve generare autonomamente il \textit{termination status}
+per indicare le ragioni della conclusione anomala.
Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
quello che contraddistingue lo stato di chiusura del processo e viene
riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
-sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
-il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
-secondo.
+sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione
+normale il kernel usa il primo (nel codice eseguito da \func{\_exit}) per
+produrre il secondo.
La scelta di riportare al padre lo stato di terminazione dei figli, pur
essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
-alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
-che sia così alla sua conclusione, dato che il padre potrebbe essere già
+alla sua creazione è scontato che ogni nuovo processo abbia un padre, non è
+detto che sia così alla sua conclusione, dato che il padre potrebbe essere già
terminato; si potrebbe avere cioè quello che si chiama un processo
-\textsl{orfano}.
+\textsl{orfano}.
Questa complicazione viene superata facendo in modo che il processo orfano
-venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
-termina, il kernel controlla se è il padre di altri processi in esecuzione: in
-caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
-con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
-avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
-cui riportare il suo stato di terminazione. Come verifica di questo
-comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
-ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
-\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
+venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \acr{pid} 1,
+cioè quello lanciato direttamente dal kernel all'avvio, che sta alla base
+dell'albero dei processi visto in sez.~\ref{sec:proc_hierarchy} e che anche
+per questo motivo ha un ruolo essenziale nel sistema e non può mai
+terminare.\footnote{almeno non senza un blocco completo del sistema, in caso
+ di terminazione o di non esecuzione di \cmd{init} infatti il kernel si
+ blocca con un cosiddetto \textit{kernel panic}, dato che questo è un errore
+ fatale.}
+
+Come già accennato quando un processo termina, il kernel controlla se è il
+padre di altri processi in esecuzione: in caso positivo allora il \acr{ppid}
+di tutti questi processi verrà sostituito dal kernel con il \acr{pid} di
+\cmd{init}, cioè con 1. In questo modo ogni processo avrà sempre un padre (nel
+caso possiamo parlare di un padre \textsl{adottivo}) cui riportare il suo
+stato di terminazione.
+
+Come verifica di questo comportamento possiamo eseguire il nostro programma
+\cmd{forktest} imponendo a ciascun processo figlio due secondi di attesa prima
+di uscire, il risultato è:
+\begin{Command}
[piccardi@selidor sources]$ ./forktest -c2 3
+\end{Command}
+\begin{Terminal}[commandchars=\\\{\}]
Process 1972: forking 3 child
Spawned 1 child, pid 1973
Child 1 successfully executing
Child 3 successfully executing
Spawned 3 child, pid 1975
Go to next child
-[piccardi@selidor sources]$ Child 3, parent 1, exiting
+
+\textbf{[piccardi@selidor sources]$} Child 3, parent 1, exiting
Child 2, parent 1, exiting
Child 1, parent 1, exiting
-\end{Verbatim}
+\end{Terminal}
come si può notare in questo caso il processo padre si conclude prima dei
figli, tornando alla shell, che stampa il prompt sul terminale: circa due
secondi dopo viene stampato a video anche l'output dei tre figli che
Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
-mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
-processi che sono terminati, ma il cui stato di terminazione non è stato
-ancora ricevuto dal padre sono chiamati \index{zombie} \textit{zombie}, essi
+mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente.
+
+I processi che sono terminati, ma il cui stato di terminazione non è stato
+ancora ricevuto dal padre sono chiamati \itindex{zombie} \textit{zombie}, essi
restano presenti nella tabella dei processi ed in genere possono essere
identificati dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella
colonna che ne indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando
-il padre effettuerà la lettura dello stato di uscita anche questa
-informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi
-completamente conclusa.
+il padre effettuerà la lettura dello stato di terminazione anche questa
+informazione, non più necessaria, verrà scartata ed il processo potrà
+considerarso completamente concluso.
Possiamo utilizzare il nostro programma di prova per analizzare anche questa
condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi
sez.~\ref{sec:sess_job_control}), indicando al processo padre di aspettare 10
-secondi prima di uscire; in questo caso, usando \cmd{ps} sullo stesso
+secondi prima di uscire. In questo caso, usando \cmd{ps} sullo stesso
terminale (prima dello scadere dei 10 secondi) otterremo:
-\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
+\begin{Command}
[piccardi@selidor sources]$ ps T
+\end{Command}
+%$
+\begin{Terminal}
PID TTY STAT TIME COMMAND
419 pts/0 S 0:00 bash
568 pts/0 S 0:00 ./forktest -e10 3
570 pts/0 Z 0:00 [forktest <defunct>]
571 pts/0 Z 0:00 [forktest <defunct>]
572 pts/0 R 0:00 ps T
-\end{Verbatim}
-%$
-e come si vede, dato che non si è fatto nulla per riceverne lo
-stato di terminazione, i tre processi figli sono ancora presenti pur essendosi
-conclusi, con lo stato di \index{zombie} \textit{zombie} e l'indicazione che
-sono stati terminati.
+\end{Terminal}
+e come si vede, dato che non si è fatto nulla per riceverne lo stato di
+terminazione, i tre processi figli sono ancora presenti pur essendosi
+conclusi, con lo stato di \itindex{zombie} \textit{zombie} e l'indicazione che
+sono terminati (la scritta \texttt{defunct}).
-La possibilità di avere degli \index{zombie} \textit{zombie} deve essere
+La possibilità di avere degli \itindex{zombie} \textit{zombie} deve essere
tenuta sempre presente quando si scrive un programma che deve essere mantenuto
in esecuzione a lungo e creare molti figli. In questo caso si deve sempre
-avere cura di far leggere l'eventuale stato di uscita di tutti i figli (in
+avere cura di far leggere l'eventuale stato di uscita di tutti i figli. In
genere questo si fa attraverso un apposito \textit{signal handler}, che chiama
-la funzione \func{wait}, vedi sez.~\ref{sec:sig_sigchld} e
-sez.~\ref{sec:proc_wait}). Questa operazione è necessaria perché anche se gli
-\index{zombie} \textit{zombie} non consumano risorse di memoria o processore,
-occupano comunque una voce nella tabella dei processi, che a lungo andare
-potrebbe esaurirsi.
-
-Si noti che quando un processo adottato da \cmd{init} termina, esso non
-diviene uno \index{zombie} \textit{zombie}; questo perché una delle funzioni
-di \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i
-processi cui fa da padre, completandone la terminazione. Questo è quanto
-avviene anche quando, come nel caso del precedente esempio con \cmd{forktest},
-il padre termina con dei figli in stato di \index{zombie} \textit{zombie}:
-alla sua terminazione infatti tutti i suoi figli (compresi gli \index{zombie}
-\textit{zombie}) verranno adottati da \cmd{init}, il quale provvederà a
-completarne la terminazione.
-
-Si tenga presente infine che siccome gli \index{zombie} \textit{zombie} sono
-processi già usciti, non c'è modo di eliminarli con il comando \cmd{kill};
-l'unica possibilità di cancellarli dalla tabella dei processi è quella di
-terminare il processo che li ha generati, in modo che \cmd{init} possa
-adottarli e provvedere a concluderne la terminazione.
-
+la funzione \func{wait}, (vedi sez.~\ref{sec:sig_sigchld} e
+sez.~\ref{sec:proc_wait}) di cui vedremo un esempio in
+fig.~\ref{fig:sig_sigchld_handl}.
+
+Questa operazione è necessaria perché anche se gli \itindex{zombie}
+\textit{zombie} non consumano risorse di memoria o processore, occupano
+comunque una voce nella tabella dei processi e se li si lascia accumulare a
+lungo quest'ultima potrebbe riempirsi, con l'impossibilità di lanciare nuovi
+processi.
+
+Si noti tuttavia che quando un processo adottato da \cmd{init} termina, non
+diviene mai uno \itindex{zombie} \textit{zombie}. Questo perché una delle
+funzioni di \cmd{init} è appunto quella di chiamare la funzione \func{wait}
+per i processi a cui fa da padre, completandone la terminazione. Questo è
+quanto avviene anche quando, come nel caso del precedente esempio con
+\cmd{forktest}, il padre termina con dei figli in stato di \itindex{zombie}
+\textit{zombie}. Questi scompaiono quando, alla terminazione del padre dopo i
+secondi programmati, tutti figli che avevamo generato, e che erano diventati
+\itindex{zombie} \textit{zombie}, vengono adottati da \cmd{init}, il quale
+provvede a completarne la terminazione.
+
+Si tenga presente infine che siccome gli \itindex{zombie} \textit{zombie} sono
+processi già terminati, non c'è modo di eliminarli con il comando \cmd{kill} o
+inviandogli un qualunque segnale di terminazione (l'argomento è trattato in
+sez.~\ref{sec:sig_termination}). L'unica possibilità di cancellarli dalla
+tabella dei processi è quella di terminare il processo che li ha generati, in
+modo che \cmd{init} possa adottarli e concluderne la terminazione.
\subsection{Le funzioni di attesa e ricezione degli stati di uscita}
\label{sec:proc_wait}
Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
consiste nella creazione di programmi di tipo server, in cui un processo
principale attende le richieste che vengono poi soddisfatte da una serie di
-processi figli. Si è già sottolineato al paragrafo precedente come in questo
-caso diventi necessario gestire esplicitamente la conclusione dei figli onde
-evitare di riempire di \index{zombie} \textit{zombie} la tabella dei processi;
-le funzioni deputate a questo compito sono principalmente due, la prima è
-\funcd{wait} ed il suo prototipo è:
-\begin{functions}
-\headdecl{sys/types.h}
-\headdecl{sys/wait.h}
-\funcdecl{pid\_t wait(int *status)}
-
-Sospende il processo corrente finché un figlio non è uscito, o finché un
-segnale termina il processo o chiama una funzione di gestione.
-
-\bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
- e -1 in caso di errore; \var{errno} può assumere i valori:
+processi figli.
+
+Si è già sottolineato al paragrafo precedente come in questo caso diventi
+necessario gestire esplicitamente la conclusione dei figli onde evitare di
+riempire di \itindex{zombie} \textit{zombie} la tabella dei
+processi. Tratteremo in questa sezione le funzioni deputate a questo compito;
+la prima è \funcd{wait} ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/wait.h}
+\fdecl{pid\_t wait(int *status)}
+\fdesc{Attende la terminazione di un processo.}
+}
+{La funzione ritorna il \acr{pid} del figlio in caso di successo e $-1$ per un
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
+ \item[\errcode{ECHILD}] il processo non ha nessun figlio di cui attendere
+ uno stato di terminazione.
\item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}}
-\end{functions}
-\noindent
+\end{funcproto}
-Questa funzione è presente fin dalle prime versioni di Unix; essa ritorna non
-appena un qualunque processo figlio termina. Se un figlio è già terminato
-prima della chiamata la funzione ritorna immediatamente, se più di un figlio è
-già terminato occorre continuare chiamare la funzione più volte se si vuole
-recuperare lo stato di terminazione di tutti quanti.
+Questa funzione è presente fin dalle prime versioni di Unix ed è quella usata
+tradizionalmente per attendere la terminazione dei figli. La funzione sospende
+l'esecuzione del processo corrente e ritorna non appena un qualunque processo
+figlio termina. Se un figlio è già terminato prima della sua chiamata la
+funzione ritorna immediatamente, se più processi figli sono già terminati
+occorrerà continuare a chiamare la funzione più volte fintanto che non si è
+recuperato lo stato di terminazione di tutti quanti.
Al ritorno della funzione lo stato di terminazione del figlio viene salvato
-nella variabile puntata da \param{status} e tutte le risorse del kernel
-relative al processo (vedi sez.~\ref{sec:proc_termination}) vengono
-rilasciate. Nel caso un processo abbia più figli il valore di ritorno della
-funzione sarà impostato al \acr{pid} del processo di cui si è ricevuto lo
-stato di terminazione, cosa che permette di identificare qual è il figlio che
-è terminato.
+(come \itindex{value~result~argument} \textit{value result argument}) nella
+variabile puntata da \param{status} e tutte le risorse del kernel relative al
+processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate. Nel caso
+un processo abbia più figli il valore di ritorno della funzione sarà impostato
+al \acr{pid} del processo di cui si è ricevuto lo stato di terminazione, cosa
+che permette di identificare qual è il figlio che è terminato.
+
+\itindend{termination~status}
Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
-necessario attendere la conclusione di un processo specifico occorrerebbe
-predisporre un meccanismo che tenga conto dei processi già terminati, e
-provvedere a ripetere la chiamata alla funzione nel caso il processo cercato
-sia ancora attivo.
+necessario attendere la conclusione di uno specifico processo fra tutti quelli
+esistenti occorre predisporre un meccanismo che tenga conto di tutti processi
+che sono terminati, e provveda a ripetere la chiamata alla funzione nel caso
+il processo cercato non risulti fra questi. Se infatti il processo cercato è
+già terminato e se è già ricevuto lo stato di uscita senza registrarlo, la
+funzione non ha modo di accorgersene, e si continuerà a chiamarla senza
+accorgersi che quanto interessava è già accaduto.
Per questo motivo lo standard POSIX.1 ha introdotto una seconda funzione che
effettua lo stesso servizio, ma dispone di una serie di funzionalità più
\code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
\&status, 0)}.} si consiglia di utilizzare sempre questa nuova funzione,
\funcd{waitpid}, il cui prototipo è:
-\begin{functions}
-\headdecl{sys/types.h}
-\headdecl{sys/wait.h}
-\funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
-Attende la conclusione di un processo figlio.
-\bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
- è stata specificata l'opzione \const{WNOHANG} e il processo non è uscito e
- -1 per un errore, nel qual caso \var{errno} assumerà i valori:
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/wait.h}
+\fdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
+\fdesc{Attende il cambiamento di stato di un processo figlio.}
+}
+{La funzione ritorna il \acr{pid} del processo che ha cambiato stato in caso
+ di successo, o 0 se è stata specificata l'opzione \const{WNOHANG} e il
+ processo non è uscito e $-1$ per un errore, nel qual caso \var{errno}
+ assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
la funzione è stata interrotta da un segnale.
\item[\errcode{EINVAL}] si è specificato un valore non valido per
l'argomento \param{options}.
\end{errlist}}
-\end{functions}
+\end{funcproto}
La prima differenza fra le due funzioni è che con \func{waitpid} si può
specificare in maniera flessibile quale processo attendere, sulla base del
Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
funzione delle opportune opzioni tramite l'argomento \param{options}; questo
-deve essere specificato come maschera binaria dei flag riportati nella prima
-parte in tab.~\ref{tab:proc_waitpid_options} che possono essere combinati fra
-loro con un OR aritmetico. Nella seconda parte della stessa tabella si sono
-riportati anche alcuni valori non standard specifici di Linux, che consentono
-un controllo più dettagliato per i processi creati con la system call generica
-\func{clone} (vedi sez.~\ref{sec:process_clone}) usati principalmente per la
-gestione della terminazione dei \itindex{thread} \textit{thread} (vedi
-sez.~\ref{sec:thread_xxx}).
+deve essere specificato come maschera binaria delle costanti riportati nella
+prima parte in tab.~\ref{tab:proc_waitpid_options} che possono essere
+combinate fra loro con un OR aritmetico. Nella seconda parte della stessa
+tabella si sono riportati anche alcuni valori non standard specifici di Linux,
+che consentono un controllo più dettagliato per i processi creati con la
+\textit{system call} generica \func{clone} (vedi sez.~\ref{sec:process_clone})
+usati principalmente per la gestione della terminazione dei \itindex{thread}
+\textit{thread} (vedi sez.~\ref{sec:thread_xxx}).
\begin{table}[!htb]
\centering
\footnotesize
\begin{tabular}[c]{|l|p{8cm}|}
\hline
- \textbf{Macro} & \textbf{Descrizione}\\
+ \textbf{Valore} & \textbf{Descrizione}\\
\hline
\hline
\const{WNOHANG} & La funzione ritorna immediatamente anche se non è
\const{WCONTINUED}& Ritorna anche quando un processo figlio che era stato
fermato ha ripreso l'esecuzione.\footnotemark \\
\hline
- \const{\_\_WCLONE}& Attende solo per i figli creati con \func{clone},
- vale a dire processi che non emettono nessun segnale
- o emettono un segnale diverso da \const{SIGCHL} alla
+ \const{\_\_WCLONE}& Attende solo per i figli creati con \func{clone}
+ (vedi sez.~\ref{sec:process_clone}), vale a dire
+ processi che non emettono nessun segnale
+ o emettono un segnale diverso da \signal{SIGCHLD} alla
terminazione. \\
\const{\_\_WALL} & Attende per qualunque processo figlio. \\
\const{\_\_WNOTHREAD}& Non attende per i figli di altri \textit{thread}
sez.~\ref{sec:process_ptrace}).} (vedi tab.~\ref{tab:proc_proc_states}),
mentre con \const{WCONTINUED} la funzione ritorna quando un processo in stato
\textit{stopped} riprende l'esecuzione per la ricezione del segnale
-\const{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
+\signal{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
dettagliato in sez.~\ref{sec:sess_ctrl_term}).
La terminazione di un processo figlio (così come gli altri eventi osservabili
di un programma e può avvenire in un qualunque momento. Per questo motivo,
come accennato nella sezione precedente, una delle azioni prese dal kernel
alla conclusione di un processo è quella di mandare un segnale di
-\const{SIGCHLD} al padre. L'azione predefinita (si veda
+\signal{SIGCHLD} al padre. L'azione predefinita (si veda
sez.~\ref{sec:sig_base}) per questo segnale è di essere ignorato, ma la sua
generazione costituisce il meccanismo di comunicazione asincrona con cui il
kernel avverte il processo padre che uno dei suoi figli è terminato.
al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello
standard POSIX.1-2001,\footnote{una revisione del 2001 dello standard POSIX.1
che ha aggiunto dei requisiti e delle nuove funzioni, come \func{waitid}.}
-e come da esso richiesto se \const{SIGCHLD} viene ignorato, o se si imposta il
+e come da esso richiesto se \signal{SIGCHLD} viene ignorato, o se si imposta il
flag di \const{SA\_NOCLDSTOP} nella ricezione dello stesso (si veda
sez.~\ref{sec:sig_sigaction}) i processi figli che terminano non diventano
\textit{zombie} e sia \func{wait} che \func{waitpid} si bloccano fintanto che
errore di \errcode{ENOCHLD}.\footnote{questo è anche il motivo per cui le
opzioni \const{WUNTRACED} e \const{WCONTINUED} sono utilizzabili soltanto
qualora non si sia impostato il flag di \const{SA\_NOCLDSTOP} per il segnale
- \const{SIGCHLD}.}
+ \signal{SIGCHLD}.}
Con i kernel della serie 2.4 e tutti i kernel delle serie precedenti entrambe
le funzioni di attesa ignorano questa prescrizione\footnote{lo standard POSIX.1
originale infatti lascia indefinito il comportamento di queste funzioni
- quando \const{SIGCHLD} viene ignorato.} e si comportano sempre nello stesso
-modo, indipendentemente dal fatto \const{SIGCHLD} sia ignorato o meno:
+ quando \signal{SIGCHLD} viene ignorato.} e si comportano sempre nello stesso
+modo, indipendentemente dal fatto \signal{SIGCHLD} sia ignorato o meno:
attendono la terminazione di un processo figlio e ritornano il relativo
\acr{pid} e lo stato di terminazione nell'argomento \param{status}.
nullo. \\
\macro{WIFCONTINUED(s)}& Vera se il processo che ha causato il ritorno è
stato riavviato da un
- \const{SIGCONT}.\footnotemark \\
+ \signal{SIGCONT}.\footnotemark \\
\hline
\end{tabular}
\caption{Descrizione delle varie macro di preprocessore utilizzabili per
In generale in un programma non si vuole essere forzati ad attendere la
conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente
-la presenza di \index{zombie} \textit{zombie}).
+la presenza di \itindex{zombie} \textit{zombie}).
Per questo la modalità più comune di chiamare queste funzioni è quella di
utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
-come gestire \const{SIGCHLD} con i segnali in sez.~\ref{sec:sig_example}). In
+come gestire \signal{SIGCHLD} con i segnali in sez.~\ref{sec:sig_example}). In
questo caso infatti, dato che il segnale è generato dalla terminazione di un
figlio, avremo la certezza che la chiamata a \func{waitpid} non si bloccherà.
controllo molto più preciso sui possibili cambiamenti di stato dei processi
figli e più dettagli sullo stato di uscita; la funzione è \funcd{waitid} ed il
suo prototipo è:
-\begin{functions}
- \headdecl{sys/types.h}
-
- \headdecl{sys/wait.h}
-
- \funcdecl{int waitid(idtype\_t idtype, id\_t id, siginfo\_t *infop, int
- options)}
-
- Attende la conclusione di un processo figlio.
- \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore,
- nel qual caso \var{errno} assumerà i valori:
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/wait.h}
+\fdecl{int waitid(idtype\_t idtype, id\_t id, siginfo\_t *infop, int options)}
+\fdesc{Attende il cambiamento di stato di un processo figlio.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINTR}] se non è stata specificata l'opzione \const{WNOHANG} e
+ \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
la funzione è stata interrotta da un segnale.
\item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
non è figlio del processo chiamante.
\item[\errcode{EINVAL}] si è specificato un valore non valido per
l'argomento \param{options}.
\end{errlist}}
-\end{functions}
+\end{funcproto}
La funzione prevede che si specifichi quali processi si intendono osservare
usando i due argomenti \param{idtype} ed \param{id}; il primo indica se ci si
\footnotesize
\begin{tabular}[c]{|l|p{8cm}|}
\hline
- \textbf{Macro} & \textbf{Descrizione}\\
+ \textbf{Valore} & \textbf{Descrizione}\\
\hline
\hline
\const{P\_PID} & Indica la richiesta di attendere per un processo figlio
\footnotesize
\begin{tabular}[c]{|l|p{8cm}|}
\hline
- \textbf{Macro} & \textbf{Descrizione}\\
+ \textbf{Valore} & \textbf{Descrizione}\\
\hline
\hline
\const{WEXITED} & Ritorna quando un processo figlio è terminato.\\
\item[\var{si\_pid}] con il \acr{pid} del figlio.
\item[\var{si\_uid}] con l'user-ID reale (vedi sez.~\ref{sec:proc_perms}) del
figlio.
-\item[\var{si\_signo}] con \const{SIGCHLD}.
+\item[\var{si\_signo}] con \signal{SIGCHLD}.
\item[\var{si\_status}] con lo stato di uscita del figlio o con il segnale che
lo ha terminato, fermato o riavviato.
\item[\var{si\_code}] con uno fra \const{CLD\_EXITED}, \const{CLD\_KILLED},
sez.~\ref{sec:sys_res_limits}) usate dal processo terminato e dai vari figli.
Le due funzioni sono \funcd{wait3} e \funcd{wait4}, che diventano accessibili
definendo la macro \macro{\_USE\_BSD}; i loro prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/times.h}
+\fhead{sys/resource.h}
+\fhead{sys/wait.h}
+\fdecl{int wait4(pid\_t pid, int *status, int options, struct rusage *rusage))}
+\fdesc{Attende il cambiamento di stato di un processo figlio, riportando l'uso
+ delle risorsr.}
+}
+{La funzione ha gli stessi valori di ritorno e codici di errore di
+ \func{waitpid}. }
+\end{funcproto}
+
+
\begin{functions}
\headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
\headdecl{sys/resource.h}
sez.~\ref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
+
\subsection{La funzione \func{exec} e le funzioni di esecuzione dei programmi}
\label{sec:proc_exec}
indicato dall'argomento \param{path}, che viene interpretato come il
\itindex{pathname} \textit{pathname} del programma.
-\begin{figure}[htb]
- \centering
- \includegraphics[width=12cm]{img/exec_rel}
+\begin{figure}[!htb]
+ \centering \includegraphics[width=12cm]{img/exec_rel}
\caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
\label{fig:proc_exec_relat}
\end{figure}
mantengono la stessa impostazione pure nel nuovo programma, ma tutti gli altri
segnali, ed in particolare quelli per i quali è stato installato un gestore
vengono impostati alla loro azione predefinita (vedi
-sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \const{SIGCHLD}
+sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \signal{SIGCHLD}
che, quando impostato a \const{SIG\_IGN}, potrebbe anche essere reimpostato a
\const{SIG\_DFL}, anche se questo con Linux non avviene.\footnote{lo standard
POSIX.1-2001 prevede che questo comportamento sia deciso dalla singola
sez.~\ref{sec:process_prctl}) viene cancellato;
\item il nome del processo viene impostato al nome del file contenente il
programma messo in esecuzione;
-\item il segnale di terminazione viene reimpostato a \const{SIGCHLD};
+\item il segnale di terminazione viene reimpostato a \signal{SIGCHLD};
\item l'ambiente viene reinizializzato impostando le variabili attinenti alla
localizzazione al valore di default POSIX.
\end{itemize*}
Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
processo, in Linux un processo può trovarsi in uno degli stati riportati in
tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
-\textbf{Runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
+\textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
sia la sua priorità, un processo non potrà mai essere messo in esecuzione
fintanto che esso si trova in uno qualunque degli altri stati.
\textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
\hline
\hline
- \textbf{Runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
+ \textit{runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
essere eseguito (cioè è in attesa che gli
venga assegnata la CPU).\\
- \textbf{Sleep} & \texttt{S} & Il processo è in attesa di un
+ \textit{sleep} & \texttt{S} & Il processo è in attesa di un
risposta dal sistema, ma può essere
interrotto da un segnale.\\
- \textbf{Uninterrutible Sleep}& \texttt{D} & Il processo è in
+ \textit{uninterrutible sleep}& \texttt{D} & Il processo è in
attesa di un risposta dal sistema (in
genere per I/O), e non può essere
interrotto in nessuna circostanza.\\
- \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
- \const{SIGSTOP}, o è tracciato.\\
- \textbf{Zombie}\index{zombie} & \texttt{Z} & Il processo è terminato ma il
+ \textit{stopped} & \texttt{T} & Il processo è stato fermato con un
+ \signal{SIGSTOP}, o è tracciato.\\
+ \textit{zombie}\itindex{zombie}& \texttt{Z} & Il processo è terminato ma il
suo stato di terminazione non è ancora
stato letto dal padre.\\
- \textbf{Killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
+ \textit{killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
2.6.25, sostanzialmente identico
- all'\textbf{Uninterrutible Sleep} con la
+ all'\textit{uninterrutible sleep} con la
sola differenza che il processo può
- terminato con \const{SIGKILL} (usato per
+ terminato con \signal{SIGKILL} (usato per
lo più per NFS).\\
\hline
\end{tabular}
(entro certi limiti, che vedremo più avanti) la priorità dei propri processi.
Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
-di \var{nice} del processo; tuttavia la system call di Linux non segue questa
-convenzione e restituisce sempre 0 in caso di successo e $-1$ in caso di
-errore; questo perché $-1$ è un valore di \var{nice} legittimo e questo
-comporta una confusione con una eventuale condizione di errore. La system call
-originaria inoltre non consente, se non dotati di adeguati privilegi, di
-diminuire un valore di \var{nice} precedentemente innalzato.
+di \var{nice} del processo; tuttavia la \textit{system call} di Linux non
+segue questa convenzione e restituisce sempre 0 in caso di successo e $-1$ in
+caso di errore; questo perché $-1$ è un valore di \var{nice} legittimo e
+questo comporta una confusione con una eventuale condizione di errore. La
+\textit{system call} originaria inoltre non consente, se non dotati di
+adeguati privilegi, di diminuire un valore di \var{nice} precedentemente
+innalzato.
Fino alle \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
-risultato dalla system call, violando lo standard, per cui per ottenere il
-nuovo valore occorreva una successiva chiamata alla funzione
+risultato dalla \textit{system call}, violando lo standard, per cui per
+ottenere il nuovo valore occorreva una successiva chiamata alla funzione
\func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
-reimplementata e non viene più chiamata la omonima system call, con questa
-versione viene restituito come valore di ritorno il valore di \var{nice}, come
-richiesto dallo standard.\footnote{questo viene fatto chiamando al suo interno
- \func{setpriority}, che tratteremo a breve.} In questo caso l'unico modo
-per rilevare in maniera affidabile una condizione di errore è quello di
-azzerare \var{errno} prima della chiamata della funzione e verificarne il
-valore quando \func{nice} restituisce $-1$.
+reimplementata e non viene più chiamata la omonima \textit{system call}, con
+questa versione viene restituito come valore di ritorno il valore di
+\var{nice}, come richiesto dallo standard.\footnote{questo viene fatto
+ chiamando al suo interno \func{setpriority}, che tratteremo a breve.} In
+questo caso l'unico modo per rilevare in maniera affidabile una condizione di
+errore è quello di azzerare \var{errno} prima della chiamata della funzione e
+verificarne il valore quando \func{nice} restituisce $-1$.
Per leggere il valore di \textit{nice} di un processo occorre usare la
funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è:
debba essere assegnato all'interno di un intervallo fra un massimo ed un
minimo che nel caso di Linux sono rispettivamente 1 e 99.
-\begin{figure}[!bht]
+\begin{figure}[!htbp]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/sched_param.c}
\end{minipage}
\normalsize
nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
- \item[\errcode{ENOSYS}] la system call non è stata implementata.
+ \item[\errcode{ENOSYS}] la \textit{system call} non è stata implementata.
\end{errlist}}
\end{prototype}
\textit{hard CPU affinity}, in contrasto con quella fornita dallo scheduler,
detta \textit{soft CPU affinity}, che di norma indica solo una preferenza,
non un requisito assoluto.} e per poter risolvere questo tipo di
-problematiche nei nuovi kernel\footnote{le due system call per la gestione
- della \textit{CPU affinity} sono state introdotte nel kernel 2.5.8, e le
- funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
-l'opportuna infrastruttura ed una nuova system call che permette di impostare
-su quali processori far eseguire un determinato processo attraverso una
-\textsl{maschera di affinità}. La corrispondente funzione di libreria è
+problematiche nei nuovi kernel\footnote{le due \textit{system call} per la
+ gestione della \textit{CPU affinity} sono state introdotte nel kernel 2.5.8,
+ e le funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
+l'opportuna infrastruttura ed una nuova \textit{system call} che permette di
+impostare su quali processori far eseguire un determinato processo attraverso
+una \textsl{maschera di affinità}. La corrispondente funzione di libreria è
\funcd{sched\_setaffinity} ed il suo prototipo è:
\begin{prototype}{sched.h}
{int sched\_setaffinity (pid\_t pid, unsigned int cpusetsize, const
Questa funzione e la corrispondente \func{sched\_setaffinity} hanno una storia
-abbastanza complessa, la system call prevede l'uso di due ulteriori argomenti
-di tipo \texttt{unsigned int len} e \texttt{unsigned long *mask}, che
-corrispondono al fatto che la implementazione effettiva usa una semplice
+abbastanza complessa, la \textit{system call} prevede l'uso di due ulteriori
+argomenti di tipo \texttt{unsigned int len} e \texttt{unsigned long *mask},
+che corrispondono al fatto che la implementazione effettiva usa una semplice
maschera binaria. Quando le funzioni vennero incluse nelle \acr{glibc}
assunsero invece il prototipo appena mostrato. A complicare la cosa si
aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} l'argomento
di processore.
Per facilitare l'uso dell'argomento \param{cpuset} le \acr{glibc} hanno
-introdotto un apposito dato di tipo, \ctyp{cpu\_set\_t},\footnote{questa è una
+introdotto un apposito dato di tipo, \type{cpu\_set\_t},\footnote{questa è una
estensione specifica delle \acr{glibc}, da attivare definendo la macro
\macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per
questo tipo di interfaccia e POSIX al momento non prevede nulla al
utilizzo non avrà alcun effetto.} Dato che non esiste una interfaccia
diretta nelle \acr{glibc} per queste due funzioni occorrerà invocarle tramite
la funzione \func{syscall} (come illustrato in
-sez.~\ref{sec:intro_syscall}). Le due funzioni sono \funcd{ioprio\_get} ed
+sez.~\ref{sec:proc_syscall}). Le due funzioni sono \funcd{ioprio\_get} ed
\funcd{ioprio\_set}; i rispettivi prototipi sono:
\begin{functions}
\headdecl{linux/ioprio.h}
attengono alla gestione ordinaria dei processi e delle loro proprietà più
comuni. Tratteremo qui alcune \textit{system call} dedicate alla gestione di
funzionalità dei processi molto specifiche ed avanzate, il cui uso è in genere
-piuttosto ridotto. Trattandosi di problematiche relativamente complesse, che
-spesso presuppongono la conoscenza di altri argomenti trattati più avanti
-nella guida, si può saltare questa lezione ad una prima lettura, tornando su
+piuttosto ridotto. Trattandosi di problematiche abbastanza complesse, che
+spesso presuppongono la conoscenza di altri argomenti trattati nel seguito
+della guida, si può saltare questa sezione in una prima lettura, tornando su
di essa in un secondo tempo.
-\subsection{La system call \func{clone}}
+\subsection{La \textit{system call} \func{clone}}
\label{sec:process_clone}
-Da fare
+La funzione tradizionale con cui creare un nuovo processo in un sistema
+Unix-like, come illustrato in sez.~\ref{sec:proc_fork}, è \func{fork}, ma con
+l'introduzione del supporto del kernel per i \textit{thread} (vedi
+cap.~\ref{cha:threads}), si è avuta la necessità di una interfaccia che
+consentisse un maggiore controllo sulla modalità con cui vengono creati nuovi
+processi, che poi è stata utilizzata anche per fornire supporto per le
+tecnologie di virtualizzazione dei processi (i cosiddetti \textit{container}).
+
+Per questo l'interfaccia per la creazione di un nuovo processo è stata
+delegata ad una nuova \textit{system call}, \func{sys\_clone}, che consente di
+reimplementare anche la tradizionale \func{fork}. In realtà in questo caso più
+che di nuovi processi si può parlare della creazioni di nuovi
+``\textit{task}'' del kernel che possono assumere la veste sia di un processo
+classico come quelli trattati finora, che di un \textit{thread}, come quelli
+che vedremo in sez.~\ref{sec:linux_thread}, in cui la memoria viene condivisa
+fra il processo chiamante ed il nuovo processo creato. Per evitare confusione
+fra \textit{thread} e processi ordinari, abbiamo deciso di usare la
+nomenclatura \textit{task} per indicare la unità di esecuzione generica messa
+a disposizione del kernel che \texttt{sys\_clone} permette di creare.
+
+Oltre a questo la funzione consente, ad uso delle nuove funzionalità di
+virtualizzazione dei processi, di creare nuovi \textit{namespace} per una
+serie di proprietà generali dei processi (come l'elenco dei PID, l'albero dei
+file, dei \textit{mount point}, della rete, ecc.), che consentono di creare
+gruppi di processi che vivono in una sorta di spazio separato dagli altri, che
+costituisce poi quello che viene chiamato un \textit{container}.
+
+La \textit{system call} richiede soltanto due argomenti: il
+primo, \param{flags}, consente di controllare le modalità di creazione del
+nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo
+dello \itindex{stack} \textit{stack} per il nuovo \textit{task}, e deve essere
+indicato quando si intende creare un \textit{thread}. L'esecuzione del
+programma creato da \func{sys\_clone} riprende, come per \func{fork}, da
+dopo l'esecuzione della stessa.
+
+La necessità di avere uno \itindex{stack} \textit{stack} alternativo c'è solo
+quando si intende creare un \textit{thread}, in tal caso infatti il nuovo
+\textit{task} vede esattamente la stessa memoria del \textit{task}
+``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente
+ il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task}
+ da essa creato, senza nessuna delle implicazioni che il concetto ha per i
+ processi.} e nella sua esecuzione alla prima chiamata di una funzione
+andrebbe a scrivere sullo \textit{stack} usato anche dal padre (si ricordi
+quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso dello
+\textit{stack}).
+
+Per evitare di doversi garantire contro la evidente possibilità di
+\itindex{race~condition} \textit{race condition} che questa situazione
+comporta (vedi sez.~\ref{sec:proc_race_cond} per una spiegazione della
+problematica) è necessario che il chiamante allochi preventivamente un'area di
+memoria. In genere lo si fa con una \func{malloc} che allochi un buffer che
+la funzione imposterà come \textit{stack} del nuovo processo, avendo
+ovviamente cura di non utilizzarlo direttamente nel processo chiamante. In
+questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e
+non si dovranno affrontare problematiche di \itindex{race~condition}
+\textit{race condition}. Si tenga presente inoltre che in molte architetture
+di processore lo \textit{stack} cresce verso il basso, pertanto in tal caso
+non si dovrà specificare per \param{child\_stack} il puntatore restituito da
+\func{malloc}, ma un puntatore alla fine del buffer da essa allocato.
+
+Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la
+memoria, la \textit{system call}, a differenza della funzione di libreria che
+vedremo a breve, consente anche di passare per \param{child\_stack} il valore
+\val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
+processo, questo ottiene un suo nuovo spazio degli indirizzi,\footnote{è
+ sottinteso cioè che non si stia usando il flag \const{CLONE\_VM}.} ed in
+questo caso si applica la semantica del \itindex{copy~on~write} \textit{copy
+ on write} illustrata in sez.~\ref{sec:proc_fork}, per cui le pagine dello
+\textit{stack} verranno automaticamente copiate come le altre e il nuovo
+processo avrà un suo \textit{stack} totalmente indipendente da quello del
+padre.
+
+Dato che l'uso principale della nuova \textit{system call} è quello relativo
+alla creazione dei \textit{thread}, le \acr{glibc} definiscono una funzione di
+libreria con una sintassi diversa, orientata a questo scopo, e la
+\textit{system call} resta accessibile solo se invocata esplicitamente come
+visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa
+ \textit{system call} non è disponibile la chiamata veloce con
+ \texttt{vsyscall}.} La funzione di libreria si chiama semplicemente
+\funcd{clone} ed il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/sched.h}
+
+ \funcdecl{int clone(int (*fn)(void *), void *child\_stack, int
+ flags, void *arg, ... \\
+ /* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */)}
+
+ Crea un nuovo processo o \textit{thread} eseguendo la funzione \param{fn}.
+
+ \bodydesc{La funzione ritorna al chiamante il \textit{Thread ID} assegnato
+ al nuovo processo in caso di successo e $-1$ in caso di errore, nel qual
+ caso \var{errno} può assumere i valori:
+ \begin{errlist}
+ \item[\errcode{EAGAIN}] sono già in esecuzione troppi processi.
+ \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o
+ un valore nullo per \param{child\_stack}.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova
+ \struct{task\_struct} o per copiare le parti del contesto del chiamante
+ necessarie al nuovo \textit{task}.
+ \item[\errcode{EPERM}] non si hanno i privilegi di amministratore
+ richiesti dai flag indicati.
+ \end{errlist}
+ }
+\end{functions}
+
+La funzione prende come primo argomento il puntatore alla funzione che verrà
+messa in esecuzione nel nuovo processo, che può avere un unico argomento di
+tipo puntatore a \ctyp{void}, il cui valore viene passato dal terzo
+argomento \param{arg}; per quanto il precedente prototipo possa intimidire
+nella sua espressione, in realtà l'uso è molto semplice basterà definire una
+qualunque funzione \param{fn} del tipo indicato, e \code{fn(arg)} sarà
+eseguita in un nuovo processo.
+
+Il nuovo processo resterà in esecuzione fintanto che la funzione \param{fn}
+non ritorna, o esegue \func{exit} o viene terminata da un segnale. Il valore
+di ritorno della funzione (o quello specificato con \func{exit}) verrà
+utilizzato come stato di uscita della funzione.
+
+I tre argomenti \param{ptid}, \param{tls} e \param{ctid} sono opzionali e sono
+presenti solo a partire dal kernel 2.6.
+
+Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
+nuovo processo da essa creato, è controllato dall'argomento \param{flags},
+
+\begin{basedescript}{\desclabelstyle{\pushlabel}}
+
+\item[\const{CLONE\_CHILD\_CLEARTID}]
+\item[\const{CLONE\_CHILD\_SETTID}]
+\item[\const{CLONE\_FILES}]
+\item[\const{CLONE\_FS}]
+\item[\const{CLONE\_IO}]
+\item[\const{CLONE\_NEWIPC}]
+\item[\const{CLONE\_NEWNET}]
+\item[\const{CLONE\_NEWNS}]
+\item[\const{CLONE\_NEWPID}]
+\item[\const{CLONE\_NEWUTS}]
+\item[\const{CLONE\_PARENT}]
+\item[\const{CLONE\_PARENT\_SETTID}]
+\item[\const{CLONE\_PID}]
+\item[\const{CLONE\_PTRACE}]
+\item[\const{CLONE\_SETTLS}]
+\item[\const{CLONE\_SIGHAND}]
+\item[\const{CLONE\_STOPPED}]
+\item[\const{CLONE\_SYSVSEM}]
+\item[\const{CLONE\_THREAD}]
+\item[\const{CLONE\_UNTRACED}]
+\item[\const{CLONE\_VFORK}]
+\item[\const{CLONE\_VM}]
+\end{basedescript}
+
\subsection{La funzione \func{prctl}}
\label{sec:process_prctl}
la cui gestione è stata predisposta una apposita \textit{system call} che
fornisce una interfaccia generica per tutte le operazioni specialistiche. La
funzione è \funcd{prctl} ed il suo prototipo è:\footnote{la funzione non è
- standardizzata ed è specifica di Linux, anche se ne esiete una analoga in
- IRIX, è stata introdotta con il kernel 2.1.57.}
+ standardizzata ed è specifica di Linux, anche se ne esiste una analoga in
+ IRIX; è stata introdotta con il kernel 2.1.57.}
\begin{functions}
\headdecl{sys/prctl.h}
nell'argomento \param{arg2} con una delle costanti di
tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} del
processo. L'operazione richiede i privilegi di amministratore (la capacità
- \const{CAP\_SETPCAP}), altrimenti fallisce con un errore di \errval{EPERM};
- se il valore di \param{arg2} non è valido o se il supporto per le
- \textit{file capabilities} non è stato compilato nel kernel fallisce con un
- errore di \errval{EINVAL}. Introdotta a partire dal kernel 2.6.25.
+ \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di
+ \errval{EPERM}; se il valore di \param{arg2} non è valido o se il supporto
+ per le \textit{file capabilities} non è stato compilato nel kernel la
+ chiamata fallirà con un errore di \errval{EINVAL}. Introdotta a partire dal
+ kernel 2.6.25.
\item[\const{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la
terminazione di un processo a causa di un segnale per il quale è prevista la
generazione di un file di \itindex{core~dump} \textit{core dump} (vedi
lo stato corrente del flag che controlla la effettiva generazione dei
\itindex{core~dump} \textit{core dump}. Introdotta a partire dal kernel
2.3.20.
-\item[\const{PR\_SET\_ENDIAN}] Imposta la \textit{endianess} del processo
+\item[\const{PR\_SET\_ENDIAN}] Imposta la \textit{endianness} del processo
chiamante secondo il valore fornito in \param{arg2}. I valori possibili sono
sono: \const{PR\_ENDIAN\_BIG} (\textit{big endian}),
\const{PR\_ENDIAN\_LITTLE} (\textit{little endian}), e
\const{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
PowerPC). Introdotta a partire dal kernel 2.6.18, solo per architettura
PowerPC.
-\item[\const{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianess} del
+\item[\const{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianness} del
processo chiamante, salvato sulla variabile puntata da \param{arg2} che deve
- essere passata come di tipo \type{(int *)}. Introdotta a partire dal kernel
+ essere passata come di tipo \ctyp{(int *)}. Introdotta a partire dal kernel
2.6.18, solo su PowerPC.
\item[\const{PR\_SET\_FPEMU}] Imposta i bit di controllo per l'emulazione
della virgola mobile su architettura ia64, secondo il valore
di \param{arg2}, si deve passare \const{PR\_FPEMU\_NOPRINT} per emulare in
maniera trasparente l'accesso alle operazioni in virgola mobile, o
\const{PR\_FPEMU\_SIGFPE} per non emularle ed inviare il segnale
- \const{SIGFPE}. Introdotta a partire dal kernel 2.4.18, solo su ia64.
+ \signal{SIGFPE} (vedi sez.~\ref{sec:sig_prog_error}). Introdotta a partire
+ dal kernel 2.4.18, solo su ia64.
\item[\const{PR\_GET\_FPEMU}] Ottiene il valore dei flag di controllo
dell'emulazione della virgola mobile, salvato all'indirizzo puntato
da \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta a
per gli underflow, \const{PR\_FP\_EXC\_RES} per risultati non esatti,
\const{PR\_FP\_EXC\_INV} per operazioni invalide,
\const{PR\_FP\_EXC\_DISABLED} per disabilitare le eccezioni,
- \const{PR\_FP\_EXC\_NONRECOV} per utilizzare la modalità di eccesione
+ \const{PR\_FP\_EXC\_NONRECOV} per utilizzare la modalità di eccezione
asincrona non recuperabile, \const{PR\_FP\_EXC\_ASYNC} per utilizzare la
- modalità di eccesione asincrona recuperabile, \const{PR\_FP\_EXC\_PRECISE}
- per la modalita precisa di eccezione.\footnote{trattasi di gestione
+ modalità di eccezione asincrona recuperabile, \const{PR\_FP\_EXC\_PRECISE}
+ per la modalità precisa di eccezione.\footnote{trattasi di gestione
specialistica della gestione delle eccezioni dei calcoli in virgola mobile
che, i cui dettagli al momento vanno al di là dello scopo di questo
testo.} Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a
pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default)
per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano
- manenute, questo valore viene sempre cancellato attraverso una
- \func{exec}. L'uso di questo flag è stato sostituito, a partire dal kernel
- 2.6.26, dal flag \const{SECURE\_KEEP\_CAPS} dei \itindex{securebits}
- \textit{securebits} (vedi \const{PR\_SET\_SECUREBITS}). Introdotta a partire
+ mantenute, questo valore viene sempre cancellato attraverso una \func{exec}.
+ L'uso di questo flag è stato sostituito, a partire dal kernel 2.6.26, dal
+ flag \const{SECURE\_KEEP\_CAPS} dei \itindex{securebits} \textit{securebits}
+ (vedi l'uso di \const{PR\_SET\_SECUREBITS} più avanti). Introdotta a partire
dal kernel 2.2.18.
\item[\const{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione
il valore del flag di controllo impostato con
se più corto. Introdotta a partire dal kernel 2.6.9.
\item[\const{PR\_SET\_PDEATHSIG}] Consente di richiedere l'emissione di un
segnale, che sarà ricevuto dal processo chiamante, in occorrenza della
- terminazione del proprio processo padre.\footnote{in sostanza consente di
- invertire il ruolo di \const{SIGCHLD}.} Il valore di \param{arg2} deve
- indicare il numero del segnale, o 0 per disabilitare l'emissione. Il valore
- viene automaticamente cancellato per un processo figlio creato con
- \func{fork}. Introdotta a partire dal kernel 2.1.57.
+ terminazione del proprio processo padre; in sostanza consente di invertire
+ il ruolo di \signal{SIGCHLD}. Il valore di \param{arg2} deve indicare il
+ numero del segnale, o 0 per disabilitare l'emissione. Il valore viene
+ automaticamente cancellato per un processo figlio creato con \func{fork}.
+ Introdotta a partire dal kernel 2.1.57.
\item[\const{PR\_GET\_PDEATHSIG}] Ottiene il valore dell'eventuale segnale
emesso alla terminazione del padre, salvato all'indirizzo
puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta a
processo potrà utilizzare soltanto un insieme estremamente limitato di
\textit{system call}: \func{read}, \func{write}, \func{\_exit} e
\func{sigreturn}, ogni altra \textit{system call} porterà all'emissione di
- un \func{SIGKILL}. Il \textit{secure computing mode} è stato ideato per
- fornire un supporto per l'esecuzione di codice esterno non fidato e non
- verificabile a scopo di calcolo;\footnote{lo scopo è quello di poter vendere
- la capacità di calcolo della proprio macchina ad un qualche servizio di
- calcolo distribuito senza comprometterne la sicurezza eseguendo codice non
- sotto il proprio controllo.} in genere i dati vengono letti o scritti
- grazie ad un socket o una pipe, e per evitare problemi di sicurezza non sono
- possibili altre operazioni se non quelle citate. Introdotta a partire dal
- kernel 2.6.23, disponibile solo se si è abilitato il supporto nel kernel con
+ un \func{SIGKILL} (vedi sez.~\ref{sec:sig_termination}). Il \textit{secure
+ computing mode} è stato ideato per fornire un supporto per l'esecuzione di
+ codice esterno non fidato e non verificabile a scopo di calcolo;\footnote{lo
+ scopo è quello di poter vendere la capacità di calcolo della proprio
+ macchina ad un qualche servizio di calcolo distribuito senza
+ comprometterne la sicurezza eseguendo codice non sotto il proprio
+ controllo.} in genere i dati vengono letti o scritti grazie ad un socket o
+ una pipe, e per evitare problemi di sicurezza non sono possibili altre
+ operazioni se non quelle citate. Introdotta a partire dal kernel 2.6.23,
+ disponibile solo se si è abilitato il supporto nel kernel con
\texttt{CONFIG\_SECCOMP}.
\item[\const{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
lo stato corrente del \textit{secure computing mode}, al momento attuale la
comporterebbe l'emissione di \texttt{SIGKILL}, è stata comunque definita per
eventuali estensioni future. Introdotta a partire dal kernel 2.6.23.
\item[\const{PR\_SET\_SECUREBITS}] Imposta i \itindex{securebits}
- \textit{securebits} per il processo corrente al valore indicato
- da \param{arg2}; per i dettagli si veda sez.~\ref{sec:proc_capabilities}, ed
- in particolare i valori di tab.~\ref{tab:securebits_values} e la relativa
- trattazione. Introdotta a partire dal kernel 2.6.26.
+ \textit{securebits} per il processo chiamante al valore indicato
+ da \param{arg2}; per i dettagli sul significato dei \textit{securebits} si
+ veda sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di
+ tab.~\ref{tab:securebits_values} e la relativa trattazione. L'operazione
+ richiede i privilegi di amministratore (la capacità \const{CAP\_SETPCAP}),
+ altrimenti la chiamata fallirà con un errore di \errval{EPERM}. Introdotta a
+ partire dal kernel 2.6.26.
\item[\const{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della
funzione l'impostazione corrente per i \itindex{securebits}
\textit{securebits}. Introdotta a partire dal kernel 2.6.26.
\item[\const{PR\_GET\_TIMING}] Ottiene come valore di ritorno della funzione
il metodo di temporizzazione del processo attualmente in uso. Introdotta a
partire dal kernel 2.6.0-test4.
-\item[\const{PR\_SET\_TSC}] Imposta il flag che indica se il processo può
- leggere il registro di processore contenente il contatore dei
+\item[\const{PR\_SET\_TSC}] Imposta il flag che indica se il processo
+ chiamante può leggere il registro di processore contenente il contatore dei
\textit{timestamp} (TSC, o \textit{Time Stamp Counter}) da indicare con il
valore di \param{arg2}. Si deve specificare \const{PR\_TSC\_ENABLE} per
abilitare la lettura o \const{PR\_TSC\_SIGSEGV} per disabilitarla con la
- generazione di un segnale di \const{SIGSEGV}. La lettura viene
- automaticamente disabilitata se si attiva il \textit{secure computing mode}.
- Introdotta a partire dal kernel 2.6.26, solo su x86.
+ generazione di un segnale di \signal{SIGSEGV} (vedi
+ sez.~\ref{sec:sig_prog_error}). La lettura viene automaticamente
+ disabilitata se si attiva il \textit{secure computing mode}. Introdotta a
+ partire dal kernel 2.6.26, solo su x86.
\item[\const{PR\_GET\_TSC}] Ottiene il valore del flag che controlla la
- lettura del contatatore dei \textit{timestamp}, salvato all'indirizzo
+ lettura del contattore dei \textit{timestamp}, salvato all'indirizzo
puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta a
partire dal kernel 2.6.26, solo su x86.
% articoli sul TSC e relativi problemi: http://lwn.net/Articles/209101/,
% http://en.wikipedia.org/wiki/Time_Stamp_Counter
\item[\const{PR\_SET\_UNALIGN}] Imposta la modalità di controllo per l'accesso
a indirizzi di memoria non allineati, che in varie architetture risultano
- illegali, da indicare con il valore di \param{arg2}. Si deve specificare
- \const{PR\_UNALIGN\_NOPRINT} per ignorare gli accessi non allineati, e
- \const{PR\_UNALIGN\_SIGBUS} per generare un segnale di \const{SIGBUS} in
- caso di accesso non allineato. Introdotta con diverse versioni su diverse
- architetture.
+ illegali, da indicare con il valore di \param{arg2}. Si deve specificare il
+ valore \const{PR\_UNALIGN\_NOPRINT} per ignorare gli accessi non allineati,
+ ed il valore \const{PR\_UNALIGN\_SIGBUS} per generare un segnale di
+ \signal{SIGBUS} (vedi sez.~\ref{sec:sig_prog_error}) in caso di accesso non
+ allineato. Introdotta con diverse versioni su diverse architetture.
\item[\const{PR\_GET\_UNALIGN}] Ottiene il valore della modalità di controllo
per l'accesso a indirizzi di memoria non allineati, salvato all'indirizzo
puntato \param{arg2}, che deve essere di tipo \code{(int *)}. Introdotta con
diverse versioni su diverse architetture.
-\item[\const{PR\_MCE\_KILL}] Introdotta a partire dal kernel 2.6.32.
-\item[\const{PR\_MCE\_KILL\_GET}] Introdotta a partire dal kernel 2.6.32.
+\item[\const{PR\_MCE\_KILL}] Imposta la politica di gestione degli errori
+ dovuti a corruzione della memoria per problemi hardware. Questo tipo di
+ errori vengono riportati dall'hardware di controllo della RAM e vengono
+ gestiti dal kernel,\footnote{la funzionalità è disponibile solo sulle
+ piattaforme più avanzate che hanno il supporto hardware per questo tipo di
+ controlli.} ma devono essere opportunamente riportati ai processi che
+ usano quella parte di RAM che presenta errori; nel caso specifico questo
+ avviene attraverso l'emissione di un segnale di \signal{SIGBUS} (vedi
+ sez.~\ref{sec:sig_prog_error}).\footnote{in particolare viene anche
+ impostato il valore di \var{si\_code} in \struct{siginfo\_t} a
+ \const{BUS\_MCEERR\_AO}; per il significato di tutto questo si faccia
+ riferimento alla trattazione di sez.~\ref{sec:sig_sigaction}.}
+
+ Il comportamento di default prevede che per tutti i processi si applichi la
+ politica generale di sistema definita nel file
+ \procfile{/proc/sys/vm/memory\_failure\_early\_kill}, ma specificando
+ per \param{arg2} il valore \const{PR\_MCE\_KILL\_SET} è possibile impostare
+ con il contenuto di \param{arg3} una politica specifica del processo
+ chiamante. Si può tornare alla politica di default del sistema utilizzando
+ invece per \param{arg2} il valore \const{PR\_MCE\_KILL\_CLEAR}. In tutti i
+ casi, per compatibilità con eventuali estensioni future, tutti i valori
+ degli argomenti non utilizzati devono essere esplicitamente posti a zero,
+ pena il fallimento della chiamata con un errore di \errval{EINVAL}.
+
+ In caso di impostazione di una politica specifica del processo con
+ \const{PR\_MCE\_KILL\_SET} i valori di \param{arg3} possono essere soltanto
+ due, che corrispondono anche al valore che si trova nell'impostazione
+ generale di sistema di \texttt{memory\_failure\_early\_kill}, con
+ \const{PR\_MCE\_KILL\_EARLY} si richiede l'emissione immediata di
+ \signal{SIGBUS} non appena viene rilevato un errore, mentre con
+ \const{PR\_MCE\_KILL\_LATE} il segnale verrà inviato solo quando il processo
+ tenterà un accesso alla memoria corrotta. Questi due valori corrispondono
+ rispettivamente ai valori 1 e 0 di
+ \texttt{memory\_failure\_early\_kill}.\footnote{in sostanza nel primo caso
+ viene immediatamente inviato il segnale a tutti i processi che hanno la
+ memoria corrotta mappata all'interno del loro spazio degli indirizzi, nel
+ secondo caso prima la pagina di memoria viene tolta dallo spazio degli
+ indirizzi di ciascun processo, mentre il segnale viene inviato solo quei
+ processi che tentano di accedervi.} Si può usare per \param{arg3} anche un
+ terzo valore, \const{PR\_MCE\_KILL\_DEFAULT}, che corrisponde a impostare
+ per il processo la politica di default.\footnote{si presume la politica di
+ default corrente, in modo da non essere influenzati da un eventuale
+ successivo cambiamento della stessa.} Introdotta a partire dal kernel
+ 2.6.32.
+\item[\const{PR\_MCE\_KILL\_GET}] Ottiene come valore di ritorno della
+ funzione la politica di gestione degli errori dovuti a corruzione della
+ memoria. Tutti gli argomenti non utilizzati (al momento tutti) devono essere
+ nulli pena la ricezione di un errore di \errval{EINVAL}. Introdotta a
+ partire dal kernel 2.6.32.
\label{sec:prctl_operation}
\end{basedescript}
Da fare
+% TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1
+
+
\subsection{L'accesso alle porte di I/O}
\label{sec:process_io_port}
cap.~\ref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
sez.~\ref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
funzioni di libreria per compiere le operazioni necessarie è garanzia
-sufficiente di atomicità in quanto le system call con cui esse sono realizzate
-non possono essere interrotte (o subire interferenze pericolose) da altri
-processi.
+sufficiente di atomicità in quanto le \textit{system call} con cui esse sono
+realizzate non possono essere interrotte (o subire interferenze pericolose) da
+altri processi.
Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
-stesso processo, e pure alcune system call, possono essere interrotti in
-qualunque momento, e le operazioni di un eventuale \textit{signal handler}
+stesso processo, e pure alcune \textit{system call}, possono essere interrotti
+in qualunque momento, e le operazioni di un eventuale \textit{signal handler}
sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
il solo accesso o l'assegnazione di una variabile possono non essere più
operazioni atomiche (torneremo su questi aspetti in
un'altra invocazione non fa altro che allocarne un'altra copia. Una funzione
può non essere rientrante quando opera su memoria che non è nello
\itindex{stack} \textit{stack}. Ad esempio una funzione non è mai rientrante
-se usa una variabile globale o statica.
+se usa una \index{variabili!globali} variabile globale o
+\index{variabili!statiche} statica.
Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
parte del programmatore.
In genere le funzioni di libreria non sono rientranti, molte di esse ad
-esempio utilizzano variabili statiche, le \acr{glibc} però mettono a
-disposizione due macro di compilatore,\footnote{si ricordi quanto illustrato
- in sez.~\ref{sec:intro_gcc_glibc_std}.} \macro{\_REENTRANT} e
-\macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
-varie funzioni di libreria, che sono identificate aggiungendo il suffisso
-\code{\_r} al nome della versione normale.
+esempio utilizzano \index{variabili!statiche} variabili statiche, le
+\acr{glibc} però mettono a disposizione due macro di compilatore,\footnote{si
+ ricordi quanto illustrato in sez.~\ref{sec:intro_gcc_glibc_std}.}
+\macro{\_REENTRANT} e \macro{\_THREAD\_SAFE}, la cui definizione attiva le
+versioni rientranti di varie funzioni di libreria, che sono identificate
+aggiungendo il suffisso \code{\_r} al nome della versione normale.
\index{funzioni!rientranti|)}
% LocalWords: CONTINUED sources forking Spawned successfully executing exiting
% LocalWords: next cat for COMMAND pts bash defunct TRAPPED DUMPED Killable PR
% LocalWords: SIGKILL static RLIMIT preemption PREEMPT VOLUNTARY IDLE RTPRIO
-% LocalWords: Completely Fair compat Uniform CFQ Queuing elevator dev cfq RT
-% LocalWords: Documentation block syscall ioprio IPRIO CLASS class best effort
-% LocalWords: refresh semop dnotify MADV DONTFORK prctl WCLONE SIGCHL WALL
-% LocalWords: WNOTHREAD DUMPABLE KEEPCAPS
+% LocalWords: completely fair compat uniform CFQ queuing elevator dev cfq RT
+% LocalWords: documentation block syscall ioprio IPRIO CLASS class best effort
+% LocalWords: refresh semop dnotify MADV DONTFORK prctl WCLONE WALL big mount
+% LocalWords: WNOTHREAD DUMPABLE KEEPCAPS IRIX CAPBSET endianness endian flags
+% LocalWords: little PPC PowerPC FPEMU NOPRINT SIGFPE FPEXC point FP SW malloc
+% LocalWords: exception EXC ENABLE OVF overflow UND underflow RES INV DISABLED
+% LocalWords: NONRECOV ASYNC KEEP securebits NAME NUL PDEATHSIG SECCOMP VM FS
+% LocalWords: secure computing sigreturn TIMING STATISTICAL TSC MCE conditions
+% LocalWords: timestamp Stamp SIGSEGV UNALIGN SIGBUS MCEERR AO failure early
+% LocalWords: namespace vsyscall SETTID FILES NEWIPC NEWNET NEWNS NEWPID ptid
+% LocalWords: NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff