Aggiunte mknod e mkfifo, e fatta una passata di ispell

[gapil.git] / prochand.tex

diff --git a/prochand.tex b/prochand.tex
index e632e248d6632736c00daa4ec64ffc301623d96e..adf67a3052c38bf7512bbc7ce417055a3b98de5d 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -118,19 +118,19 @@ alla cui base c'
 \label{sec:proc_handling_intro}
 
 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è
 \label{sec:proc_handling_intro}
 
 I processi vengono creati dalla funzione \func{fork}; in molti unix questa è

-una system call, Linux però usa un'altra nomenclatura, e la funzione fork è
-basata a sua volta sulla system call \func{\_\_clone}, che viene usata anche
-per generare i \textit{thread}.  Il processo figlio creato dalla \func{fork} è
-una copia identica del processo processo padre, ma ha nuovo \acr{pid} e viene
-eseguito in maniera indipendente (le differenze fra padre e figlio sono
-affrontate in dettaglio in \secref{sec:proc_fork}).
+una system call, Linux però usa un'altra nomenclatura, e la funzione
+\func{fork} è basata a sua volta sulla system call \func{\_\_clone}, che viene
+usata anche per generare i \textit{thread}.  Il processo figlio creato dalla
+\func{fork} è una copia identica del processo processo padre, ma ha nuovo
+\acr{pid} e viene eseguito in maniera indipendente (le differenze fra padre e
+figlio sono affrontate in dettaglio in \secref{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
 \secref{sec:proc_wait}); queste funzioni restituiscono anche una informazione
 abbastanza limitata (lo stato di terminazione) sulle cause della terminazione
 
 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
 \secref{sec:proc_wait}); queste funzioni restituiscono anche una informazione
 abbastanza limitata (lo stato di terminazione) sulle cause della terminazione

-del processo.
+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
 
 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


@@ -163,11 +163,12 @@ non ritorna mai (in quanto con essa viene eseguito un altro programma).
 \section{La gestione dei processi}
 \label{sec:proc_handling}
 
 \section{La gestione dei processi}
 \label{sec:proc_handling}
 

-In questa sezione tratteremo le funzioni per la gestione dei processi, a
-partire dalle funzioni elementari che permettono di leggerne gli
-identificatori, alle varie funzioni di manipolazione dei processi, che
-riguardano la loro creazione, terminazione, e la messa in esecuzione di altri
-programmi.
+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 fondamentali che si usano per la
+creazione e la terminazione dei processi, e per la messa in esecuzione degli
+altri programmi.

 
 
 \subsection{Gli identificatori dei processi}
 
 
 \subsection{Gli identificatori dei processi}


@@ -176,7 +177,7 @@ programmi.
 Come accennato nell'introduzione ogni processo viene identificato dal sistema
 da un numero identificativo unico, il \textit{process id} o \acr{pid};
 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
 Come accennato nell'introduzione ogni processo viene identificato dal sistema
 da un numero identificativo unico, il \textit{process id} o \acr{pid};
 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un

-intero con segno (nel caso di Linux e delle glibc il tipo usato è \type{int}).
+intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è \type{int}).

 
 Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
 processo viene creato, fino ad un limite massimo (in genere essendo detto
 
 Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
 processo viene creato, fino ad un limite massimo (in genere essendo detto


@@ -216,12 +217,13 @@ o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
 un processo e le varie relazioni fra processi utilizzate per definire una
 sessione.
 
 un processo e le varie relazioni fra processi utilizzate per definire una
 sessione.
 

-Oltre al \acr{pid} e al \acr{ppid}, e a quelli usati per il controllo di
-sessione, ad ogni processo sono associati altri identificatori, usati per il
-controllo di accesso, che servono per determinare se il processo può o meno
-eseguire le operazioni richieste, a seconda dei privilegi e dell'identità di
-chi lo ha posto in esecuzione; su questi torneremo in dettagli più avanti in
-\secref{sec:proc_perms}.
+Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
+\secref{sec:sess_xxx}, 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 \secref{sec:proc_perms}.

 
 
 \subsection{La funzione \func{fork}}
 
 
 \subsection{La funzione \func{fork}}


@@ -259,24 +261,21 @@ padre, ma la memoria 
   di testo, che è identico, è condiviso e tenuto in read-only, Linux poi
   utilizza la tecnica del \textit{copy-on-write}, per cui la memoria degli
   altri segmenti viene copiata dal kernel per il nuovo processo solo in caso
   di testo, che è identico, è condiviso e tenuto in read-only, Linux poi
   utilizza la tecnica del \textit{copy-on-write}, per cui la memoria degli
   altri segmenti viene copiata dal kernel per il nuovo processo solo in caso

-  di scrittura, rendendo molto più efficiente il meccanismo} pertanto padre e
-figlio vedono variabili diverse.
+  di scrittura, rendendo molto più efficiente il meccanismo della creazione di
+  un nuovo processo}, pertanto padre e figlio vedono variabili diverse.

 
 La differenza che si ha nei due processi è che nel processo padre il valore di
 
 La differenza che si ha nei due processi è che nel processo padre il valore di

