Correzioni per far andare pdflatex

[gapil.git] / prochand.tex

diff --git a/prochand.tex b/prochand.tex
index ef6c064a0552dcbfa657378321a7ce663b38fbfb..6e99c3cd56cd21ca618899c856e23edb9c77df06 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -8,16 +8,20 @@ base per l'allocazione e l'uso delle risorse del sistema.
 Nel precedente capitolo abbiamo visto come funziona un singolo processo, in
 questo capitolo affronteremo i dettagli della creazione e della distruzione
 dei processi, della gestione dei loro attributi e privilegi, e di tutte le
 Nel precedente capitolo abbiamo visto come funziona un singolo processo, in
 questo capitolo affronteremo i dettagli della creazione e della distruzione
 dei processi, della gestione dei loro attributi e privilegi, e di tutte le

-funzioni a questo connesse.
+funzioni a questo connesse. Infine nella sezione finale affronteremo alcune
+problematiche generiche della programmazione in ambiente multitasking.
+

 
 
 \section{Introduzione}
 \label{sec:proc_gen}
 
 Partiremo con una introduzione generale ai concetti che stanno alla base della
 
 
 \section{Introduzione}
 \label{sec:proc_gen}
 
 Partiremo con una introduzione generale ai concetti che stanno alla base della

-gestione dei processi in unix. Introdurremo in questa sezione l'architettura
-della gestione dei processi e le sue principali caratteristiche, e daremo una
-panoramica sull'uso delle principali funzioni per la gestione dei processi.
+gestione dei processi in un sistema unix-like. Introdurremo in questa sezione
+l'architettura della gestione dei processi e le sue principali
+caratteristiche, e daremo una panoramica sull'uso delle principali funzioni
+per la gestione dei processi.
+

 
 \subsection{La gerarchia dei processi}
 \label{sec:proc_hierarchy}
 
 \subsection{La gerarchia dei processi}
 \label{sec:proc_hierarchy}


@@ -183,7 +187,6 @@ Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
 \textit{parent process id}).  Questi due identificativi possono essere
 ottenuti da programma usando le funzioni:
 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
 \textit{parent process id}).  Questi due identificativi possono essere
 ottenuti da programma usando le funzioni:

-

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


@@ -207,7 +210,7 @@ Tutti i processi figli dello stesso processo padre sono detti
 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
   sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
   sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
 o relativi allo stesso login. Torneremo su questo argomento in dettaglio in

-\secref{cap:session}, dove esamineremo gli altri identificativi associati ad
+\secref{cha:session}, dove esamineremo gli altri identificativi associati ad

 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.
 


@@ -215,8 +218,8 @@ 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
 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 dettaglii più avanti in
-\secref{sec:proc_perm}.
+chi lo ha posto in esecuzione; su questi torneremo in dettagli più avanti in
+\secref{sec:proc_perms}.

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


@@ -227,7 +230,6 @@ processi: come si 
 attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale
 tutte le volte che si devono scrivere programmi che usano il multitasking.  Il
 prototipo della funzione è:
 attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale
 tutte le volte che si devono scrivere programmi che usano il multitasking.  Il
 prototipo della funzione è:

-

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


@@ -377,6 +379,8 @@ periodo di attesa.
 Se eseguiamo il comando senza specificare attese (come si può notare in
 \texttt{\small 17--19} i valori di default specificano di non attendere),
 otterremo come output sul terminale:
 Se eseguiamo il comando senza specificare attese (come si può notare in
 \texttt{\small 17--19} i valori di default specificano di non attendere),
 otterremo come output sul terminale:

+
+\footnotesize

 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 3
 Process 1963: forking 3 child
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 3
 Process 1963: forking 3 child


@@ -393,6 +397,7 @@ Child 3, parent 1963, exiting
 Spawned 3 child, pid 1966 
 Go to next child 
 \end{verbatim} %$
 Spawned 3 child, pid 1966 
 Go to next child 
 \end{verbatim} %$

+\normalsize

 
 Esaminiamo questo risultato: una prima conclusione che si può trarre è non si
 può dire quale processo fra il padre ed il figlio venga eseguito per
 
 Esaminiamo questo risultato: una prima conclusione che si può trarre è non si
 può dire quale processo fra il padre ed il figlio venga eseguito per


@@ -431,6 +436,8 @@ 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 è:
 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 è:

+
+\footnotesize

 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 3 > output
 [piccardi@selidor sources]$ cat output
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 3 > output
 [piccardi@selidor sources]$ cat output


@@ -457,6 +464,7 @@ Go to next child
 Spawned 3 child, pid 1970 
 Go to next child 
 \end{verbatim}
 Spawned 3 child, pid 1970 
 Go to next child 
 \end{verbatim}

+\normalsize

 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
 
 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
 
 Il comportamento delle varie funzioni di interfaccia con i file è analizzato


