\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}.
+\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}
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.
-\section{Le funzioni di base}% della gestione dei processi}
-\label{sec:proc_handling}
+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.
-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}
\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}[!htbp]
- \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}
-
-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;
+ 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*}
\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 \signal{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;
(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 \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}).
+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 è
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
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.\\
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}
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
+ \textit{stopped} & \texttt{T} & Il processo è stato fermato con un
\signal{SIGSTOP}, o è tracciato.\\
- \textbf{Zombie}\index{zombie} & \texttt{Z} & Il processo è terminato ma il
+ \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 \signal{SIGKILL} (usato per
lo più per NFS).\\
(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 è:
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
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}
La funzione tradizionale con cui creare un nuovo processo in un sistema
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 \ctyp{(int *)}. Introdotta a partire dal kernel
2.6.18, solo su PowerPC.
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
% 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 WALL big
-% LocalWords: WNOTHREAD DUMPABLE KEEPCAPS IRIX CAPBSET endianess endian flags
+% 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
+% 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