-ritorno della funzione 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. La sola differenza che si
-ha nei due processi è il valore di ritorno restituito dalla funzione, che nel
-padre è il \acr{pid} del figlio mentre nel figlio è zero; in questo modo il
-programma può identificare se viene eseguito dal padre o dal figlio.
-
-La scelta di questi valori non è casuale, un processo infatti può avere più
-figli, ed il valore di ritorno di \func{fork} è l'unico modo che 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
-\secref{sec:proc_pid}) e si usa il valore nullo, che non può essere il
-\acr{pid} di nessun processo.
+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. 
+
+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 \secref{sec:proc_pid}) per cui si usa il valore nullo,
+che non è il \acr{pid} di nessun processo.

 
 \begin{figure}[!htb]
   \footnotesize
 
 \begin{figure}[!htb]
   \footnotesize


@@ -333,9 +332,7 @@ int main(int argc, char *argv[])
 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
 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 (il valore della costante
-\macro{CHILD\_MAX} definito in \file{limits.h}, che fa riferimento ai processo
-con lo stesso \textit{real user id}).
+sul numero totale di processi permessi all'utente (vedi \secref{sec:sys_xxx}).

 
 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
 quella in cui all'interno di un programma si creano processi figli per
 
 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
 quella in cui all'interno di un programma si creano processi figli per


@@ -352,13 +349,14 @@ parleremo in \secref{sec:proc_exec}) subito dopo la \func{fork}.
 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato

-scelto di mantenere questa separazione, dato che, come visto per la prima
-modalità d'uso, esistono numerosi scenari in cui si può usare una \func{fork}
-senza bisogno di una \func{exec}. Inoltre anche nel caso della seconda
-modalità di operazioni, avere le due funzioni separate permette al figlio di
+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à di uso, avere le due funzioni separate permette al figlio di

 cambiare gli attributi del processo (maschera dei segnali, redirezione
 cambiare gli attributi del processo (maschera dei segnali, redirezione

-dell'output, \textit{user id}) prima della \func{exec}, rendendo molto più
-flessibile la possibilità di modificare gli attributi del nuovo processo.
+dell'output, \textit{user id}) prima della \func{exec}, rendendo così
+relativamente facile intervenire sulle le modalità di esecuzione del nuovo
+programma.

 
 In \curfig\ si è riportato il corpo del codice del programma di esempio
 \cmd{forktest}, che ci permette di illustrare molte caratteristiche dell'uso
 
 In \curfig\ si è riportato il corpo del codice del programma di esempio
 \cmd{forktest}, che ci permette di illustrare molte caratteristiche dell'uso


@@ -427,14 +425,15 @@ Pertanto non si pu
 istruzioni del codice fra padre e figli, nè sull'ordine in cui questi potranno
 essere messi in esecuzione, e se è necessaria una qualche forma di precedenza
 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
 istruzioni del codice fra padre e figli, nè sull'ordine in cui questi potranno
 essere messi in esecuzione, e se è necessaria una qualche forma di precedenza
 occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il

-rischio di incorrere nelle cosiddette \textit{race conditions}.
+rischio di incorrere nelle cosiddette \textit{race condition} \index{race
+  condition} (vedi \secref{sec:proc_race_cond}.

 
 

-Si noti inoltre che, come accennato, 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 33}) sono
-visibili solo al loro interno, 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).
+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 33}) sono visibili solo
+a loro, 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
 
 Un secondo aspetto molto importante nella creazione dei processi figli è
 quello dell'interazione dei vari processi con i file; per illustrarlo meglio


@@ -475,20 +474,22 @@ Il comportamento delle varie funzioni di interfaccia con i file 
 in gran dettaglio in \capref{cha:file_unix_interface} e in
 \secref{cha:files_std_interface}. Qui basta accennare che si sono usate le
 funzioni standard della libreria del C che prevedono l'output bufferizzato; e
 in gran dettaglio in \capref{cha:file_unix_interface} e in
 \secref{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 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 a capo).