@@ -490,10 +498,9 @@ Quello che succede 
 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
 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 stesse voci della file table (per la spiegazione di questi termini si veda
-\secref{sec:file_sharing} e referenza a figura da fare) e quindi anche
-l'offset corrente nel 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
 
 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


@@ -527,11 +534,10 @@ sequenza impredicibile. Le modalit
 \end{enumerate}
 
 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre
 \end{enumerate}
 
 Oltre ai file aperti i processi figli ereditano dal padre una serie di altre

-proprietà comuni; in dettaglio avremo che dopo l'esecuzione di una \func{fork}
-padre e figlio avranno in comune:
+proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
+comune dopo l'esecuzione di una \func{fork} è la seguente:

 \begin{itemize*}
 \begin{itemize*}

-\item i file aperti (e gli eventuali flag di \textit{close-on-exec} se
-  settati).
+\item i file aperti e gli eventuali flag di \textit{close-on-exec} se settati.

 \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
 \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


@@ -543,12 +549,12 @@ padre e figlio avranno in comune:
 \item la directory di lavoro e la directory radice (vedi
   \secref{sec:file_work_dir}).
 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).
 \item la directory di lavoro e la directory radice (vedi
   \secref{sec:file_work_dir}).
 \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}).

-\item la maschera dei segnali.
+\item la maschera dei segnali bloccati e le azioni installate.

 \item i segmenti di memoria condivisa agganciati al processo. 
 \item i segmenti di memoria condivisa agganciati al processo. 

-\item i limiti sulle risorse
+\item i limiti sulle risorse.

 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
 \end{itemize*}
 \item le variabili di ambiente (vedi \secref{sec:proc_environ}).
 \end{itemize*}

-le differenze invece sono:
+le differenze fra padre e figlio dopo la \func{fork} invece sono:

 \begin{itemize*}
 \item il valore di ritorno di \func{fork}.
 \item il \textit{process id}. 
 \begin{itemize*}
 \item il valore di ritorno di \func{fork}.
 \item il \textit{process id}. 


@@ -557,7 +563,7 @@ le differenze invece sono:
 \item i valori dei tempi di esecuzione (\var{tms\_utime}, \var{tms\_stime},
   \var{tms\_cutime}, \var{tms\_uetime}) che nel figlio sono posti a zero.
 \item i \textit{file lock}, che non vengono ereditati dal figlio.
 \item i valori dei tempi di esecuzione (\var{tms\_utime}, \var{tms\_stime},
   \var{tms\_cutime}, \var{tms\_uetime}) che nel figlio sono posti a zero.
 \item i \textit{file lock}, che non vengono ereditati dal figlio.

-\item gli allarmi pendenti, che per il figlio vengono cancellati.
+\item gli allarmi ed i segnali pendenti, che per il figlio vengono cancellati.

 \end{itemize*}
 
 
 \end{itemize*}
 
 


@@ -660,6 +666,8 @@ avr
 di terminazione.  Come verifica di questo comportamento possiamo eseguire il
 comando \cmd{forktest} imponendo a ciascun processo figlio due
 secondi di attesa prima di uscire, il risultato è:
 di terminazione.  Come verifica di questo comportamento possiamo eseguire il
 comando \cmd{forktest} imponendo a ciascun processo figlio due
 secondi di attesa prima di uscire, il risultato è:

+
+\footnotesize

 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest -c2 3
 Process 1972: forking 3 child
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest -c2 3
 Process 1972: forking 3 child


@@ -676,6 +684,7 @@ Go to next child
 Child 2, parent 1, exiting
 Child 1, parent 1, exiting
 \end{verbatim}
 Child 2, parent 1, exiting
 Child 1, parent 1, exiting
 \end{verbatim}

+\normalsize

 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
 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


@@ -705,6 +714,8 @@ condizione: lanciamo il comando \cmd{forktest} in background, indicando al
 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
 otterremo:
 processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
 \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
 otterremo:

+
+\footnotesize

 \begin{verbatim}
 [piccardi@selidor sources]$ ps T
   PID TTY      STAT   TIME COMMAND
 \begin{verbatim}
 [piccardi@selidor sources]$ ps T
   PID TTY      STAT   TIME COMMAND


@@ -715,6 +726,7 @@ otterremo:
   571 pts/0    Z      0:00 [forktest <defunct>]
   572 pts/0    R      0:00 ps T
 \end{verbatim} %$
   571 pts/0    Z      0:00 [forktest <defunct>]
   572 pts/0    R      0:00 ps T
 \end{verbatim} %$

+\normalsize 

 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 zombie e l'indicazione che sono stati terminati.
 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 zombie e l'indicazione che sono stati terminati.


@@ -744,7 +756,7 @@ di terminare il processo che li ha generati, in modo che \cmd{init} possa
 adottarli e provvedere a concludere la terminazione.
 
 
 adottarli e provvedere a concludere la terminazione.
 
 