+questa bufferizzazione (di veda \secref{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
 
 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, per questo
+non avviene più alla fine di ogni riga e l'output resta nel buffer. Per questo

 motivo, 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 all'uscita del figlio il buffer
 viene scritto su disco, troveremo nel file anche tutto quello che il processo
 motivo, 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 all'uscita del figlio il buffer
 viene scritto su disco, 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, troviamo anche l'output del padre.
+padre aveva scritto prima della sua creazione.  E solo alla fine del file,
+dato che in questo caso il padre esce per ultimo, troveremo anche l'output del
+padre.

 
 Ma l'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i
 file, che era valido anche per l'esempio precedente, ma meno evidente; il
 
 Ma l'esempio ci mostra un'altro aspetto fondamentale dell'interazione con i
 file, che era valido anche per l'esempio precedente, ma meno evidente; il


@@ -503,62 +504,66 @@ lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha
 la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione
 \func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file
 descriptor aperti nel padre, il che comporta che padre e figli condividono le
 la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione
 \func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file
 descriptor aperti nel padre, il che comporta che padre e figli condividono le

-stesse voci della file table (per la spiegazione di questi termini si veda
-\secref{sec:file_sharing}) e quindi anche l'offset corrente nel file.
-
-In questo modo se un processo scrive sul file aggiornerà l'offset sulla file
-table, e tutti gli altri processi che condividono la 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).
+stesse voci della \textit{file table} (per la spiegazione di questi termini si
+veda \secref{sec:file_sharing}) e fra cui c'è anche la posizione corrente nel
+file.
+
+In questo modo se un processo scrive sul file aggiornerà la posizione corrente
+sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
+\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
 
 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre

-crea un figlio ed attende la sua conclusione per proseguire, ed entrambi
-scrivono sullo stesso file, ad esempio lo standard output (un caso tipico è la
-shell). Se l'output viene rediretto con questo comportamento avremo che il
-padre potrà continuare a scrivere automaticamente in coda a quanto scritto dal
-figlio; se così non fosse ottenere questo comportamento sarebbe estremamente
-complesso necessitando di una qualche forma di comunicazione fra i due
-processi.
+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.

 
 In generale comunque non è buona norma far scrivere più processi sullo stesso
 
 In generale comunque non è buona norma far scrivere più processi sullo stesso

-file senza una qualche forma di sincronizzazione in quanto, come visto con il
-nostro esempio, le varie scritture risulteranno mescolate fra loro in una
-sequenza impredicibile. Le modalità con cui in genere si usano i file dopo una
-\func{fork} sono sostanzialmente due:
+file senza una qualche forma di sincronizzazione in quanto, come visto anche
+con il nostro esempio, le varie scritture risulteranno mescolate fra loro in
+una sequenza impredicibile. Per questo le modalità con cui in genere si usano
+i file dopo una \func{fork} sono sostanzialmente due:

 \begin{enumerate}
 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
   è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione
 \begin{enumerate}
 \item Il processo padre aspetta la conclusione del figlio. In questo caso non
   è necessaria nessuna azione riguardo ai file, in quanto la sincronizzazione

-  degli offset dopo eventuali operazioni di lettura e scrittura effettuate dal
-  figlio è automatica.
+  della posizione corrente dopo eventuali operazioni di lettura e scrittura
+  effettuate dal figlio è automatica.

 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso
 \item L'esecuzione di padre e figlio procede indipendentemente. In questo caso

-  ciascuno dei due deve chiudere i file che non gli servono una volta che la
-  \func{fork} è stata eseguita, per evitare ogni forma di interferenza.
+  ciascuno dei due processi deve chiudere i file che non gli servono una volta
+  che la \func{fork} è stata eseguita, per evitare ogni forma di interferenza.

 \end{enumerate}
 
 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
 comune dopo l'esecuzione di una \func{fork} è la seguente:
 \begin{itemize*}
 \end{enumerate}
 
 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
 proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
 comune dopo l'esecuzione di una \func{fork} è la seguente:
 \begin{itemize*}

-\item i file aperti e gli eventuali flag di \textit{close-on-exec} (vedi
-\secref{sec:proc_exec} e \secref{sec:file_fcntl}) se settati.
+\item i file aperti e gli eventuali flag di \textit{close-on-exec} settati
+  (vedi \secref{sec:proc_exec} e \secref{sec:file_fcntl}).

 \item gli identificatori per il controllo di accesso: il \textit{real user
     id}, il \textit{real group id}, l'\textit{effective user id},
 \item gli identificatori per il controllo di accesso: il \textit{real user
     id}, il \textit{real group id}, l'\textit{effective user id},

-  l'\textit{effective group id} e i \textit{supplementary group id} (vedi
+  l'\textit{effective group id} ed i \textit{supplementary group id} (vedi

   \secref{sec:proc_user_group}).
 \item gli identificatori per il controllo di sessione: il \textit{process
   \secref{sec:proc_user_group}).
 \item gli identificatori per il controllo di sessione: il \textit{process

-    group id} e il \textit{session id} e il terminale di controllo (vedi
+    group id} e il \textit{session id} ed il terminale di controllo (vedi

   \secref{sec:sess_xxx} e \secref{sec:sess_xxx}).
 \item i flag di \acr{suid} e \acr{sgid} (vedi \secref{sec:file_suid_sgid}).
 \item la directory di lavoro e la directory radice (vedi
   \secref{sec:sess_xxx} e \secref{sec:sess_xxx}).
 \item i flag di \acr{suid} e \acr{sgid} (vedi \secref{sec:file_suid_sgid}).
 \item la directory di lavoro e la directory radice (vedi

-  \secref{sec:file_work_dir}).
+  \secref{sec:file_work_dir} e \secref{sec:file_chroot}).

 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
 \item la maschera dei segnali bloccati e le azioni installate  (vedi
 \secref{sec:sig_xxx}).
 \item i segmenti di memoria condivisa agganciati al processo (vedi
 \secref{sec:ipc_xxx}). 
 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
 \item la maschera dei segnali bloccati e le azioni installate  (vedi
 \secref{sec:sig_xxx}).
 \item i segmenti di memoria condivisa agganciati al processo (vedi
 \secref{sec:ipc_xxx}). 

-\item i limiti sulle risorse (vedi  \secref{sec:sys_xxx}).
+\item i limiti sulle risorse (vedi \secref{sec:sys_xxx}).

 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
 \end{itemize*}
 le differenze fra padre e figlio dopo la \func{fork} invece sono:
 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
 \end{itemize*}
 le differenze fra padre e figlio dopo la \func{fork} invece sono:


@@ -594,7 +599,7 @@ venne introdotta in BSD per migliorare le prestazioni.
 
 Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è
 assolutamente trascurabile, e l'uso di questa funzione (che resta un caso
 
 Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è
 assolutamente trascurabile, e l'uso di questa funzione (che resta un caso

-speciale della funzione \func{clone}), è deprecato, per questo eviteremo di
+speciale della funzione \func{clone}), è deprecato; per questo eviteremo di

 trattarla ulteriormente.
 
 
 trattarla ulteriormente.
 
 


@@ -602,7 +607,7 @@ trattarla ulteriormente.
 \label{sec:proc_termination}
 
 In \secref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
 \label{sec:proc_termination}
 
 In \secref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui

-concludere un programma, ma dal punto di vista del programma stesso; avendo a
+chiudere un programma, ma dal punto di vista del programma stesso; avendo a

 che fare con un sistema multitasking occorre adesso affrontare l'argomento dal
 punto di vista generale di come il sistema gestisce la conclusione dei
 processi.
 che fare con un sistema multitasking occorre adesso affrontare l'argomento dal
 punto di vista generale di come il sistema gestisce la conclusione dei
 processi.


@@ -626,11 +631,12 @@ 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:
 \begin{itemize*}
 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 descrittori dei file sono chiusi.
+\item tutti i file descriptor sono chiusi.

 \item viene memorizzato lo stato di terminazione del processo.
 \item viene memorizzato lo stato di terminazione del processo.

-\item ad ogni processo figlio viene assegnato un nuovo padre.
+\item ad ogni processo figlio viene assegnato un nuovo padre (in genere
+  \cmd{init}).

 \item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi
 \item viene inviato il segnale \macro{SIGCHLD} al processo padre (vedi

-  \secref{sec:sig_xxx}) .
+  \secref{sec:sig_xxx}).

 \item se il processo è un leader di sessione viene mandato un segnale di
   \macro{SIGHUP} a tutti i processi in background e il terminale di
   controllo viene disconnesso (vedi \secref{sec:sess_xxx}).
 \item se il processo è un leader di sessione viene mandato un segnale di
   \macro{SIGHUP} a tutti i processi in background e il terminale di
   controllo viene disconnesso (vedi \secref{sec:sess_xxx}).


@@ -642,16 +648,16 @@ eseguite alla chiusura di un processo 
 ma al di la di queste operazioni è necessario poter disporre di un meccanismo
 ulteriore che consenta di sapere come questa terminazione è avvenuta; dato che
 in un sistema unix-like tutto viene gestito attraverso i processi il
 ma al di la di queste operazioni è necessario poter disporre di un meccanismo
 ulteriore che consenta di sapere come questa 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
-(\textit{termination status}) di cui sopra al processo padre.
+meccanismo scelto consiste nel riportare lo stato di terminazione (il
+cosiddetto \textit{termination status}) al processo padre.

 
 

-Nel caso di conclusione normale, 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.  
+Nel caso di conclusione normale, abbiamo visto in \secref{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.

 
 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
 quello che contraddistingue lo stato di chiusura del processo e viene
 
 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
 quello che contraddistingue lo stato di chiusura del processo e viene


@@ -708,15 +714,15 @@ informazioni riguardo ai processi che sta terminando.
 
 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
 
 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 \secref{sec:sys_unix_time}) e lo stato di terminazione
-\footnote{NdA verificare esattamente cosa c'è!}, 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 \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 \cmd{Z} nella colonna che ne indica lo stato. Quando il padre
-effettuerà la lettura dello stato di uscita anche questa informazione, non più
-necessaria, verrà scartata e la terminazione potrà dirsi completamente
+dal processo (vedi \secref{sec:sys_unix_time}) e lo stato di
+terminazione\footnote{NdA verificare esattamente cosa c'è!}, 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 \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. 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.
 
 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
 conclusa.
 
 Possiamo utilizzare il nostro programma di prova per analizzare anche questa


@@ -781,7 +787,7 @@ prototipo 
 \begin{functions}
 \headdecl{sys/types.h}
 \headdecl{sys/wait.h}
 \begin{functions}
 \headdecl{sys/types.h}
 \headdecl{sys/wait.h}

-\funcdecl{pid\_t wait(int * status)} 
+\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. 
 
 Sospende il processo corrente finché un figlio non è uscito, o finché un
 segnale termina il processo o chiama una funzione di gestione. 


@@ -795,9 +801,9 @@ caso di errore; \var{errno} pu
 }
 \end{functions}
 \noindent
 }
 \end{functions}
 \noindent

-è presente fin dalle prime versioni di unix; la funzione ritorna alla
-conclusione del primo figlio (o immediatamente se un figlio è già
-uscito). Se un figlio è già uscito la funzione ritorna immediatamente.
+è presente fin dalle prime versioni di unix; la funzione ritorna non appena un
+processo figlio termina. Se un figlio è già terminato la funzione ritorna
+immediatamente.

 
 Al ritorno lo stato di termininazione del processo viene salvato nella
 variabile puntata da \var{status} e tutte le informazioni relative al
 
 Al ritorno lo stato di termininazione del processo viene salvato nella
 variabile puntata da \var{status} e tutte le informazioni relative al


@@ -816,11 +822,11 @@ Per questo motivo lo standard POSIX.1 ha introdotto la funzione \func{waitpid}
 che effettua lo stesso servizio, ma dispone di una serie di funzionalità più
 ampie, legate anche al controllo di sessione.  Dato che è possibile ottenere
 lo stesso comportamento di \func{wait} si consiglia di utilizzare sempre
 che effettua lo stesso servizio, ma dispone di una serie di funzionalità più
 ampie, legate anche al controllo di sessione.  Dato che è possibile ottenere
 lo stesso comportamento di \func{wait} si consiglia di utilizzare sempre