-\subsection{Le funzioni \texttt{wait} e  \texttt{waitpid}}
+\subsection{Le funzioni \func{wait} e  \func{waitpid}}

 \label{sec:proc_wait}
 
 Abbiamo già accennato come uno degli usi possibili delle capacità multitasking
 \label{sec:proc_wait}
 
 Abbiamo già accennato come uno degli usi possibili delle capacità multitasking


@@ -756,7 +768,6 @@ conclusione dei vari processi figli onde evitare di riempire di
 \textit{zombie} la tabella dei processi; le funzioni deputate a questo compito
 sono sostanzialmente due, \func{wait} e \func{waitpid}. La prima, il cui
 prototipo è:
 \textit{zombie} la tabella dei processi; le funzioni deputate a questo compito
 sono sostanzialmente due, \func{wait} e \func{waitpid}. La prima, il cui
 prototipo è:

-

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


@@ -775,6 +786,7 @@ caso di errore; \var{errno} pu
   \item \macro{EINTR} la funzione è stata interrotta da un segnale.
   \end{errlist}
 \end{functions}
   \item \macro{EINTR} la funzione è stata interrotta da un segnale.
   \end{errlist}
 \end{functions}

+

 è presente fin dalle prime versioni di unix; la funzione ritorna alla
 conclusione del primo figlio (o immediatamente se un figlio è già uscito). Nel
 caso un processo abbia più figli il valore di ritorno permette di identificare
 è presente fin dalle prime versioni di unix; la funzione ritorna alla
 conclusione del primo figlio (o immediatamente se un figlio è già uscito). Nel
 caso un processo abbia più figli il valore di ritorno permette di identificare


@@ -791,7 +803,6 @@ che effettua lo stesso servizio, ma dispone di una serie di funzionalit
 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 è:
 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 è:

-

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


@@ -816,6 +827,7 @@ base del valore specificato tramite la variabile \var{pid}, secondo lo
 specchietto riportato in \ntab:
 \begin{table}[!htb]
   \centering
 specchietto riportato in \ntab:
 \begin{table}[!htb]
   \centering

+  \footnotesize

   \begin{tabular}[c]{|c|p{10cm}|}
     \hline
     \textbf{Valore} & \textbf{Significato}\\
   \begin{tabular}[c]{|c|p{10cm}|}
     \hline
     \textbf{Valore} & \textbf{Significato}\\


@@ -900,7 +912,6 @@ 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
 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


@@ -931,7 +942,6 @@ lettura dello stato di terminazione di un processo, analoghe a \func{wait} e
 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 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:

-

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


@@ -946,6 +956,7 @@ accessibili definendo la costante \macro{\_USE\_BSD}, sono:
   Prima versione, equivalente a \func{wait4(-1, \&status, opt, rusage)} è
   ormai deprecata in favore di \func{wait4}.
 \end{functions}
   Prima versione, equivalente a \func{wait4(-1, \&status, opt, rusage)} è
   ormai deprecata in favore di \func{wait4}.
 \end{functions}

+\noindent 

 la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
 utilizzata anche dalla funzione \func{getrusage} per ottenere le risorse di
 sistema usate dal processo; in Linux è definita come:
 la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
 utilizzata anche dalla funzione \func{getrusage} per ottenere le risorse di
 sistema usate dal processo; in Linux è definita come:


@@ -975,7 +986,7 @@ struct rusage {
     \end{lstlisting}
   \end{minipage} 
   \normalsize 
     \end{lstlisting}
   \end{minipage} 
   \normalsize 

-  \caption{La struttura \texttt{rusage} per la lettura delle informazioni dei 
+  \caption{La struttura \var{rusage} per la lettura delle informazioni dei 

     delle risorse usate da un processo.}
   \label{fig:proc_rusage_struct}
 \end{figure}
     delle risorse usate da un processo.}
   \label{fig:proc_rusage_struct}
 \end{figure}


@@ -987,7 +998,7 @@ sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime}, \var{ru\_minflt},
 \var{ru\_majflt}, e \var{ru\_nswap}.
 
 
 \var{ru\_majflt}, e \var{ru\_nswap}.
 
 

-\subsection{Le funzioni \texttt{exec}}
+\subsection{Le funzioni \func{exec}}

 \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


@@ -1003,7 +1014,6 @@ Ci sono sei diverse versioni di \func{exec} (per questo la si 
 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, che in
 realtà (come mostrato in \figref{fig:proc_exec_relat}), costituiscono 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[])}
   
 \begin{prototype}{unistd.h}
 {int execve(const char * filename, char * const argv [], char * const envp[])}
   


@@ -1040,7 +1050,6 @@ front-end a \func{execve}. Il prototipo  di quest'ultima 
 Le altre funzioni della famiglia servono per fornire all'utente una serie
 possibile di diverse interfacce per la creazione di un nuovo processo. I loro
 prototipi sono:
 Le altre funzioni della famiglia servono per fornire all'utente una serie
 possibile di diverse interfacce per la creazione di un nuovo processo. I loro
 prototipi sono:

-

 \begin{functions}
 \headdecl{unistd.h}
 \funcdecl{int execl(const char *path, const char *arg, ...)} 
 \begin{functions}
 \headdecl{unistd.h}
 \funcdecl{int execl(const char *path, const char *arg, ...)} 


@@ -1126,7 +1135,7 @@ indicato dal parametro \var{path}, che viene interpretato come il
 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering

-  \includegraphics[width=13cm]{img/exec_rel.eps}
+  \includegraphics[width=13cm]{img/exec_rel}

   \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}}
   \label{fig:proc_exec_relat}
 \end{figure}
   \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}}
   \label{fig:proc_exec_relat}
 \end{figure}


@@ -1155,24 +1164,24 @@ la lista completa 
   \secref{sec:file_work_dir}).
 \item la maschera di creazione dei file (\var{umask}, vedi
   \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
   \secref{sec:file_work_dir}).
 \item la maschera di creazione dei file (\var{umask}, vedi
   \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi

-  \secref{sec:file_xxx}).
+  \secref{sec:file_locking}).

 \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
   \secref{sec:sig_xxx}).
 \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:limits_xxx})..
+\item i limiti sulle risorse (vedi \secref{sec:sys_limits})..

 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
 \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},

-  \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx})..
+  \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).

 \end{itemize*}
 
 Oltre a questo i segnali che sono stati settati per essere ignorati nel
 \end{itemize*}
 
 Oltre a questo i segnali che sono stati settati per essere ignorati nel

-processo chiamante mantengono lo stesso settaggio pure nuovo programma, tutti
-gli altri segnali vengono settati alla loro azione di default. Un caso
-speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN}
+processo chiamante mantengono lo stesso settaggio pure nel nuovo programma,
+tutti gli altri segnali vengono settati alla loro azione di default. Un caso
+speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN},

 può anche non essere resettato a \macro{SIG\_DFL} (si veda
 \secref{sec:sig_xxx}).
 
 La gestione dei file aperti dipende dal valore del flag di
 \textit{close-on-exec} per ciascun file descriptor (si veda
 può anche non essere resettato a \macro{SIG\_DFL} (si veda
 \secref{sec:sig_xxx}).
 
 La gestione dei file aperti dipende dal valore del flag di
 \textit{close-on-exec} per ciascun file descriptor (si veda

-\secref{sec:file_xxx}); i file per cui è settato vengono chiusi, tutti gli
+\secref{sec:file_fcntl}); i file per cui è settato vengono chiusi, tutti gli

 altri file restano aperti. Questo significa che il comportamento di default è
 che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
 esplicita a \func{fcntl} che setti il suddetto flag.
 altri file restano aperti. Questo significa che il comportamento di default è
 che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
 esplicita a \func{fcntl} che setti il suddetto flag.


@@ -1260,7 +1269,6 @@ utente per un limitato insieme di operazioni. Per questo motivo in generale
 tutti gli unix prevedono che i processi abbiano almeno due gruppi di
 identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}.
 
 tutti gli unix prevedono che i processi abbiano almeno due gruppi di
 identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}.
 

-

 \begin{table}[htb]
   \footnotesize
   \centering
 \begin{table}[htb]
   \footnotesize
   \centering


@@ -1315,26 +1323,29 @@ il programma che si 
 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
 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 qualunquee utente normale privilegi o permessi di
+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
 prototipi sono i seguenti:
 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
 prototipi sono i seguenti:

-

 \begin{functions}
 \begin{functions}

-\headdecl{unistd.h}
-\headdecl{sys/types.h}
-\funcdecl{uid\_t getuid(void)} restituisce il \textit{real user ID} del
-processo corrente.
-\funcdecl{uid\_t geteuid(void)} restituisce l'\textit{effective user ID} del
-processo corrente.
-\funcdecl{gid\_t getgid(void)} restituisce il \textit{real group ID} del
-processo corrente.
-\funcdecl{gid\_t getegid(void)} restituisce l'\textit{effective group ID} del
-processo corrente.
-
-Queste funzioni non riportano condizioni di errore. 
+  \headdecl{unistd.h}
+  \headdecl{sys/types.h}
+  
+  \funcdecl{uid\_t getuid(void)} restituisce il \textit{real user ID} del
+  processo corrente.
+
+  \funcdecl{uid\_t geteuid(void)} restituisce l'\textit{effective user ID} del
+  processo corrente.
+
+  \funcdecl{gid\_t getgid(void)} restituisce il \textit{real group ID} del
+  processo corrente.
+
+  \funcdecl{gid\_t getegid(void)} restituisce l'\textit{effective group ID} del
+  processo corrente.
+  
+  Queste funzioni non riportano condizioni di errore. 

 \end{functions}
 
 In generale l'uso di privilegi superiori deve essere limitato il più
 \end{functions}
 
 In generale l'uso di privilegi superiori deve essere limitato il più