-questa funzione; il suo prototipo è:
+questa funzione, il cui prototipo è:

 \begin{functions}
 \headdecl{sys/types.h}
 \headdecl{sys/wait.h}
 \begin{functions}
 \headdecl{sys/types.h}
 \headdecl{sys/wait.h}

-\funcdecl{pid\_t waitpid(pid\_t pid, int * status, int options)} 
+\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
 Attende la conclusione di un processo figlio.
 
 \bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se


@@ -927,15 +933,15 @@ certezza che la chiamata a \func{wait} non si bloccher
   \label{tab:proc_status_macro}
 \end{table}
 
   \label{tab:proc_status_macro}
 \end{table}
 

-Entrambe le funzioni restituiscono lo stato di terminazione del processo
-tramite il puntatore \var{status} (se non interessa memorizzare lo stato si
-può passare un puntatore nullo). Il valore restituito da entrambe le funzioni
-dipende dall'implementazione, e tradizionalmente alcuni bit sono riservati per
-memorizzare lo stato di uscita (in genere 8) altri per indicare il segnale che
-ha causato la terminazione (in caso di conclusione anomala), uno per indicare
-se è stato generato un core file, etc.\footnote{le definizioni esatte si
-  possono trovare in \file{<bits/waitstatus.h} ma questo file non deve mai
-  essere usato direttamente, esso viene incluso attraverso
+Entrambe le funzioni di attesa restituiscono lo stato di terminazione del
+processo tramite il puntatore \var{status} (se non interessa memorizzare lo
+stato si può passare un puntatore nullo). Il valore restituito da entrambe le
+funzioni dipende dall'implementazione, e tradizionalmente alcuni bit sono
+riservati per memorizzare lo stato di uscita (in genere 8) altri per indicare
+il segnale che ha causato la terminazione (in caso di conclusione anomala),
+uno per indicare se è stato generato un core file, ecc\footnote{le
+  definizioni esatte si possono trovare in \file{<bits/waitstatus.h} ma questo
+  file non deve mai essere usato direttamente, esso viene incluso attraverso

   \file{<sys/wait.h>}}.  Lo standard POSIX.1 definisce una serie di macro di
 preprocessore da usare per analizzare lo stato di uscita; esse sono definite
 sempre in \file{<sys/wait.h>} ed elencate in \curtab\ (si tenga presente che
   \file{<sys/wait.h>}}.  Lo standard POSIX.1 definisce una serie di macro di
 preprocessore da usare per analizzare lo stato di uscita; esse sono definite
 sempre in \file{<sys/wait.h>} ed elencate in \curtab\ (si tenga presente che


@@ -944,8 +950,8 @@ da \var{status}).
 
 Si tenga conto che nel caso di conclusione anomala il valore restituito da
 \macro{WTERMSIG} può essere controllato contro le costanti definite in
 
 Si tenga conto che nel caso di conclusione anomala il valore restituito da
 \macro{WTERMSIG} può essere controllato contro le costanti definite in

-\file{signal.h}, e stampato usando le funzioni definite in
-\secref{sec:sig_strsignal}.
+\file{signal.h} ed elencate in \tabref{tab:sig_signal_list}, e stampato usando
+le apposite funzioni trattate in \secref{sec:sig_strsignal}.

 
 
 \subsection{Le funzioni \func{wait3} e \func{wait4}}
 
 
 \subsection{Le funzioni \func{wait3} e \func{wait4}}


@@ -954,9 +960,9 @@ Si tenga conto che nel caso di conclusione anomala il valore restituito da
 Linux, seguendo una estensione di BSD, supporta altre due funzioni per la
 lettura dello stato di terminazione di un processo, analoghe a \func{wait} e
 \func{waitpid}, ma che prevedono un ulteriore parametro attraverso il quale il
 Linux, seguendo una estensione di BSD, supporta altre due funzioni per la
 lettura dello stato di terminazione di un processo, analoghe a \func{wait} e
 \func{waitpid}, ma che prevedono un ulteriore parametro attraverso il quale il

-kernel può restituire al processo padre ulteriori informazioni sulle risorse
-usate dal processo terminato e dai vari figli.  Queste funzioni, che diventano
-accessibili definendo la costante \macro{\_USE\_BSD}, sono:
+kernel può restituire al padre informazioni sulle risorse usate dal processo
+terminato e dai vari figli.  Queste funzioni, che diventano accessibili
+definendo la costante \macro{\_USE\_BSD}, sono:

 \begin{functions}
   \headdecl{sys/times.h} 
   \headdecl{sys/types.h} 
 \begin{functions}
   \headdecl{sys/times.h} 
   \headdecl{sys/types.h} 


@@ -1019,18 +1025,18 @@ campi che sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime},
 \label{sec:proc_exec}
 
 Abbiamo già detto che una delle modalità principali con cui si utilizzano i
 \label{sec:proc_exec}
 
 Abbiamo già detto che una delle modalità principali con cui si utilizzano i

-processi in unix è quella di usarli per lanciare nuovi programmi: questo viene
+processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene

 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
 processo chiama una di queste funzioni esso viene completamente sostituito dal
 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
 fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
 processo chiama una di queste funzioni esso viene completamente sostituito dal
 nuovo programma; il \acr{pid} del processo non cambia, dato che non viene

-creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, o
+creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo

 heap, i dati ed il testo del processo corrente con un nuovo programma letto da
 disco. 
 
 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
 heap, i dati ed il testo del processo corrente con un nuovo programma letto da
 disco. 
 
 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata

-famiglia di funzioni) che possono essere usate per questo compito, che in
-realtà (come mostrato in \figref{fig:proc_exec_relat}), costituiscono un
-front-end a \func{execve}. Il prototipo  di quest'ultima è:
+famiglia di funzioni) che possono essere usate per questo compito, in realtà
+(come mostrato in \figref{fig:proc_exec_relat}), sono tutte un front-end a
+\func{execve}. Il prototipo di quest'ultima è:

 \begin{prototype}{unistd.h}
 {int execve(const char *filename, char *const argv[], char *const envp[])}
   Esegue il programma contenuto nel file \param{filename}.
 \begin{prototype}{unistd.h}
 {int execve(const char *filename, char *const argv[], char *const envp[])}
   Esegue il programma contenuto nel file \param{filename}.


@@ -1094,7 +1100,7 @@ le modalit
 argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
 dalla funzione \func{main} del programma chiamato). 
 
 argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
 dalla funzione \func{main} del programma chiamato). 
 

-Queste modalità sono due e sono riassunte dagli mnenonici \code{v} e \code{l}
+Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}

 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
 gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
 stringhe terminate con zero che costituiranno gli argomenti a riga di comando,


@@ -1103,7 +1109,7 @@ questo vettore \emph{deve} essere terminato da un puntatore nullo.
 Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
 lista di puntatori, nella forma:
 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
 Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
 lista di puntatori, nella forma:
 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}

-  char * arg0, char * arg1,  ..., char * argn, NULL
+  char *arg0, char *arg1,  ..., char *argn, NULL

 \end{lstlisting}
 che deve essere terminata da un puntatore nullo.  In entrambi i casi vale la
 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
 \end{lstlisting}
 che deve essere terminata da un puntatore nullo.  In entrambi i casi vale la
 convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato


@@ -1179,7 +1185,7 @@ la lista completa 
 \item il \textit{session ID} ed il \textit{process group ID} (vedi
   \secref{sec:sess_xxx}).
 \item il terminale di controllo (vedi \secref{sec:sess_xxx}).
 \item il \textit{session ID} ed il \textit{process group ID} (vedi
   \secref{sec:sess_xxx}).
 \item il terminale di controllo (vedi \secref{sec:sess_xxx}).

-\item il tempo restante ad un allarme.
+\item il tempo restante ad un allarme (vedi \secref{sec:sig_xxx}).

 \item la directory radice e la directory di lavoro corrente (vedi
   \secref{sec:file_work_dir}).
 \item la maschera di creazione dei file (\var{umask}, vedi
 \item la directory radice e la directory di lavoro corrente (vedi
   \secref{sec:file_work_dir}).
 \item la maschera di creazione dei file (\var{umask}, vedi


@@ -1187,7 +1193,7 @@ la lista completa 
   \secref{sec:file_locking}).
 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
   \secref{sec:sig_xxx}).
   \secref{sec:file_locking}).
 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
   \secref{sec:sig_xxx}).

-\item i limiti sulle risorse (vedi \secref{sec:sys_limits})..
+\item i limiti sulle risorse (vedi \secref{sec:sys_limits}).

 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
   \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).
 \end{itemize*}
 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
   \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).
 \end{itemize*}


@@ -1208,9 +1214,9 @@ esplicita a \func{fcntl} che setti il suddetto flag.
 
 Per le directory lo standard POSIX.1 richiede che esse vengano chiuse
 attraverso una \func{exec}, in genere questo è fatto dalla funzione
 
 Per le directory lo standard POSIX.1 richiede che esse vengano chiuse
 attraverso una \func{exec}, in genere questo è fatto dalla funzione

-\func{opendir} che effettua da sola il settaggio del flag di
-\textit{close-on-exec} sulle directory che apre, in maniera trasparente
-all'utente.
+\func{opendir} (vedi \secref{sec:file_dir_read}) che effettua da sola il
+settaggio del flag di \textit{close-on-exec} sulle directory che apre, in
+maniera trasparente all'utente.

 
 Abbiamo detto che il \textit{real user ID} ed il \textit{real group ID}
 restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
 
 Abbiamo detto che il \textit{real user ID} ed il \textit{real group ID}
 restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per


@@ -1234,7 +1240,7 @@ chiamato come se si fosse eseguito il comando \cmd{interpreter [arg]
   filename}.
 
 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
   filename}.
 
 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è

-basata la gestione dei processi in unix: con \func{fork} si crea un nuovo
+basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo

 processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
 \func{wait} si effettua e verifica la conclusione dei programmi. Tutte le
 altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari
 processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
 \func{wait} si effettua e verifica la conclusione dei programmi. Tutte le
 altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari


@@ -1249,7 +1255,7 @@ In questa sezione esamineremo le problematiche relative al controllo di
 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
 usati, come questi possono essere modificati nella creazione e nel lancio di
 nuovi processi, e le varie funzioni per la loro manipolazione diretta e tutte
 accesso dal punto di vista del processi; vedremo quali sono gli identificatori
 usati, come questi possono essere modificati nella creazione e nel lancio di
 nuovi processi, e le varie funzioni per la loro manipolazione diretta e tutte