@@ -1347,8 +1358,11 @@ servano di nuovo.
 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 è
 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}, il secondo gruppo è
-specifico di Linux e viene usato per migliorare la sicurezza con NFS. 
+definita la costante \macro{\_POSIX\_SAVED\_IDS}\footnote{in caso si abbia a
+  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.

 
 Il \textit{saved user id} e il \textit{saved group id} sono copie
 dell'\textit{effective user id} e dell'\textit{effective group id} del
 
 Il \textit{saved user id} e il \textit{saved group id} sono copie
 dell'\textit{effective user id} e dell'\textit{effective group id} del


@@ -1377,18 +1391,17 @@ di utente e gruppo associati dal kernel ad ogni processo, 
 \subsection{Le funzioni \func{setuid} e \func{setgid}}
 \label{sec:proc_setuid}
 
 \subsection{Le funzioni \func{setuid} e \func{setgid}}
 \label{sec:proc_setuid}
 

-Le due funzioni che venfono usate per cambiare identità (cioè utente e gruppo
+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
 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 sematica POSIX che prevede l'esistenza di \textit{saved user id} e
+seguono la semantica POSIX che prevede l'esistenza di \textit{saved user id} e

 \textit{saved group id}; i loro prototipi sono:
 \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
-corrente.  
+\funcdecl{int setuid(uid\_t uid)} setta l'\textit{user ID} del processo
+corrente.

 
 \funcdecl{int setgid(gid\_t gid)} setta il \textit{group ID} del processo
 corrente.
 
 \funcdecl{int setgid(gid\_t gid)} setta il \textit{group ID} del processo
 corrente.


@@ -1399,36 +1412,29 @@ l'unico errore possibile 
 
 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
 la prima; la seconda si comporta esattamente allo stesso modo facendo
 
 Il funzionamento di queste due funzioni è analogo, per cui considereremo solo
 la prima; la seconda si comporta esattamente allo stesso modo facendo

-riferimento al \textit{group id} invece che all'\textit{user id}.  
+riferimento al \textit{group id} invece che all'\textit{user id}.  Gli
+eventuali \textit{supplementary group id} non vengono modificati da nessuna
+delle funzioni che tratteremo in questa sezione.

 
 
 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
 l'\textit{effective user id} è zero (cioè è quello dell'amministratore di
 
 
 L'effetto della chiamata è diverso a seconda dei privilegi del processo; se
 l'\textit{effective user id} è zero (cioè è quello dell'amministratore di

-sistema) allora tutti gli identificatatori (\textit{real}, \textit{effective}
+sistema) allora tutti gli identificatori (\textit{real}, \textit{effective}

 e \textit{saved}) vengono settati al valore specificato da \var{uid},
 altrimenti viene settato solo l'\textit{effective user id}, e soltanto se il
 valore specificato corrisponde o al \textit{real user id} o al \textit{saved
 e \textit{saved}) vengono settati al valore specificato da \var{uid},
 altrimenti viene settato solo l'\textit{effective user id}, e soltanto se il
 valore specificato corrisponde o al \textit{real user id} o al \textit{saved

-  user id}. Negli altri casi segnalato un errore (con \macro{EPERM}).
+  user id}. Negli altri casi viene segnalato un errore (con \macro{EPERM}).

 
 Come accennato l'uso principale di queste funzioni è quello di poter
 
 Come accennato l'uso principale di queste funzioni è quello di poter

-consentire ad un programma con i bit \acr{suid} o \acr{sgid} settati, di
+consentire ad un programma con i bit \acr{suid} o \acr{sgid} settati di

 riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il
 riportare l'\textit{effective user id} a quello dell'utente che ha lanciato il

-programma, per effettuare il lavoro che non necessita di privilegi aggiuntivi,
-ed eventualmente tornare indietro. 
-
-Occorre però tenere conto che tutto questo non è possibile nel caso di root,
-in tal caso infatti l'esecuzione una \func{setuid} con un \textit{effective
-  user id} uguale a zero comporta il cambiamento di tutti gli identificatori
-associati al processo rendendo impossibile riguadagnare i privilegi di
-amministratore. Questo è l'uso che ne fa \cmd{login} una volta che crea una
-nuova shell per l'utente, ma se si vuole cambiare soltanto l'\textit{effective
-  user id} occorre ricorrere ad altre funzioni (si veda ad esempio
-\secref{sec:proc_seteuid}).
+programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed
+eventualmente tornare indietro.

 
 Come esempio per chiarire dell'uso di queste funzioni prediamo quello con cui
 viene gestito l'accesso al file \file{/var/log/utmp}.  In questo file viene
 registrato chi sta usando il sistema al momento corrente; chiaramente non può
 
 Come esempio per chiarire dell'uso di queste funzioni prediamo quello con cui
 viene gestito l'accesso al file \file{/var/log/utmp}.  In questo file viene
 registrato chi sta usando il sistema al momento corrente; chiaramente non può