-le problematiche connesse alla gestione accorta dei privilegi.
+le problematiche connesse ad una gestione accorta dei privilegi.

 
 
 \subsection{Utente e gruppo di un processo}
 
 
 \subsection{Utente e gruppo di un processo}


@@ -1279,14 +1285,14 @@ kernel nella gestione dei permessi di accesso.
 
 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
 evidente che per poter implementare un controllo sulle operazioni occorre
 
 Dato che tutte le operazioni del sistema vengono compiute dai processi, è
 evidente che per poter implementare un controllo sulle operazioni occorre

-anche poter identificare chi è che ha lanciato un certo processo, e pertanto
-anche a ciascuno di essi è associato un utente e a un gruppo. 
+anche poter identificare chi è che ha lanciato un certo programma, e pertanto
+anche a ciascun processo è associato un utente e a un gruppo.

 
 Un semplice controllo di una corrispondenza fra identificativi però non
 garantisce però sufficiente flessibilità per tutti quei casi in cui è
 necessario poter disporre di privilegi diversi, o dover impersonare un altro
 utente per un limitato insieme di operazioni. Per questo motivo in generale
 
 Un semplice controllo di una corrispondenza fra identificativi però non
 garantisce però sufficiente flessibilità per tutti quei casi in cui è
 necessario poter disporre di privilegi diversi, o dover impersonare un altro
 utente per un limitato insieme di operazioni. Per questo motivo in generale

-tutti gli unix prevedono che i processi abbiano almeno due gruppi di
+tutti gli Unix prevedono che i processi abbiano almeno due gruppi di

 identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}.
 
 \begin{table}[htb]
 identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}.
 
 \begin{table}[htb]


@@ -1341,13 +1347,13 @@ processo e per il controllo di accesso ai file (argomento affrontato in
 dettaglio in \secref{sec:file_perm_overview}). 
 
 Questi identificatori normalmente sono identici ai corrispondenti del gruppo
 dettaglio in \secref{sec:file_perm_overview}). 
 
 Questi identificatori normalmente sono identici ai corrispondenti del gruppo

-\textsl{reale} tranne nel caso in cui, come visto in \secref{sec:proc_exec},
-il programma che si è posto in esecuzione abbia i bit \acr{suid} o \acr{sgid}
-settati (il significato di questi bit è affrontato in dettaglio in
-\secref{sec:file_suid_sgid}). In questo caso essi saranno settati all'utente e
-al gruppo proprietari del file; questo consente, per programmi in cui ci sia
-necessità, di dare a qualunque utente normale privilegi o permessi di
-un'altro (o dell'amministratore).
+\textsl{reale} tranne nel caso in cui, come accennato in
+\secref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit
+\acr{suid} o \acr{sgid} settati (il significato di questi bit è affrontato in
+dettaglio in \secref{sec:file_suid_sgid}). In questo caso essi saranno settati
+all'utente e al gruppo proprietari del file; questo consente, per programmi in
+cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
+di un'altro (o dell'amministratore).

 
 Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
 possono essere letti dal processo attraverso delle opportune funzioni, i cui
 
 Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
 possono essere letti dal processo attraverso delle opportune funzioni, i cui


@@ -1381,7 +1387,7 @@ Questo in Linux viene fatto usando altri due gruppi di identificatori, il
 \textit{saved} ed il \textit{filesystem}, analoghi ai precedenti. Il primo
 gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è
 definita la costante \macro{\_POSIX\_SAVED\_IDS}\footnote{in caso si abbia a
 \textit{saved} ed il \textit{filesystem}, analoghi ai precedenti. Il primo
 gruppo è lo stesso usato in SVr4, e previsto dallo standard POSIX quando è
 definita la costante \macro{\_POSIX\_SAVED\_IDS}\footnote{in caso si abbia a

-  cuore la portabilità del programma su altri unix è buona norma controllare
+  cuore la portabilità del programma su altri Unix è buona norma controllare

   sempre la disponibilità di queste funzioni controllando se questa costante è
   definita}, il secondo gruppo è specifico di Linux e viene usato per
 migliorare la sicurezza con NFS.
   sempre la disponibilità di queste funzioni controllando se questa costante è
   definita}, il secondo gruppo è specifico di Linux e viene usato per
 migliorare la sicurezza con NFS.


@@ -1416,16 +1422,16 @@ di utente e gruppo associati dal kernel ad ogni processo, 
 Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
 di appartenenza) ad un processo sono rispettivamente \func{setuid} e
 \func{setgid}; come accennato in \secref{sec:proc_user_group} in Linux esse
 Le due funzioni che vengono usate per cambiare identità (cioè utente e gruppo
 di appartenenza) ad un processo sono rispettivamente \func{setuid} e
 \func{setgid}; come accennato in \secref{sec:proc_user_group} in Linux esse

-seguono la semantica POSIX che prevede l'esistenza di \textit{saved user id} e
-\textit{saved group id}; i loro prototipi sono:
+seguono la semantica POSIX che prevede l'esistenza del \textit{saved user id}
+e del \textit{saved group id}; i loro prototipi sono:

 \begin{functions}
 \headdecl{unistd.h}
 \headdecl{sys/types.h}
 
 \begin{functions}
 \headdecl{unistd.h}
 \headdecl{sys/types.h}
 

-\funcdecl{int setuid(uid\_t uid)} Setta l'\textit{user ID} del processo
+\funcdecl{int setuid(uid\_t uid)} Setta l'\textit{user id} del processo

 corrente.
 
 corrente.
 