-essere lasciato aperto in scrittura a qualunque utente, che protrebbe
+essere lasciato aperto in scrittura a qualunque utente, che potrebbe

 falsificare la registrazione. Per questo motivo questo file (e l'analogo
 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad
 falsificare la registrazione. Per questo motivo questo file (e l'analogo
 \file{/var/log/wtmp} su cui vengono registrati login e logout) appartengono ad
 un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad


@@ -1447,10 +1453,10 @@ situazione degli identificatori 
 in questo modo, dato che l'\textit{effective group id} è quello giusto, il
 programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo, a
 questo punto il programma può eseguire una \func{setgid(getgid())} per settare
 in questo modo, dato che l'\textit{effective group id} è quello giusto, il
 programma può accedere a \file{/var/log/utmp} in scrittura ed aggiornarlo, a
 questo punto il programma può eseguire una \func{setgid(getgid())} per settare

-l'\textit{effective group id} a quello dell'utente (ed usando il \textit{real
-  group id} la funzione avrà successo), in questo modo non sarà possibile
-lanciare dal terminale programmi che modificano detto file, in tal caso
-infatti la situazione degli identificatori sarebbe:
+l'\textit{effective group id} a quello dell'utente (e dato che il \textit{real
+  group id} corrisponde la funzione avrà successo), in questo modo non sarà
+possibile lanciare dal terminale programmi che modificano detto file, in tal
+caso infatti la situazione degli identificatori sarebbe:

 \begin{eqnarray*}
   \label{eq:2}
   \textit{real group id}      &=& \textrm{\acr{gid} (invariato)}  \\
 \begin{eqnarray*}
   \label{eq:2}
   \textit{real group id}      &=& \textrm{\acr{gid} (invariato)}  \\


@@ -1472,27 +1478,279 @@ avr
 \end{eqnarray*}
 consentendo l'accesso a \file{/var/log/utmp}.
 
 \end{eqnarray*}
 consentendo l'accesso a \file{/var/log/utmp}.
 

+Occorre però tenere conto che tutto questo non è possibile con un processo con
+i privilegi di root, in tal caso infatti l'esecuzione una \func{setuid}
+comporta il cambiamento di tutti gli identificatori associati al processo,
+rendendo impossibile riguadagnare i privilegi di amministratore.  Questo
+comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea
+una nuova shell per l'utente; ma quando si vuole cambiare soltanto
+l'\textit{effective user id} del processo per cedere i privilegi occorre
+ricorrere ad altre funzioni (si veda ad esempio \secref{sec:proc_seteuid}).
+
+
+\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:
+\begin{functions}
+\headdecl{unistd.h}
+\headdecl{sys/types.h}
+
+\funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} setta il \textit{real user
+  ID} e l'\textit{effective user ID} del processo corrente ai valori
+specificati da \var{ruid} e \var{euid}.
+  
+\funcdecl{int setregid(gid\_t rgid, gid\_t egid)} setta il \textit{real group
+  ID} e l'\textit{effective group ID} del processo corrente ai valori
+specificati da \var{rgid} e \var{egid}.
+
+Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento:
+l'unico errore possibile è \macro{EPERM}. 
+\end{functions}
+
+I processi non privilegiati possono settare i \textit{real id} soltanto ai
+valori dei loro \textit{effective id} o \textit{real id} e gli
+\textit{effective id} ai valori dei loro \textit{real id}, \textit{effective
+  id} o \textit{saved id}; valori diversi comportano il fallimento della
+chiamata; l'amministratore invece può specificare un valore qualunque.
+Specificando un valore di -1 l'identificatore corrispondente viene lasciato
+inalterato.
+
+Con queste funzione si possono scambiare fra loro \textit{real id} e
+\textit{effective id}, e pertanto è possibile implementare un comportamento
+simile a quello visto in precedenza per \func{setgid}, cedendo i privilegi con
+un primo scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un
+secondo scambio.
+
+In questo caso però occorre porre molta attenzione quando si creano nuovi
+processi nella fase intermedia in cui si sono scambiati gli identificatori, in
+questo caso infatti essi avranno un \textit{real id} privilegiato, che dovrà
+essere esplicitamente eliminato prima di porre in esecuzione un nuovo
+programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork}, e
+prima della \func{exec} per uniformare i \textit{real id} agli
+\textit{effective id}) in caso contrario quest'ultimo potrebbe a sua volta
+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
+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}.
+
+
+\subsection{Le funzioni \func{setresuid} e \func{setresgid}}
+\label{sec:proc_setresuid}
+
+Queste due funzioni sono una estensione introdotta in Linux dal kernel 2.1.44,
+e permettono un completo controllo su tutti gli identificatori (\textit{real},
+\textit{effective} e \textit{saved}), i prototipi sono:
+\begin{functions}
+\headdecl{unistd.h}
+\headdecl{sys/types.h}
+
+\funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} setta il
+\textit{real user ID}, l'\textit{effective user ID} e il \textit{saved user
+  ID} del processo corrente ai valori specificati rispettivamente da
+\var{ruid}, \var{euid} e \var{suid}.
+  
+\funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} setta il
+\textit{real group ID}, l'\textit{effective group ID} e il \textit{saved group
+  ID} del processo corrente ai valori specificati rispettivamente da
+\var{rgid}, \var{egid} e \var{sgid}.
+
+Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento:
+l'unico errore possibile è \macro{EPERM}. 
+\end{functions}
+
+I processi non privilegiati possono cambiare uno qualunque degli
+identificatori usando uno qualunque dei valori correnti di \textit{real id},
+\textit{effective id} o \textit{saved id}, l'amministratore può specificare i
+valori che vuole; un valore di -1 per un qualunque parametro lascia inalterato
+l'identificatore corrispondente.
+
+

 
 \subsection{Le funzioni \func{seteuid} e \func{setegid}}
 \label{sec:proc_seteuid}
 
 
 \subsection{Le funzioni \func{seteuid} e \func{setegid}}
 \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
+\textit{effective id}; i loro prototipi sono:
+\begin{functions}
+\headdecl{unistd.h}
+\headdecl{sys/types.h}

 
 

-\subsection{Le funzioni \func{setreuid} e \func{setresuid}}
-\label{sec:proc_setreuid}
+\funcdecl{int seteuid(uid\_t uid)} setta l'\textit{effective user ID} del
+processo corrente a \var{uid}.
+
+\funcdecl{int setegid(gid\_t gid)} setta l'\textit{effective group ID} del
+processo corrente a \var{gid}.
+
+Le funzioni restituiscono 0 in caso di successo e -1 in caso di fallimento:
+l'unico errore possibile è \macro{EPERM}. 
+\end{functions}

 
 

+Gli utenti normali possono settare l'\textit{effective id} solo al valore del
+\textit{real id} o del \textit{saved id}, l'amministratore può specificare
+qualunque valore. Queste funzioni sono usate per permettere a root di settare
+solo l'\textit{effective id}, dato che l'uso normale di \func{setuid} comporta
+il settaggio di tutti gli identificatori.
+ 

 
 \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
 \label{sec:proc_setfsuid}
 
 
 \subsection{Le funzioni \func{setfsuid} e \func{setfsgid}}
 \label{sec:proc_setfsuid}
 

+Queste funzioni sono usate per settare gli identificatori usati da Linux per
+il controllo dell'accesso ai file. Come già accennato in
+\secref{sec:proc_user_group} in Linux è definito questo ulteriore gruppo di
+identificatori, che di norma sono assolutamente equivalenti agli
+\textit{effective id}, dato che ogni cambiamento di questi ultimi viene
+immediatamente riportato sui \textit{filesystem id}.
+
+C'è un solo caso in cui si ha necessità di introdurre una differenza fra
+\textit{effective id} e \textit{filesystem id}, ed è per ovviare ad un
+problema di sicurezza che si presenta quando si deve implementare un server
+NFS. Il server NFS infatti deve poter cambiare l'identificatore con cui accede
+ai file per assumere l'identità del singolo utente remoto, ma se questo viene
+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
+quelli originari per quanto riguarda tutti gli altri controlli di accesso.
+
+Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid}
+e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
+usate se si intendono scrivere programmi portabili; i loro prototipi sono:
+\begin{functions}
+\headdecl{sys/fsuid.h}
+
+\funcdecl{int setfsuid(uid\_t fsuid)} setta il \textit{filesystem user ID} del
+processo corrente a \var{fsuid}.

 
 

+\funcdecl{int setfsgid(gid\_t fsgid)} setta l'\textit{filesystem group ID} del
+processo corrente a \var{fsgid}.

 
 