-\funcdecl{int setgid(gid\_t gid)} Setta il \textit{group ID} del processo
+\funcdecl{int setgid(gid\_t gid)} Setta il \textit{group id} del processo

 corrente.
 
 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
 corrente.
 
 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso


@@ -1513,10 +1519,10 @@ ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
 \subsection{Le funzioni \func{setreuid} e \func{setresuid}}
 \label{sec:proc_setreuid}
 
 \subsection{Le funzioni \func{setreuid} e \func{setresuid}}
 \label{sec:proc_setreuid}
 

-Queste due funzioni derivano da BSD che non supportando\footnote{almeno fino
-  alla versione 4.3+BSD TODO, verificare e aggiornare la nota} i \textit{saved
-  id} le usava per poter scambiare fra di loro effective e real id. I
-prototipi sono:
+Queste due funzioni derivano da BSD che, non supportando\footnote{almeno fino
+  alla versione 4.3+BSD TODO, verificare e aggiornare la nota.} i
+\textit{saved id}, le usava per poter scambiare fra di loro \textit{effective}
+e \textit{real id}. I loro prototipi sono:

 \begin{functions}
 \headdecl{unistd.h}
 \headdecl{sys/types.h}
 \begin{functions}
 \headdecl{unistd.h}
 \headdecl{sys/types.h}


@@ -1557,12 +1563,12 @@ prima della \func{exec} per uniformare i \textit{real id} agli
 effettuare uno scambio e riottenere privilegi non previsti.
 
 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli
 effettuare uno scambio e riottenere privilegi non previsti.
 
 Lo stesso problema di propagazione dei privilegi ad eventuali processi figli

-si porrebbe per i \textit{saved id}. Queste funzioni derivano da
+si porrebbe per i \textit{saved id}: queste funzioni derivano da

 un'implementazione che non ne prevede la presenza, e quindi non è possibile
 un'implementazione che non ne prevede la presenza, e quindi non è possibile

-usarle per correggere la situazione come nel caso precedente, per questo
-motivo tutte le volte che uno degli identificatori viene modificato ad un
-valore diverso dal precedente \textit{real id}, il \textit{saved id} viene
-sempre settato al valore dell'\textit{effective id}.
+usarle per correggere la situazione come nel caso precedente. Per questo
+motivo in Linux tutte le volte che vengono usata per modificare uno degli
+identificatori ad un valore diverso dal \textit{real id} precedente, il
+\textit{saved id} viene sempre settato al valore dell'\textit{effective id}.

 
 
 \subsection{Le funzioni \func{setresuid} e \func{setresgid}}
 
 
 \subsection{Le funzioni \func{setresuid} e \func{setresgid}}


@@ -1601,7 +1607,7 @@ l'identificatore corrispondente.
 \label{sec:proc_seteuid}
 
 Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque
 \label{sec:proc_seteuid}
 
 Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque

-supportate dalla maggior parte degli unix) e usate per cambiare gli
+supportate dalla maggior parte degli Unix) e usate per cambiare gli

 \textit{effective id}; i loro prototipi sono:
 \begin{functions}
 \headdecl{unistd.h}
 \textit{effective id}; i loro prototipi sono:
 \begin{functions}
 \headdecl{unistd.h}


@@ -1643,7 +1649,8 @@ fatto cambiando l'\textit{effective id} o il \textit{real id} il server si
 espone alla ricezione di eventuali segnali ostili da parte dell'utente di cui
 ha temporaneamente assunto l'identità.  Cambiando solo il \textit{filesystem
   id} si ottengono i privilegi necessari per accedere ai file, mantenendo
 espone alla ricezione di eventuali segnali ostili da parte dell'utente di cui
 ha temporaneamente assunto l'identità.  Cambiando solo il \textit{filesystem
   id} si ottengono i privilegi necessari per accedere ai file, mantenendo

-quelli originari per quanto riguarda tutti gli altri controlli di accesso.
+quelli originari per quanto riguarda tutti gli altri controlli di accesso,
+così che l'utente non possa inviare segnali al server NFS.

 
 Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid}
 e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
 
 Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid}
 e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere


@@ -1660,10 +1667,9 @@ processo corrente a \var{fsgid}.
 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
   di fallimento: l'unico errore possibile è \macro{EPERM}.}
 \end{functions}
 \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso
   di fallimento: l'unico errore possibile è \macro{EPERM}.}
 \end{functions}

-
-Queste funzioni hanno successo solo se il processo chiamante ha i privilegi di
-amministratore o, per gli altri utenti, se il valore specificato coincide con
-uno dei \textit{real}, \textit{effective} o \textit{saved id}.
+\noindent queste funzioni hanno successo solo se il processo chiamante ha i
+privilegi di amministratore o, per gli altri utenti, se il valore specificato
+coincide con uno dei \textit{real}, \textit{effective} o \textit{saved id}.

 
 
 \section{Problematiche di programmazione multitasking}
 
 
 \section{Problematiche di programmazione multitasking}


@@ -1715,7 +1721,7 @@ Nel caso dei segnali invece la situazione 
 stesso processo, e pure alcune 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
 stesso processo, e pure alcune 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

-solo il solo accesso o l'assegnazione di una variabile possono non essere più
+il solo accesso o l'assegnazione di una variabile possono non essere più

 operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}).
 
 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
 operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}).
 
 In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},