-\subsection{Le \textit{race condition}}
+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}.
+
+
+\section{Problematiche di programmazione multitasking}
+\label{sec:proc_multi_prog}
+
+Benché i processi siano strutturati in modo da apparire il più possibile come
+indipendenti l'uno dall'altro, nella programmazione in un sistema multiutente
+occorre tenere conto di tutta una serie di problematiche che normalmente non
+esistono quando si ha a che fare con un sistema in cui viene eseguito un solo
+programma alla volta. 
+
+Pur non essendo tutto questo direttamente legato alla modalità specifica in
+cui il multitasking è implementato in un sistema unix-like, né al solo
+concetto di multitasking (le stesse problematiche si presentano ad esempio
+nella gestione degli interrupt hardware), in questa sezione conclusiva del
+capitolo in cui abbiamo affrontato la gestione dei processi, introdurremo
+sinteticamente queste problematiche, che ritroveremo a più riprese in capitoli
+successivi, con una breve definizione della terminologia e delle loro
+caratteristiche di fondo.
+
+
+\subsection{Le operazioni atomiche}
+\label{sec:proc_atom_oper}
+
+La nozione di \textsl{operazione atomica} deriva dal significato greco della
+parola atomo, cioè indivisibile; si dice infatti che una operazione è atomica
+quando si ha la certezza che, qualora essa venga effettuata, tutti i passaggi
+che devono essere compiuti per realizzarla verranno eseguiti senza possibilità
+di interruzione in una fase intermedia.
+
+In un ambiente multitasking il concetto è essenziale, dato che un processo può
+essere interrotto in qualunque momento dal kernel che mette in esecuzione un
+altro processo o dalla ricezione di un segnale; occorre pertanto essere
+accorti nei confronti delle possibili \textit{race condition} (vedi
+\secref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase in
+cui non erano ancora state completate.
+
+Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
+occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
+fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
+\capref{cha:IPC}) o nella operazioni con i file (vedremo alcuni esempi in
+\secref{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.
+
+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}
+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ù
+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},
+il cui accesso è assicurato essere atomico.  In pratica comunque si può
+assumere che in ogni piattaforma su cui è implementato Linux il tipo
+\type{int} (e gli altri interi di dimensione inferiore) ed i puntatori sono
+atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
+maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
+le strutture. In questi casi è anche opportuno marcare come \type{volatile} le
+variabili che possono essere interessate ad accesso condiviso, onde evitare
+problemi con le ottimizzazioni del codice.
+
+
+\subsection{Le \textit{race condition} e i \textit{deadlock}}

 \label{sec:proc_race_cond}
 
 Si definisce una \textit{race condition} il caso in cui diversi processi
 stanno cercando di fare qualcosa con una risorsa comune ed il risultato finale
 viene a dipendere dall'ordine di esecuzione dei medesimi. Ovviamente dato che
 \label{sec:proc_race_cond}
 
 Si definisce una \textit{race condition} il caso in cui diversi processi
 stanno cercando di fare qualcosa con una risorsa comune ed il risultato finale
 viene a dipendere dall'ordine di esecuzione dei medesimi. Ovviamente dato che

-l'ordine di esecuzione di un processo, senza appositi meccanismi di
-sincronizzazione, non è assolutamente prevedibile, queste situazioni sono
-fonti di errori molto subdoli, che possono verificarsi solo in condizioni
-particolari e quindi difficilmente riproducibili.
+l'ordine di esecuzione di un processo rispetto agli altri, senza appositi
+meccanismi di sincronizzazione, non è assolutamente prevedibile, queste
+situazioni sono fonti di errori molto subdoli, che possono verificarsi solo in
+condizioni particolari e quindi difficilmente riproducibili.
+
+Casi tipici di \textit{race condition} si hanno quando diversi processi
+accedono allo stesso file, o nell'accesso a meccanismi di intercomunicazione
+come la memoria condivisa. In questi casi, se non si dispone della possibilità
+di eseguire atomicamente le operazioni necessarie, occorre che le risorse
+condivise siano opportunamente protette da meccanismi di sincronizzazione
+(torneremo su queste problematiche di questo tipo in \secref{sec:ipc_semaph}).
+
+Un caso particolare di \textit{race condition} sono poi i cosiddetti
+\textit{deadlock}; l'esempio tipico è quello di un flag di ``occupazione'' che
+viene rilasciato da un evento asincrono fra il controllo (in cui viene trovato
+occupato) e la successiva messa in attesa, che a questo punto diventerà
+perpetua (da cui il nome di \textit{deadlock}) in quanto l'evento di sblocco
+del flag è stato perso fra il controllo e la messa in attesa.
+
+
+\subsection{Le funzioni rientranti}
+\label{sec:proc_reentrant}
+
+Si dice rientrante una funzione che può essere interrotta in qualunque momento
+ed essere chiamata da capo (da questo il nome) da un altro filone di
+esecuzione (thread e manipolatori di segnali sono i casi in cui occorre
+prestare attenzione a questa problematica) senza che questo comporti nessun
+problema.
+
+In genere una funzione non è rientrante se opera direttamente su memoria che
+non è nello stack. Ad esempio una funzione non è rientrante se usa una
+variabile globale o statica od un oggetto allocato dinamicamente che trova da
+sola: due chiamate alla stessa funzione interferiranno.  Una funzione può non
+essere rientrante se usa e modifica un oggetto che le viene fornito dal
+chiamante: due chiamate possono interferire se viene passato lo stesso
+oggetto. 
+
+Le glibc mettono a disposizione due macro di compilatore \macro{\_REENTRANT} e
+\macro{\_THREAD\_SAFE} per assicurare che siano usate delle versioni rientranti
+delle funzioni di libreria.
+