X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=d3bc3e6307a554f91e88e80c2ba6cce73223eb78;hp=04fe2cdf5625d4deb87393086d0f47089f3b1297;hb=71bd769469078fc921d9646d62b0f9293b6ae47c;hpb=caa33ab45032ea8c9917a9d2914ff59266b30ad2

diff --git a/ipc.tex b/ipc.tex
index 04fe2cd..d3bc3e6 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -1,9 +1,9 @@
 %% ipc.tex
 %%
-%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2006 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
-%% Free Software Foundation; with the Invariant Sections being "Prefazione",
+%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
 %% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
@@ -41,7 +41,7 @@ ne gestiscono l'uso e le varie forme in cui si 
 
 Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, e tuttora
 uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
-sostanza di una una coppia di file descriptor\footnote{si tenga presente che
+sostanza di una coppia di file descriptor\footnote{si tenga presente che
   le pipe sono oggetti creati dal kernel e non risiedono su disco.} connessi
 fra di loro in modo che se quanto scrive su di uno si può rileggere
 dall'altro. Si viene così a costituire un canale di comunicazione tramite i
@@ -67,8 +67,8 @@ scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
 nel file descriptor aperto in lettura. I file descriptor infatti non sono
 connessi a nessun file reale, ma ad un buffer nel kernel, la cui dimensione è
 specificata dal parametro di sistema \const{PIPE\_BUF}, (vedi
-\secref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
-illustrato in \figref{fig:ipc_pipe_singular}, in cui sono illustrati i due
+sez.~\ref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
+illustrato in fig.~\ref{fig:ipc_pipe_singular}, in cui sono illustrati i due
 capi della pipe, associati a ciascun file descriptor, con le frecce che
 indicano la direzione del flusso dei dati.
 
@@ -80,12 +80,12 @@ indicano la direzione del flusso dei dati.
 \end{figure}
 
 Chiaramente creare una pipe all'interno di un singolo processo non serve a
-niente; se però ricordiamo quanto esposto in \secref{sec:file_sharing}
+niente; se però ricordiamo quanto esposto in sez.~\ref{sec:file_sharing}
 riguardo al comportamento dei file descriptor nei processi figli, è immediato
 capire come una pipe possa diventare un meccanismo di intercomunicazione. Un
 processo figlio infatti condivide gli stessi file descriptor del padre,
 compresi quelli associati ad una pipe (secondo la situazione illustrata in
-\figref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
+fig.~\ref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
 capo della pipe, l'altro può leggere.
 
 \begin{figure}[htb]
@@ -98,7 +98,7 @@ capo della pipe, l'altro pu
 
 Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
 comunicazione fra processi attraverso una pipe, utilizzando le proprietà
-ordinarie dei file, ma ci mostra anche qual'è il principale\footnote{Stevens
+ordinarie dei file, ma ci mostra anche qual è il principale\footnote{Stevens
   in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
   unidirezionale, ma in realtà questo è un limite facilmente superabile usando
   una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
@@ -131,18 +131,18 @@ da altri processi.
 Per capire meglio il funzionamento delle pipe faremo un esempio di quello che
 è il loro uso più comune, analogo a quello effettuato della shell, e che
 consiste nell'inviare l'output di un processo (lo standard output) sull'input
-di un'altro. Realizzeremo il programma di esempio nella forma di un
+di un altro. Realizzeremo il programma di esempio nella forma di un
 \textit{CGI}\footnote{Un CGI (\textit{Common Gateway Interface}) è un
   programma che permette la creazione dinamica di un oggetto da inserire
   all'interno di una pagina HTML.}  per Apache, che genera una immagine JPEG
-di un codice a barre, specificato come parametro di input.
+di un codice a barre, specificato come argomento in ingresso.
 
 Un programma che deve essere eseguito come \textit{CGI} deve rispondere a
 delle caratteristiche specifiche, esso infatti non viene lanciato da una
 shell, ma dallo stesso web server, alla richiesta di una specifica URL, che di
 solito ha la forma:
 \begin{verbatim}
-    http://www.sito.it/cgi-bin/programma?parametro
+    http://www.sito.it/cgi-bin/programma?argomento
 \end{verbatim}
 ed il risultato dell'elaborazione deve essere presentato (con una intestazione
 che ne descrive il mime-type) sullo standard output, in modo che il web-server
@@ -154,37 +154,39 @@ Per realizzare quanto voluto useremo in sequenza i programmi \cmd{barcode} e
 codici a barre corrispondenti ad una qualunque stringa, mentre il secondo
 serve per poter effettuare la conversione della stessa immagine in formato
 JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
-secondo, secondo lo schema mostrato in \figref{fig:ipc_pipe_use}, in cui la
+secondo, secondo lo schema mostrato in fig.~\ref{fig:ipc_pipe_use}, in cui la
 direzione del flusso dei dati è data dalle frecce continue.
 
 \begin{figure}[htb]
   \centering
   \includegraphics[height=5cm]{img/pipeuse}
   \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
-    due processi attraverso attraverso l'esecuzione una \func{fork} e la
-    chiusura dei capi non utilizzati.}
+    due processi attraverso l'esecuzione una \func{fork} e la chiusura dei
+    capi non utilizzati.}
   \label{fig:ipc_pipe_use}
 \end{figure}
 
 Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
 intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
 \textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
-evidente race condition\index{race condition} in caso di accesso simultaneo a
-detto file.\footnote{il problema potrebbe essere superato determinando in
-  anticipo un nome appropriato per il file temporaneo, che verrebbe utilizzato
-  dai vari sotto-processi, e cancellato alla fine della loro esecuzione; ma a
-  questo le cose non sarebbero più tanto semplici.}  L'uso di una pipe invece
-permette di risolvere il problema in maniera semplice ed elegante, oltre ad
-essere molto più efficiente, dato che non si deve scrivere su disco.
+evidente \textit{race condition}\itindex{race~condition} in caso di accesso
+simultaneo a detto file.\footnote{il problema potrebbe essere superato
+  determinando in anticipo un nome appropriato per il file temporaneo, che
+  verrebbe utilizzato dai vari sotto-processi, e cancellato alla fine della
+  loro esecuzione; ma a questo le cose non sarebbero più tanto semplici.}
+L'uso di una pipe invece permette di risolvere il problema in maniera semplice
+ed elegante, oltre ad essere molto più efficiente, dato che non si deve
+scrivere su disco.
 
 Il programma ci servirà anche come esempio dell'uso delle funzioni di
 duplicazione dei file descriptor che abbiamo trattato in
-\secref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
+sez.~\ref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
 funzioni infatti che è possibile dirottare gli stream standard dei processi
-(che abbiamo visto in \secref{sec:file_std_descr} e
-\secref{sec:file_std_stream}) sulla pipe. In \figref{fig:ipc_barcodepage_code}
-abbiamo riportato il corpo del programma, il cui codice completo è disponibile
-nel file \file{BarCodePage.c} che si trova nella directory dei sorgenti.
+(che abbiamo visto in sez.~\ref{sec:file_std_descr} e
+sez.~\ref{sec:file_std_stream}) sulla pipe. In
+fig.~\ref{fig:ipc_barcodepage_code} abbiamo riportato il corpo del programma,
+il cui codice completo è disponibile nel file \file{BarCodePage.c} che si
+trova nella directory dei sorgenti.
 
 
 \begin{figure}[!htb]
@@ -203,7 +205,7 @@ le due pipe che serviranno per la comunicazione fra i due comandi utilizzati
 per produrre il codice a barre; si ha cura di controllare la riuscita della
 chiamata, inviando in caso di errore un messaggio invece dell'immagine
 richiesta.\footnote{la funzione \func{WriteMess} non è riportata in
-  \secref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
+  fig.~\ref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
   formattare l'uscita alla maniera dei CGI, aggiungendo l'opportuno
   \textit{mime type}, e formattando il messaggio in HTML, in modo che
   quest'ultimo possa essere visualizzato correttamente da un browser.}
@@ -300,11 +302,11 @@ programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
 quindi associato allo standard input) in caso di \code{"w"}.
 
 Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
-stream visti in \capref{cha:files_std_interface}, anche se è collegato ad una
-pipe e non ad un file, e viene sempre aperto in modalità
-\textit{fully-buffered} (vedi \secref{sec:file_buffering}); l'unica differenza
-con gli usuali stream è che dovrà essere chiuso dalla seconda delle due nuove
-funzioni, \funcd{pclose}, il cui prototipo è:
+stream visti in cap.~\ref{cha:files_std_interface}, anche se è collegato ad
+una pipe e non ad un file, e viene sempre aperto in modalità
+\textit{fully-buffered} (vedi sez.~\ref{sec:file_buffering}); l'unica
+differenza con gli usuali stream è che dovrà essere chiuso dalla seconda delle
+due nuove funzioni, \funcd{pclose}, il cui prototipo è:
 \begin{prototype}{stdio.h}
 {int pclose(FILE *stream)}
 
@@ -320,7 +322,7 @@ attendendo la terminazione del processo ad essa associato.
 \func{popen}.
 
 Per illustrare l'uso di queste due funzioni riprendiamo il problema
-precedente: il programma mostrato in \figref{fig:ipc_barcodepage_code} per
+precedente: il programma mostrato in fig.~\ref{fig:ipc_barcodepage_code} per
 quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
 inoltre nella pratica sconta un problema di \cmd{gs} che non è in
 grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
@@ -364,13 +366,13 @@ semplificare notevolmente la stesura del codice.
 Nel nostro caso, dato che ciascun processo deve scrivere il suo output sullo
 standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
 scrittura. Il codice del nuovo programma è riportato in
-\figref{fig:ipc_barcode_code}.  Come si può notare l'ordine di invocazione dei
-programmi è l'inverso di quello in cui ci si aspetta che vengano
+fig.~\ref{fig:ipc_barcode_code}.  Come si può notare l'ordine di invocazione
+dei programmi è l'inverso di quello in cui ci si aspetta che vengano
 effettivamente eseguiti. Questo non comporta nessun problema dato che la
 lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
 per primo, si bloccherà in attesa di ricevere sullo standard input il
-risultato dell'elaborazione del precedente, benchè quest'ultimo venga
-invocato dopo.
+risultato dell'elaborazione del precedente, benché quest'ultimo venga invocato
+dopo.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -409,10 +411,10 @@ create, tutte le pipe create con \func{pclose}.
 \subsection{Le \textit{pipe} con nome, o \textit{fifo}}
 \label{sec:ipc_named_pipe}
 
-Come accennato in \secref{sec:ipc_pipes} il problema delle \textit{pipe} è che
-esse possono essere utilizzate solo da processi con un progenitore comune o
-nella relazione padre/figlio; per superare questo problema lo standard POSIX.1
-ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
+Come accennato in sez.~\ref{sec:ipc_pipes} il problema delle \textit{pipe} è
+che esse possono essere utilizzate solo da processi con un progenitore comune
+o nella relazione padre/figlio; per superare questo problema lo standard
+POSIX.1 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
 caratteristiche delle pipe, ma che invece di essere strutture interne del
 kernel, visibili solo attraverso un file descriptor, sono accessibili
 attraverso un inode\index{inode} che risiede sul filesystem, così che i
@@ -424,9 +426,9 @@ attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
 l'inode\index{inode} allocato sul filesystem serve infatti solo a fornire un
 punto di riferimento per i processi, che permetta loro di accedere alla stessa
 fifo; il comportamento delle funzioni di lettura e scrittura è identico a
-quello illustrato per le pipe in \secref{sec:ipc_pipes}.
+quello illustrato per le pipe in sez.~\ref{sec:ipc_pipes}.
 
-Abbiamo già visto in \secref{sec:file_mknod} le funzioni \func{mknod} e
+Abbiamo già visto in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
 \func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
 processo non avrà che da aprire il relativo file speciale o in lettura o
 scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
@@ -451,8 +453,8 @@ comunque una fifo in scrittura anche se non ci sono ancora processi il
 lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
 qual caso però occorre stare molto attenti alla possibili situazioni di
 stallo.\footnote{se si cerca di leggere da una fifo che non contiene dati si
-  avrà un deadlock\index{deadlock} immediato, dato che il processo si blocca e
-  non potrà quindi mai eseguire le funzioni di scrittura.}
+  avrà un deadlock\itindex{deadlock} immediato, dato che il processo si blocca
+  e non potrà quindi mai eseguire le funzioni di scrittura.}
 
 Per la loro caratteristica di essere accessibili attraverso il filesystem, è
 piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
@@ -460,7 +462,7 @@ situazioni un processo deve ricevere informazioni da altri. In questo caso 
 fondamentale che le operazioni di scrittura siano atomiche; per questo si deve
 sempre tenere presente che questo è vero soltanto fintanto che non si supera
 il limite delle dimensioni di \const{PIPE\_BUF} (si ricordi quanto detto in
-\secref{sec:ipc_pipes}).
+sez.~\ref{sec:ipc_pipes}).
 
 A parte il caso precedente, che resta probabilmente il più comune, Stevens
 riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
@@ -470,7 +472,7 @@ riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
   sull'input di parecchi altri (attraverso l'uso del comando \cmd{tee}).
   
 \item Come canale di comunicazione fra client ed server (il modello
-  \textit{client-server} è illustrato in \secref{sec:net_cliserv}).
+  \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}).
 \end{itemize}
 
 Nel primo caso quello che si fa è creare tante fifo, da usare come standard
@@ -489,7 +491,7 @@ la struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
 leggerli, quando i dati inviati sono destinati a loro.
 
 Per risolvere questo problema, si può usare un'architettura come quella
-illustrata in \figref{fig:ipc_fifo_server_arch} in cui i client inviano le
+illustrata in fig.~\ref{fig:ipc_fifo_server_arch} in cui i client inviano le
 richieste al server su una fifo nota mentre le risposte vengono reinviate dal
 server a ciascuno di essi su una fifo temporanea creata per l'occasione.
 
@@ -506,7 +508,7 @@ un server di \textit{fortunes}, che restituisce, alle richieste di un client,
 un detto a caso estratto da un insieme di frasi; sia il numero delle frasi
 dell'insieme, che i file da cui esse vengono lette all'avvio, sono importabili
 da riga di comando. Il corpo principale del server è riportato in
-\figref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
+fig.~\ref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
 gestione delle opzioni a riga di comando, che effettua il settaggio delle
 variabili \var{fortunefilename}, che indica il file da cui leggere le frasi,
 ed \var{n}, che indica il numero di frasi tenute in memoria, ad un valore
@@ -528,10 +530,11 @@ Il server richiede (\texttt{\small 12}) che sia stata impostata una dimensione
 dell'insieme delle frasi non nulla, dato che l'inizializzazione del vettore
 \var{fortune} avviene solo quando questa dimensione viene specificata, la
 presenza di un valore nullo provoca l'uscita dal programma attraverso la
-routine (non riportata) che ne stampa le modalità d'uso.  Dopo di che installa
-(\texttt{\small 13--15}) la funzione che gestisce i segnali di interruzione
-(anche questa non è riportata in \figref{fig:ipc_fifo_server}) che si limita a
-rimuovere dal filesystem la fifo usata dal server per comunicare.
+funzione (non riportata) che ne stampa le modalità d'uso.  Dopo di che
+installa (\texttt{\small 13--15}) la funzione che gestisce i segnali di
+interruzione (anche questa non è riportata in fig.~\ref{fig:ipc_fifo_server})
+che si limita a rimuovere dal filesystem la fifo usata dal server per
+comunicare.
 
 Terminata l'inizializzazione (\texttt{\small 16}) si effettua la chiamata alla
 funzione \code{FortuneParse} che legge dal file specificato in
@@ -584,7 +587,7 @@ a \func{read} possono bloccarsi.
 A questo punto si può entrare nel ciclo principale del programma che fornisce
 le risposte ai client (\texttt{\small 34--50}); questo viene eseguito
 indefinitamente (l'uscita del server viene effettuata inviando un segnale, in
-modo da passare attraverso la routine di chiusura che cancella la fifo).
+modo da passare attraverso la funzione di chiusura che cancella la fifo).
 
 Il server è progettato per accettare come richieste dai client delle stringhe
 che contengono il nome della fifo sulla quale deve essere inviata la risposta.
@@ -597,9 +600,9 @@ all'apertura della fifo per la risposta, che poi \texttt{\small 47--48}) vi
 sarà scritta. Infine (\texttt{\small 49}) si chiude la fifo di risposta che
 non serve più.
 
-Il codice del client è invece riportato in \figref{fig:ipc_fifo_client}, anche
-in questo caso si è omessa la gestione delle opzioni e la funzione che stampa
-a video le informazioni di utilizzo ed esce, riportando solo la sezione
+Il codice del client è invece riportato in fig.~\ref{fig:ipc_fifo_client},
+anche in questo caso si è omessa la gestione delle opzioni e la funzione che
+stampa a video le informazioni di utilizzo ed esce, riportando solo la sezione
 principale del programma e le definizioni delle variabili. Il codice completo
 è nel file \file{FortuneClient.c} dei sorgenti allegati.
 
@@ -645,12 +648,12 @@ state raccolte nella libreria \file{libgapil.so}, per poter usare quest'ultima
 occorrerà definire la speciale variabile di ambiente \code{LD\_LIBRARY\_PATH}
 in modo che il linker dinamico possa accedervi.
 
-In generale questa variabile indica il pathname della directory contenente la
-libreria. Nell'ipotesi (che daremo sempre per verificata) che si facciano le
-prove direttamente nella directory dei sorgenti (dove di norma vengono creati
-sia i programmi che la libreria), il comando da dare sarà \code{export
-  LD\_LIBRARY\_PATH=./}; a questo punto potremo lanciare il server, facendogli
-leggere una decina di frasi, con:
+In generale questa variabile indica il \itindex{pathname}\textit{pathname}
+della directory contenente la libreria. Nell'ipotesi (che daremo sempre per
+verificata) che si facciano le prove direttamente nella directory dei sorgenti
+(dove di norma vengono creati sia i programmi che la libreria), il comando da
+dare sarà \code{export LD\_LIBRARY\_PATH=./}; a questo punto potremo lanciare
+il server, facendogli leggere una decina di frasi, con:
 \begin{verbatim}
 [piccardi@gont sources]$ ./fortuned -n10
 \end{verbatim}
@@ -658,7 +661,7 @@ leggere una decina di frasi, con:
 Avendo usato \func{daemon} per eseguire il server in background il comando
 ritornerà immediatamente, ma potremo verificare con \cmd{ps} che in effetti il
 programma resta un esecuzione in background, e senza avere associato un
-terminale di controllo (si ricordi quanto detto in \secref{sec:sess_daemon}):
+terminale di controllo (si ricordi quanto detto in sez.~\ref{sec:sess_daemon}):
 \begin{verbatim}
 [piccardi@gont sources]$ ps aux
 ...
@@ -706,8 +709,8 @@ complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
 fifo non è adatta a risolvere questo tipo di problemi, che possono essere
 affrontati in maniera più semplice ed efficace o usando i
 \textit{socket}\index{socket} (che tratteremo in dettaglio a partire da
-\capref{cha:socket_intro}) o ricorrendo a meccanismi di comunicazione diversi,
-come quelli che esamineremo in seguito.
+cap.~\ref{cha:socket_intro}) o ricorrendo a meccanismi di comunicazione
+diversi, come quelli che esamineremo in seguito.
 
 
 
@@ -717,12 +720,12 @@ come quelli che esamineremo in seguito.
 Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il
 problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
 \textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo l'argomento
-dei \textit{socket}\index{socket} in \capref{cha:socket_intro},\footnote{si
+dei \textit{socket}\index{socket} in cap.~\ref{cha:socket_intro},\footnote{si
   tratta comunque di oggetti di comunicazione che, come le pipe, sono
   utilizzati attraverso dei file descriptor.} nell'ambito dell'interfaccia
 generale che essi forniscono per la programmazione di rete; e vedremo anche
-(in~\secref{sec:sock_sa_local}) come si possono definire dei file speciali (di
-tipo \textit{socket}, analoghi a quello associati alle fifo) cui si accede
+(in~sez.~\ref{sec:sock_sa_local}) come si possono definire dei file speciali
+(di tipo \textit{socket}, analoghi a quello associati alle fifo) cui si accede
 però attraverso quella medesima interfaccia; vale però la pena esaminare qui
 una modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
   stata introdotta in BSD4.4, ma è supportata in genere da qualunque sistema
@@ -758,11 +761,12 @@ effettuato in entrambe le direzioni. Il prototipo della funzione 
 
 La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di
 loro: quello che si scrive su uno di essi sarà ripresentato in input
-sull'altro e viceversa. I parametri \param{domain}, \param{type} e
-\param{protocol} derivano dall'interfaccia dei socket\index{socket} (che è
-quella che fornisce il substrato per connettere i due descrittori), ma in
-questo caso i soli valori validi che possono essere specificati sono
-rispettivamente \const{AF\_UNIX}, \const{SOCK\_STREAM} e \val{0}.
+sull'altro e viceversa. Gli argomenti \param{domain}, \param{type} e
+\param{protocol} derivano dall'interfaccia dei socket\index{socket} (vedi
+sez.~\ref{sec:sock_creation}) che è quella che fornisce il substrato per
+connettere i due descrittori, ma in questo caso i soli valori validi che
+possono essere specificati sono rispettivamente \const{AF\_UNIX},
+\const{SOCK\_STREAM} e \val{0}.
 
 L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
 può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei
@@ -770,10 +774,10 @@ socket\index{socket} locali in generale) permette di trasmettere attraverso le
 linea non solo dei dati, ma anche dei file descriptor: si può cioè passare da
 un processo ad un altro un file descriptor, con una sorta di duplicazione
 dello stesso non all'interno di uno stesso processo, ma fra processi distinti
-(torneremo su questa funzionalità in \secref{sec:xxx_fd_passing}).
+(torneremo su questa funzionalità in sez.~\ref{sec:sock_fd_passing}).
 
 
-\section{La comunicazione fra processi di System V}
+\section{Il sistema di comunicazione fra processi di System V}
 \label{sec:ipc_sysv}
 
 Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
@@ -785,7 +789,7 @@ Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
 oggetti per la comunicazione fra processi ed una nuova interfaccia di
 programmazione, che fossero in grado di garantire una maggiore flessibilità.
 In questa sezione esamineremo come Linux supporta quello che viene chiamato il
-\textsl{Sistema di comunicazione inter-processo} di System V, cui da qui in
+\textsl{Sistema di comunicazione fra processi} di System V, cui da qui in
 avanti faremo riferimento come \textit{SysV IPC} (dove IPC è la sigla di
 \textit{Inter-Process Comunication}).
 
@@ -813,7 +817,7 @@ Un'ulteriore caratteristica negativa 
 specificando il relativo \textsl{identificatore}. Questo è un numero
 progressivo (un po' come il \acr{pid} dei processi) che il kernel assegna a
 ciascuno di essi quanto vengono creati (sul procedimento di assegnazione
-torneremo in \secref{sec:ipc_sysv_id_use}). L'identificatore viene restituito
+torneremo in sez.~\ref{sec:ipc_sysv_id_use}). L'identificatore viene restituito
 dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha
 eseguite. Dato che l'identificatore viene assegnato dinamicamente dal kernel
 non è possibile prevedere quale sarà, né utilizzare un qualche valore statico,
@@ -828,7 +832,7 @@ tramite la quale 
   si sposta il problema dell'accesso dalla classificazione in base
   all'identificatore alla classificazione in base alla chiave, una delle tante
   complicazioni inutili presenti nel \textit{SysV IPC}.} Oltre la chiave, la
-struttura, la cui definizione è riportata in \figref{fig:ipc_ipc_perm},
+struttura, la cui definizione è riportata in fig.~\ref{fig:ipc_ipc_perm},
 mantiene varie proprietà ed informazioni associate all'oggetto.
 
 \begin{figure}[!htb]
@@ -845,14 +849,14 @@ mantiene varie propriet
 Usando la stessa chiave due processi diversi possono ricavare l'identificatore
 associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
 come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
-sono \textsl{parenti} la soluzione è relativamente semplice, in tal caso
+sono \textsl{imparentati} la soluzione è relativamente semplice, in tal caso
 infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
 nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
-disponibile in tutti i figli, e potrà essere passato come parametro attraverso
+disponibile in tutti i figli, e potrà essere passato come argomento attraverso
 una \func{exec}.
 
-Però quando i processi non sono \textsl{parenti} (come capita tutte le volte
-che si ha a che fare con un sistema client-server) tutto questo non è
+Però quando i processi non sono \textsl{imparentati} (come capita tutte le
+volte che si ha a che fare con un sistema client-server) tutto questo non è
 possibile; si potrebbe comunque salvare l'identificatore su un file noto, ma
 questo ovviamente comporta lo svantaggio di doverselo andare a rileggere.  Una
 alternativa più efficace è quella che i programmi usino un valore comune per
@@ -876,13 +880,13 @@ nome di un file ed un numero di versione; il suo prototipo 
 \end{functions}
 
 La funzione determina un valore della chiave sulla base di \param{pathname},
-che deve specificare il pathname di un file effettivamente esistente e di un
-numero di progetto \param{proj\_id)}, che di norma viene specificato come
-carattere, dato che ne vengono utilizzati solo gli 8 bit meno
-significativi.\footnote{nelle libc4 e libc5, come avviene in SunOS,
-  l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, le \acr{glibc}
-  usano il prototipo specificato da XPG4, ma vengono lo stesso utilizzati gli
-  8 bit meno significativi.}
+che deve specificare il \itindex{pathname}\textit{pathname} di un file
+effettivamente esistente e di un numero di progetto \param{proj\_id)}, che di
+norma viene specificato come carattere, dato che ne vengono utilizzati solo
+gli 8 bit meno significativi.\footnote{nelle libc4 e libc5, come avviene in
+  SunOS, l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, le
+  \acr{glibc} usano il prototipo specificato da XPG4, ma vengono lo stesso
+  utilizzati gli 8 bit meno significativi.}
 
 Il problema è che anche così non c'è la sicurezza che il valore della chiave
 sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
@@ -910,7 +914,7 @@ problema del \textit{SysV IPC}. Non esiste infatti una modalit
 identificare un oggetto, come sarebbe stato se lo si fosse associato ad in
 file, e tutta l'interfaccia è inutilmente complessa.  Per questo ne è stata
 effettuata una revisione completa nello standard POSIX.1b, che tratteremo in
-\secref{sec:ipc_posix}.
+sez.~\ref{sec:ipc_posix}.
 
 
 \subsection{Il controllo di accesso}
@@ -921,7 +925,7 @@ Oltre alle chiavi, abbiamo visto che ad ogni oggetto sono associate in
 (nei campi \var{cuid} e \var{cgid}) e del proprietario (nei campi \var{uid} e
 \var{gid}) dello stesso, e un insieme di permessi (nel campo \var{mode}). In
 questo modo è possibile definire un controllo di accesso sugli oggetti di IPC,
-simile a quello che si ha per i file (vedi \secref{sec:file_perm_overview}).
+simile a quello che si ha per i file (vedi sez.~\ref{sec:file_perm_overview}).
 
 Benché questo controllo di accesso sia molto simile a quello dei file, restano
 delle importanti differenze. La prima è che il permesso di esecuzione non
@@ -929,7 +933,7 @@ esiste (e se specificato viene ignorato), per cui si pu
 permessi di lettura e scrittura (nel caso dei semafori poi quest'ultimo è più
 propriamente un permesso di modifica). I valori di \var{mode} sono gli stessi
 ed hanno lo stesso significato di quelli riportati in
-\secref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
+tab.~\ref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
   simboliche ivi definite occorrerà includere il file \file{sys/stat.h},
   alcuni sistemi definiscono le costanti \const{MSG\_R} (\texttt{0400}) e
   \const{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
@@ -939,9 +943,9 @@ ed hanno lo stesso significato di quelli riportati in
 il proprietario, il suo gruppo e tutti gli altri.
 
 Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di
-\struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono settati
-rispettivamente al valore dell'user-ID e del group-ID effettivo del processo che
-ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
+\struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono impostati
+rispettivamente al valore dell'user-ID e del group-ID effettivo del processo
+che ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
 essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
 
 Il controllo di accesso è effettuato a due livelli. Il primo livello è nelle
@@ -963,7 +967,7 @@ controlli 
 \item se l'user-ID effettivo del processo corrisponde o al valore del campo
   \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
   in \var{mode} è appropriato\footnote{per appropriato si intende che è
-    settato il permesso di scrittura per le operazioni di scrittura e quello
+    impostato il permesso di scrittura per le operazioni di scrittura e quello
     di lettura per le operazioni di lettura.} l'accesso è consentito.
 \item se il group-ID effettivo del processo corrisponde o al
   valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
@@ -975,14 +979,14 @@ a differenza di quanto avviene per i permessi dei file, fallire in uno dei
 passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
 differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
 il valore di \var{umask} (si ricordi quanto esposto in
-\secref{sec:file_umask}) non ha alcun significato.
+sez.~\ref{sec:file_umask}) non ha alcun significato.
 
 
 \subsection{Gli identificatori ed il loro utilizzo}
 \label{sec:ipc_sysv_id_use}
 
 L'unico campo di \struct{ipc\_perm} del quale non abbiamo ancora parlato è
-\var{seq}, che in \figref{fig:ipc_ipc_perm} è qualificato con un criptico
+\var{seq}, che in fig.~\ref{fig:ipc_ipc_perm} è qualificato con un criptico
 ``\textsl{numero di sequenza}'', ne parliamo adesso dato che esso è
 strettamente attinente alle modalità con cui il kernel assegna gli
 identificatori degli oggetti del sistema di IPC.
@@ -1039,12 +1043,12 @@ s
   \label{fig:ipc_sysv_idtest}
 \end{figure}
 
-In \figref{fig:ipc_sysv_idtest} è riportato il codice di un semplice programma
-di test che si limita a creare un oggetto (specificato a riga di comando),
-stamparne il numero di identificatore e cancellarlo per un numero specificato
-di volte. Al solito non si è riportato il codice della gestione delle opzioni
-a riga di comando, che permette di specificare quante volte effettuare il
-ciclo \var{n}, e su quale tipo di oggetto eseguirlo.
+In fig.~\ref{fig:ipc_sysv_idtest} è riportato il codice di un semplice
+programma di test che si limita a creare un oggetto (specificato a riga di
+comando), stamparne il numero di identificatore e cancellarlo per un numero
+specificato di volte. Al solito non si è riportato il codice della gestione
+delle opzioni a riga di comando, che permette di specificare quante volte
+effettuare il ciclo \var{n}, e su quale tipo di oggetto eseguirlo.
 
 La figura non riporta il codice di selezione delle opzioni, che permette di
 inizializzare i valori delle variabili \var{type} al tipo di oggetto voluto, e
@@ -1133,7 +1137,7 @@ Se invece si vuole creare una nuova coda di messaggi \param{flag} non pu
 essere nullo e deve essere fornito come maschera binaria, impostando il bit
 corrispondente al valore \const{IPC\_CREAT}. In questo caso i nove bit meno
 significativi di \param{flag} saranno usati come permessi per il nuovo
-oggetto, secondo quanto illustrato in \secref{sec:ipc_sysv_access_control}.
+oggetto, secondo quanto illustrato in sez.~\ref{sec:ipc_sysv_access_control}.
 Se si imposta anche il bit corrispondente a \const{IPC\_EXCL} la funzione avrà
 successo solo se l'oggetto non esiste già, fallendo con un errore di
 \errcode{EEXIST} altrimenti.
@@ -1170,7 +1174,7 @@ coda.
 
 Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti
 negli header e corrispondenti alle prime tre costanti riportate in
-\tabref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
+tab.~\ref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
 modificare questi limiti attraverso l'uso di \func{sysctl} o scrivendo nei
 file \file{msgmax}, \file{msgmnb} e \file{msgmni} di \file{/proc/sys/kernel/}.
 
@@ -1182,22 +1186,23 @@ file \file{msgmax}, \file{msgmnb} e \file{msgmni} di \file{/proc/sys/kernel/}.
 \end{figure}
 
 
-Una coda di messaggi è costituita da una \textit{linked list};\footnote{una
-  \textit{linked list} è una tipica struttura di dati, organizzati in una
-  lista in cui ciascun elemento contiene un puntatore al successivo. In questo
-  modo la struttura è veloce nell'estrazione ed immissione dei dati dalle
-  estremità dalla lista (basta aggiungere un elemento in testa o in coda ed
-  aggiornare un puntatore), e relativamente veloce da attraversare in ordine
-  sequenziale (seguendo i puntatori), è invece relativamente lenta
-  nell'accesso casuale e nella ricerca.}  i nuovi messaggi vengono inseriti in
-coda alla lista e vengono letti dalla cima, in \figref{fig:ipc_mq_schema} si è
-riportato lo schema con cui queste strutture vengono mantenute dal
-kernel.\footnote{lo schema illustrato in \figref{fig:ipc_mq_schema} è in
-  realtà una semplificazione di quello usato effettivamente fino ai kernel
-  della serie 2.2.x, nei kernel della serie 2.4.x la gestione delle code di
-  messaggi è stata modificata ed è effettuata in maniera diversa; abbiamo
-  mantenuto lo schema precedente in quanto illustra comunque in maniera più
-  che adeguata i principi di funzionamento delle code di messaggi.}
+Una coda di messaggi è costituita da una \itindex{linked~list}\textit{linked
+  list};\footnote{una \textit{linked list} è una tipica struttura di dati,
+  organizzati in una lista in cui ciascun elemento contiene un puntatore al
+  successivo. In questo modo la struttura è veloce nell'estrazione ed
+  immissione dei dati dalle estremità dalla lista (basta aggiungere un
+  elemento in testa o in coda ed aggiornare un puntatore), e relativamente
+  veloce da attraversare in ordine sequenziale (seguendo i puntatori), è
+  invece relativamente lenta nell'accesso casuale e nella ricerca.}  i nuovi
+messaggi vengono inseriti in coda alla lista e vengono letti dalla cima, in
+fig.~\ref{fig:ipc_mq_schema} si è riportato lo schema con cui queste strutture
+vengono mantenute dal kernel.\footnote{lo schema illustrato in
+  fig.~\ref{fig:ipc_mq_schema} è in realtà una semplificazione di quello usato
+  effettivamente fino ai kernel della serie 2.2.x, nei kernel della serie
+  2.4.x la gestione delle code di messaggi è stata modificata ed è effettuata
+  in maniera diversa; abbiamo mantenuto lo schema precedente in quanto
+  illustra comunque in maniera più che adeguata i principi di funzionamento
+  delle code di messaggi.}
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1211,22 +1216,22 @@ kernel.\footnote{lo schema illustrato in \figref{fig:ipc_mq_schema} 
 \end{figure}
 
 A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
-definizione, è riportata in \secref{fig:ipc_msqid_ds}. In questa struttura il
+definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura il
 kernel mantiene le principali informazioni riguardo lo stato corrente della
 coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2.x,
   essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
   quanto è quella restituita dalle funzioni dell'interfaccia.  Si noti come ci
   sia una differenza con i campi mostrati nello schema di
-  \figref{fig:ipc_mq_schema} che sono presi dalla definizione di
+  fig.~\ref{fig:ipc_mq_schema} che sono presi dalla definizione di
   \file{linux/msg.h}, e fanno riferimento alla definizione della omonima
-  struttura usata nel kernel.} In \figref{fig:ipc_msqid_ds} sono elencati i
+  struttura usata nel kernel.} In fig.~\ref{fig:ipc_msqid_ds} sono elencati i
 campi significativi definiti in \file{sys/msg.h}, a cui si sono aggiunti gli
 ultimi tre campi che sono previsti dalla implementazione originale di System
 V, ma non dallo standard Unix98.
 
 Quando si crea una nuova coda con \func{msgget} questa struttura viene
 inizializzata, in particolare il campo \var{msg\_perm} viene inizializzato
-come illustrato in \secref{sec:ipc_sysv_access_control}, per quanto riguarda
+come illustrato in sez.~\ref{sec:ipc_sysv_access_control}, per quanto riguarda
 gli altri campi invece:
 \begin{itemize*}
 \item il campo \var{msg\_qnum}, che esprime il numero di messaggi presenti
@@ -1289,7 +1294,7 @@ eseguire; i valori possibili sono:
 \item[\const{IPC\_RMID}] Rimuove la coda, cancellando tutti i dati, con
   effetto immediato. Tutti i processi che cercheranno di accedere alla coda
   riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
-  funzioni di di lettura o di scrittura sulla coda saranno svegliati ricevendo
+  funzioni di lettura o di scrittura sulla coda saranno svegliati ricevendo
   il medesimo errore. Questo comando può essere eseguito solo da un processo
   con user-ID effettivo corrispondente al creatore o al proprietario della
   coda, o all'amministratore.
@@ -1338,11 +1343,11 @@ La funzione inserisce il messaggio sulla coda specificata da \param{msqid}; il
 messaggio ha lunghezza specificata da \param{msgsz} ed è passato attraverso il
 l'argomento \param{msgp}.  Quest'ultimo deve venire passato sempre come
 puntatore ad una struttura \struct{msgbuf} analoga a quella riportata in
-\figref{fig:ipc_msbuf} che è quella che deve contenere effettivamente il
+fig.~\ref{fig:ipc_msbuf} che è quella che deve contenere effettivamente il
 messaggio.  La dimensione massima per il testo di un messaggio non può
 comunque superare il limite \const{MSGMAX}.
 
-La struttura di \figref{fig:ipc_msbuf} è comunque solo un modello, tanto che
+La struttura di fig.~\ref{fig:ipc_msbuf} è comunque solo un modello, tanto che
 la definizione contenuta in \file{sys/msg.h} usa esplicitamente per il secondo
 campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini pratici.
 La sola cosa che conta è che la struttura abbia come primo membro un campo
@@ -1352,7 +1357,7 @@ messaggio e deve essere sempre specificato come intero positivo di tipo
 dimensione, e serve a contenere il testo del messaggio.
 
 In generale pertanto per inviare un messaggio con \func{msgsnd} si usa
-ridefinire una struttura simile a quella di \figref{fig:ipc_msbuf}, adattando
+ridefinire una struttura simile a quella di fig.~\ref{fig:ipc_msbuf}, adattando
 alle proprie esigenze il campo \var{mtype}, (o ridefinendo come si vuole il
 corpo del messaggio, anche con più campi o con strutture più complesse) avendo
 però la cura di mantenere nel primo campo un valore di tipo \ctyp{long} che ne
@@ -1362,7 +1367,7 @@ Si tenga presente che la lunghezza che deve essere indicata in questo
 argomento è solo quella del messaggio, non quella di tutta la struttura, se
 cioè \var{message} è una propria struttura che si passa alla funzione,
 \param{msgsz} dovrà essere uguale a \code{sizeof(message)-sizeof(long)}, (se
-consideriamo il caso dell'esempio in \figref{fig:ipc_msbuf}, \param{msgsz}
+consideriamo il caso dell'esempio in fig.~\ref{fig:ipc_msbuf}, \param{msgsz}
 dovrà essere pari a \const{LENGTH}).
 
 \begin{figure}[!htb]
@@ -1378,7 +1383,7 @@ dovr
 
 Per capire meglio il funzionamento della funzione riprendiamo in
 considerazione la struttura della coda illustrata in
-\figref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
+fig.~\ref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
 sarà aggiunto in fondo alla lista inserendo una nuova struttura \struct{msg},
 il puntatore \var{msg\_last} di \struct{msqid\_ds} verrà aggiornato, come pure
 il puntatore al messaggio successivo per quello che era il precedente ultimo
@@ -1443,10 +1448,10 @@ La funzione che viene utilizzata per estrarre un messaggio da una coda 
 
 La funzione legge un messaggio dalla coda specificata, scrivendolo sulla
 struttura puntata da \param{msgp}, che dovrà avere un formato analogo a quello
-di \figref{fig:ipc_msbuf}.  Una volta estratto, il messaggio sarà rimosso dalla
-coda.  L'argomento \param{msgsz} indica la lunghezza massima del testo del
-messaggio (equivalente al valore del parametro \const{LENGTH} nell'esempio di
-\figref{fig:ipc_msbuf}).
+di fig.~\ref{fig:ipc_msbuf}.  Una volta estratto, il messaggio sarà rimosso
+dalla coda.  L'argomento \param{msgsz} indica la lunghezza massima del testo
+del messaggio (equivalente al valore del parametro \const{LENGTH} nell'esempio
+di fig.~\ref{fig:ipc_msbuf}).
 
 Se il testo del messaggio ha lunghezza inferiore a \param{msgsz} esso viene
 rimosso dalla coda; in caso contrario, se \param{msgflg} è impostato a
@@ -1456,13 +1461,13 @@ un errore di \errcode{E2BIG}.
 
 L'argomento \param{msgtyp} permette di restringere la ricerca ad un
 sottoinsieme dei messaggi presenti sulla coda; la ricerca infatti è fatta con
-una scansione della struttura mostrata in \figref{fig:ipc_mq_schema},
+una scansione della struttura mostrata in fig.~\ref{fig:ipc_mq_schema},
 restituendo il primo messaggio incontrato che corrisponde ai criteri
 specificati (che quindi, visto come i messaggi vengono sempre inseriti dalla
 coda, è quello meno recente); in particolare:
 \begin{itemize}
 \item se \param{msgtyp} è 0 viene estratto il messaggio in cima alla coda, cioè
-  quello fra i presenti che è stato inserito inserito per primo. 
+  quello fra i presenti che è stato inserito per primo. 
 \item se \param{msgtyp} è positivo viene estratto il primo messaggio il cui
   tipo (il valore del campo \var{mtype}) corrisponde al valore di
   \param{msgtyp}.
@@ -1505,16 +1510,16 @@ tutte le risorse occupate vengono rilasciate quanto l'ultimo processo che le
 utilizzava termina. Questo comporta che in caso di errori si può saturare il
 sistema, e che devono comunque essere esplicitamente previste delle funzioni
 di rimozione in caso di interruzioni o uscite dal programma (come vedremo in
-\figref{fig:ipc_mq_fortune_server}).
+fig.~\ref{fig:ipc_mq_fortune_server}).
 
 L'altro problema è non facendo uso di file descriptor le tecniche di
-\textit{I/O multiplexing} descritte in \secref{sec:file_multiplexing} non
+\textit{I/O multiplexing} descritte in sez.~\ref{sec:file_multiplexing} non
 possono essere utilizzate, e non si ha a disposizione niente di analogo alle
 funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di
 una di queste strutture alla volta; ad esempio non si può scrivere un server
 che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica
-di \textit{polling}\index{polling} che esegua un ciclo di attesa su ciascuna
-di esse.
+di \textit{polling}\itindex{polling} che esegua un ciclo di attesa su
+ciascuna di esse.
 
 Come esempio dell'uso delle code di messaggi possiamo riscrivere il nostro
 server di \textit{fortunes} usando queste al posto delle fifo. In questo caso
@@ -1532,7 +1537,7 @@ in maniera indipendente con client diversi.
   \label{fig:ipc_mq_fortune_server}
 \end{figure}
 
-In \figref{fig:ipc_mq_fortune_server} si è riportato un estratto delle parti
+In fig.~\ref{fig:ipc_mq_fortune_server} si è riportato un estratto delle parti
 principali del codice del nuovo server (il codice completo è nel file
 \file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un
 uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi
@@ -1606,13 +1611,13 @@ gestore \code{HandSIGTERM}, che semplicemente si limita a cancellare la coda
   \label{fig:ipc_mq_fortune_client}
 \end{figure}
 
-In \figref{fig:ipc_mq_fortune_client} si è riportato un estratto il codice del
-programma client.  Al solito il codice completo è con i sorgenti allegati, nel
-file \file{MQFortuneClient.c}.  Come sempre si sono rimosse le parti relative
-alla gestione delle opzioni, ed in questo caso, anche la dichiarazione delle
-variabili, che, per la parte relative alle strutture usate per la
-comunicazione tramite le code, sono le stesse viste in
-\figref{fig:ipc_mq_fortune_server}.
+In fig.~\ref{fig:ipc_mq_fortune_client} si è riportato un estratto il codice
+del programma client.  Al solito il codice completo è con i sorgenti allegati,
+nel file \file{MQFortuneClient.c}.  Come sempre si sono rimosse le parti
+relative alla gestione delle opzioni, ed in questo caso, anche la
+dichiarazione delle variabili, che, per la parte relative alle strutture usate
+per la comunicazione tramite le code, sono le stesse viste in
+fig.~\ref{fig:ipc_mq_fortune_server}.
 
 Il client in questo caso è molto semplice; la prima parte del programma
 (\texttt{\small 4--9}) si occupa di accedere alla coda di messaggi, ed è
@@ -1634,7 +1639,7 @@ passo (\texttt{\small 17}) prima di uscire 
 messaggio ricevuto.
  
 Proviamo allora il nostro nuovo sistema, al solito occorre definire
-\code{LD\_LIBRAY\_PATH} per accedere alla libreria \file{libgapil.so}, dopo di
+\code{LD\_LIBRARY\_PATH} per accedere alla libreria \file{libgapil.so}, dopo di
 che, in maniera del tutto analoga a quanto fatto con il programma che usa le
 fifo, potremo far partire il server con:
 \begin{verbatim}
@@ -1689,8 +1694,8 @@ indirizzato a lui.
 I semafori non sono meccanismi di intercomunicazione diretta come quelli
 (pipe, fifo e code di messaggi) visti finora, e non consentono di scambiare
 dati fra processi, ma servono piuttosto come meccanismi di sincronizzazione o
-di protezione per le \textsl{sezioni critiche}\index{sezioni critiche} del
-codice (si ricordi quanto detto in \secref{sec:proc_race_cond}). 
+di protezione per le \textsl{sezioni critiche} \index{sezione~critica} del
+codice (si ricordi quanto detto in sez.~\ref{sec:proc_race_cond}). 
 
 Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a
 seconda del suo valore, di consentire o meno la prosecuzione dell'esecuzione
@@ -1759,7 +1764,7 @@ permette di creare o ottenere l'identificatore di un insieme di semafori 
 La funzione è del tutto analoga a \func{msgget}, solo che in questo caso
 restituisce l'identificatore di un insieme di semafori, in particolare è
 identico l'uso degli argomenti \param{key} e \param{flag}, per cui non
-ripeteremo quanto detto al proposito in \secref{sec:ipc_sysv_mq}. L'argomento
+ripeteremo quanto detto al proposito in sez.~\ref{sec:ipc_sysv_mq}. L'argomento
 \param{nsems} permette di specificare quanti semafori deve contenere l'insieme
 quando se ne richieda la creazione, e deve essere nullo quando si effettua una
 richiesta dell'identificatore di un insieme già esistente.
@@ -1797,14 +1802,15 @@ semaforo all'uscita del processo.
 \end{figure}
 
 A ciascun insieme di semafori è associata una struttura \struct{semid\_ds},
-riportata in \figref{fig:ipc_semid_ds}.\footnote{non si sono riportati i campi
-  ad uso interno del kernel, che vedremo in \figref{fig:ipc_sem_schema}, che
-  dipendono dall'implementazione.} Come nel caso delle code di messaggi quando
-si crea un nuovo insieme di semafori con \func{semget} questa struttura viene
-inizializzata, in particolare il campo \var{sem\_perm} viene inizializzato
-come illustrato in \secref{sec:ipc_sysv_access_control} (si ricordi che in
-questo caso il permesso di scrittura è in realtà permesso di alterare il
-semaforo), per quanto riguarda gli altri campi invece:
+riportata in fig.~\ref{fig:ipc_semid_ds}.\footnote{non si sono riportati i
+  campi ad uso interno del kernel, che vedremo in
+  fig.~\ref{fig:ipc_sem_schema}, che dipendono dall'implementazione.} Come nel
+caso delle code di messaggi quando si crea un nuovo insieme di semafori con
+\func{semget} questa struttura viene inizializzata, in particolare il campo
+\var{sem\_perm} viene inizializzato come illustrato in
+sez.~\ref{sec:ipc_sysv_access_control} (si ricordi che in questo caso il
+permesso di scrittura è in realtà permesso di alterare il semaforo), per
+quanto riguarda gli altri campi invece:
 \begin{itemize*}
 \item il campo \var{sem\_nsems}, che esprime il numero di semafori
   nell'insieme, viene inizializzato al valore di \param{nsems}.
@@ -1822,10 +1828,10 @@ Ciascun semaforo dell'insieme 
   ormai è ridotta ai soli due primi membri, e gli altri vengono calcolati
   dinamicamente. La si è utilizzata a scopo di esempio, perché indica tutti i
   valori associati ad un semaforo, restituiti dalle funzioni di controllo, e
-  citati dalle pagine di manuale.} è riportata in \figref{fig:ipc_sem}. Questa
-struttura, non è accessibile in user space, ma i valori in essa specificati
-possono essere letti in maniera indiretta, attraverso l'uso delle funzioni di
-controllo.
+  citati dalle pagine di manuale.} è riportata in fig.~\ref{fig:ipc_sem}.
+Questa struttura, non è accessibile in user space, ma i valori in essa
+specificati possono essere letti in maniera indiretta, attraverso l'uso delle
+funzioni di controllo.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -1838,7 +1844,7 @@ controllo.
   \label{fig:ipc_sem}
 \end{figure}
 
-I dati mantenuti nella struttura, ed elencati in \figref{fig:ipc_sem},
+I dati mantenuti nella struttura, ed elencati in fig.~\ref{fig:ipc_sem},
 indicano rispettivamente:
 \begin{description*}
 \item[\var{semval}] il valore numerico del semaforo.
@@ -1877,8 +1883,8 @@ indicano rispettivamente:
 
 Come per le code di messaggi anche per gli insiemi di semafori esistono una
 serie di limiti, i cui valori sono associati ad altrettante costanti, che si
-sono riportate in \tabref{tab:ipc_sem_limits}. Alcuni di questi limiti sono al
-solito accessibili e modificabili attraverso \func{sysctl} o scrivendo
+sono riportate in tab.~\ref{tab:ipc_sem_limits}. Alcuni di questi limiti sono
+al solito accessibili e modificabili attraverso \func{sysctl} o scrivendo
 direttamente nel file \file{/proc/sys/kernel/sem}.
 
 La funzione che permette di effettuare le varie operazioni di controllo sui
@@ -1912,7 +1918,7 @@ loro inizializzazione) 
 }
 \end{functions}
 
-La funzione può avere tre o quattro parametri, a seconda dell'operazione
+La funzione può avere tre o quattro argomenti, a seconda dell'operazione
 specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
 \param{semid} o sul singolo semaforo di un insieme, specificato da
 \param{semnum}. 
@@ -1933,10 +1939,10 @@ Qualora la funzione operi con quattro argomenti \param{arg} 
 generico, che conterrà un dato diverso a seconda dell'azione richiesta; per
 unificare l'argomento esso deve essere passato come una \struct{semun}, la cui
 definizione, con i possibili valori che può assumere, è riportata in
-\figref{fig:ipc_semun}.
+fig.~\ref{fig:ipc_semun}.
 
 Come già accennato sia il comportamento della funzione che il numero di
-parametri con cui deve essere invocata, dipendono dal valore dell'argomento
+argomenti con cui deve essere invocata dipendono dal valore dell'argomento
 \param{cmd}, che specifica l'azione da intraprendere; i valori validi (che
 cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i
 seguenti:
@@ -2018,7 +2024,7 @@ tutti i semafori il cui valore viene modificato.
 Il valore di ritorno della funzione in caso di successo dipende
 dall'operazione richiesta; per tutte le operazioni che richiedono quattro
 argomenti esso è sempre nullo, per le altre operazioni, elencate in
-\tabref{tab:ipc_semctl_returns} viene invece restituito il valore richiesto,
+tab.~\ref{tab:ipc_semctl_returns} viene invece restituito il valore richiesto,
 corrispondente al campo della struttura \struct{sem} indicato nella seconda
 colonna della tabella.
 
@@ -2076,7 +2082,7 @@ effettivamente eseguite se e soltanto se 
 
 Il contenuto di ciascuna operazione deve essere specificato attraverso una
 opportuna struttura \struct{sembuf} (la cui definizione è riportata in
-\figref{fig:ipc_sembuf}) che il programma chiamante deve avere cura di
+fig.~\ref{fig:ipc_sembuf}) che il programma chiamante deve avere cura di
 allocare in un opportuno vettore. La struttura permette di indicare il
 semaforo su cui operare, il tipo di operazione, ed un flag di controllo.
 Il campo \var{sem\_num} serve per indicare a quale semaforo dell'insieme fa
@@ -2167,7 +2173,7 @@ una \func{exec} (altrimenti non si avrebbe ripristino).
 
 Tutto questo però ha un problema di fondo. Per capire di cosa si tratta
 occorre fare riferimento all'implementazione usata in Linux, che è riportata
-in maniera semplificata nello schema di \figref{fig:ipc_sem_schema}.  Si è
+in maniera semplificata nello schema di fig.~\ref{fig:ipc_sem_schema}.  Si è
 presa come riferimento l'architettura usata fino al kernel 2.2.x che è più
 semplice (ed illustrata in dettaglio in \cite{tlk}); nel kernel 2.4.x la
 struttura del \textit{SysV IPC} è stata modificata, ma le definizioni relative
@@ -2175,7 +2181,7 @@ a queste strutture restano per compatibilit
   vecchie versioni delle librerie del C, come le libc5.}
 
 \begin{figure}[htb]
-  \centering \includegraphics[width=15cm]{img/semtruct}
+  \centering \includegraphics[width=13cm]{img/semtruct}
   \caption{Schema della struttura di un insieme di semafori.}
   \label{fig:ipc_sem_schema}
 \end{figure}
@@ -2187,11 +2193,13 @@ possono avere successo; se una di esse comporta il blocco del processo il
 kernel crea una struttura \struct{sem\_queue} che viene aggiunta in fondo alla
 coda di attesa associata a ciascun insieme di semafori\footnote{che viene
   referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last}
-  di \struct{semid\_ds}.}. Nella struttura viene memorizzato il riferimento
-alle operazioni richieste (nel campo \var{sops}, che è un puntatore ad una
-struttura \struct{sembuf}) e al processo corrente (nel campo \var{sleeper}) poi
-quest'ultimo viene messo stato di attesa e viene invocato lo
-scheduler\index{scheduler} per passare all'esecuzione di un altro processo.
+  di \struct{semid\_ds}.}. 
+
+Nella struttura viene memorizzato il riferimento alle operazioni richieste
+(nel campo \var{sops}, che è un puntatore ad una struttura \struct{sembuf}) e
+al processo corrente (nel campo \var{sleeper}) poi quest'ultimo viene messo
+stato di attesa e viene invocato lo scheduler\itindex{scheduler} per passare
+all'esecuzione di un altro processo.
 
 Se invece tutte le operazioni possono avere successo queste vengono eseguite
 immediatamente, dopo di che il kernel esegue una scansione della coda di
@@ -2200,13 +2208,12 @@ operazioni sospese in precedenza pu
 struttura \struct{sem\_queue} viene rimossa e lo stato del processo associato
 all'operazione (\var{sleeper}) viene riportato a \textit{running}; il tutto
 viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
-svuotata la coda.
-
-Per gestire il meccanismo del ripristino tutte le volte che per un'operazione
-si è specificato il flag \const{SEM\_UNDO} viene mantenuta per ciascun insieme
-di semafori una apposita struttura \struct{sem\_undo} che contiene (nel vettore
-puntato dal campo \var{semadj}) un valore di aggiustamento per ogni semaforo
-cui viene sommato l'opposto del valore usato per l'operazione. 
+svuotata la coda.  Per gestire il meccanismo del ripristino tutte le volte che
+per un'operazione si è specificato il flag \const{SEM\_UNDO} viene mantenuta
+per ciascun insieme di semafori una apposita struttura \struct{sem\_undo} che
+contiene (nel vettore puntato dal campo \var{semadj}) un valore di
+aggiustamento per ogni semaforo cui viene sommato l'opposto del valore usato
+per l'operazione.
 
 Queste strutture sono mantenute in due liste,\footnote{rispettivamente
   attraverso i due campi \var{id\_next} e \var{proc\_next}.} una associata
@@ -2216,25 +2223,26 @@ operazione con \func{semctl}; l'altra associata al processo che ha eseguito
 l'operazione;\footnote{attraverso il campo \var{semundo} di
   \struct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
 processo termina, la lista ad esso associata viene scandita e le operazioni
-applicate al semaforo.
-
-Siccome un processo può accumulare delle richieste di ripristino per semafori
-differenti chiamate attraverso diverse chiamate a \func{semop}, si pone il
-problema di come eseguire il ripristino dei semafori all'uscita del processo,
-ed in particolare se questo può essere fatto atomicamente. Il punto è cosa
-succede quando una delle operazioni previste per il ripristino non può essere
-eseguita immediatamente perché ad esempio il semaforo è occupato; in tal caso
-infatti, se si pone il processo in stato di \textit{sleep} aspettando la
-disponibilità del semaforo (come faceva l'implementazione originaria) si perde
-l'atomicità dell'operazione. La scelta fatta dal kernel è pertanto quella di
-effettuare subito le operazioni che non prevedono un blocco del processo e di
-ignorare silenziosamente le altre; questo però comporta il fatto che il
-ripristino non è comunque garantito in tutte le occasioni.
+applicate al semaforo.  Siccome un processo può accumulare delle richieste di
+ripristino per semafori differenti chiamate attraverso diverse chiamate a
+\func{semop}, si pone il problema di come eseguire il ripristino dei semafori
+all'uscita del processo, ed in particolare se questo può essere fatto
+atomicamente.
+
+Il punto è cosa succede quando una delle operazioni previste per il ripristino
+non può essere eseguita immediatamente perché ad esempio il semaforo è
+occupato; in tal caso infatti, se si pone il processo in stato di
+\textit{sleep} aspettando la disponibilità del semaforo (come faceva
+l'implementazione originaria) si perde l'atomicità dell'operazione. La scelta
+fatta dal kernel è pertanto quella di effettuare subito le operazioni che non
+prevedono un blocco del processo e di ignorare silenziosamente le altre;
+questo però comporta il fatto che il ripristino non è comunque garantito in
+tutte le occasioni.
 
 Come esempio di uso dell'interfaccia dei semafori vediamo come implementare
 con essa dei semplici \textit{mutex} (cioè semafori binari), tutto il codice
 in questione, contenuto nel file \file{Mutex.c} allegato ai sorgenti, è
-riportato in \figref{fig:ipc_mutex_create}. Utilizzeremo l'interfaccia per
+riportato in fig.~\ref{fig:ipc_mutex_create}. Utilizzeremo l'interfaccia per
 creare un insieme contenente un singolo semaforo, per il quale poi useremo un
 valore unitario per segnalare la disponibilità della risorsa, ed un valore
 nullo per segnalarne l'indisponibilità. 
@@ -2306,9 +2314,9 @@ non avrebbe pi
 considerata libera).  Infine si tenga presente che usare \func{MutexRead} per
 controllare il valore dei mutex prima di proseguire in una operazione di
 sblocco non servirebbe comunque, dato che l'operazione non sarebbe atomica.
-Vedremo in \secref{sec:ipc_lock_file} come sia possibile ottenere
+Vedremo in sez.~\ref{sec:ipc_lock_file} come sia possibile ottenere
 un'interfaccia analoga a quella appena illustrata, senza incorrere in questi
-problemi, usando il file locking\index{file!locking}.
+problemi, usando il \index{file!locking} \textit{file locking}.
 
 
 \subsection{Memoria condivisa}
@@ -2345,7 +2353,7 @@ ed il suo prototipo 
 
 La funzione, come \func{semget}, è del tutto analoga a \func{msgget}, ed
 identico è l'uso degli argomenti \param{key} e \param{flag} per cui non
-ripeteremo quanto detto al proposito in \secref{sec:ipc_sysv_mq}. L'argomento
+ripeteremo quanto detto al proposito in sez.~\ref{sec:ipc_sysv_mq}. L'argomento
 \param{size} specifica invece la dimensione, in byte, del segmento, che viene
 comunque arrotondata al multiplo superiore di \const{PAGE\_SIZE}.
 
@@ -2379,11 +2387,11 @@ norma, significa insieme a dei semafori.
 \end{figure}
 
 A ciascun segmento di memoria condivisa è associata una struttura
-\struct{shmid\_ds}, riportata in \figref{fig:ipc_shmid_ds}.  Come nel caso
+\struct{shmid\_ds}, riportata in fig.~\ref{fig:ipc_shmid_ds}.  Come nel caso
 delle code di messaggi quando si crea un nuovo segmento di memoria condivisa
 con \func{shmget} questa struttura viene inizializzata, in particolare il
 campo \var{shm\_perm} viene inizializzato come illustrato in
-\secref{sec:ipc_sysv_access_control}, e valgono le considerazioni ivi fatte
+sez.~\ref{sec:ipc_sysv_access_control}, e valgono le considerazioni ivi fatte
 relativamente ai permessi di accesso; per quanto riguarda gli altri campi
 invece:
 \begin{itemize}
@@ -2408,7 +2416,7 @@ di questi limiti sono al solito accessibili e modificabili attraverso
 \func{sysctl} o scrivendo direttamente nei rispettivi file di
 \file{/proc/sys/kernel/}. 
 
-In \tabref{tab:ipc_shm_limits} si sono riportate le
+In tab.~\ref{tab:ipc_shm_limits} si sono riportate le
 costanti simboliche associate a ciascuno di essi, il loro significato, i
 valori preimpostati, e, quando presente, il file in \file{/proc/sys/kernel/}
 che permettono di cambiarne il valore. 
@@ -2473,7 +2481,7 @@ un segmento di memoria condivisa 
       \const{IPC\_RMID} senza i permessi necessari.
     \item[\errcode{EOVERFLOW}] Si è tentato il comando \const{IPC\_STAT} ma il
       valore del group-ID o dell'user-ID è troppo grande per essere
-      memorizzato nella struttura puntata dal \param{buf}.  
+      memorizzato nella struttura puntata da \param{buf}.
     \item[\errcode{EFAULT}] L'indirizzo specificato con \param{buf} non è
       valido.
     \end{errlist}
@@ -2498,19 +2506,20 @@ corrispondente comportamento della funzione, sono i seguenti:
   \var{shm\_perm.uid} e \var{shm\_perm.gid} occorre essere il proprietario o
   il creatore del segmento, oppure l'amministratore. Compiuta l'operazione
   aggiorna anche il valore del campo \var{shm\_ctime}.
-\item[\const{SHM\_LOCK}] Abilita il  
-  \textit{memory locking}\index{memory locking}\footnote{impedisce cioè che la
-    memoria usata per il segmento venga salvata su disco dal meccanismo della
-    memoria virtuale\index{memoria virtuale}; si ricordi quanto trattato in
-    \secref{sec:proc_mem_lock}.} sul segmento di memoria condivisa. Solo
+\item[\const{SHM\_LOCK}] Abilita il \itindex{memory~locking} \textit{memory
+    locking}\footnote{impedisce cioè che la memoria usata per il segmento
+    venga salvata su disco dal meccanismo della \index{memoria~virtuale}
+    memoria virtuale; si ricordi quanto trattato in
+    sez.~\ref{sec:proc_mem_lock}.} sul segmento di memoria condivisa. Solo
+  l'amministratore può utilizzare questo comando.
+\item[\const{SHM\_UNLOCK}] Disabilita il \textit{memory locking}
+  \itindex{memory~locking} sul segmento di memoria condivisa.  Solo
   l'amministratore può utilizzare questo comando.
-\item[\const{SHM\_UNLOCK}] Disabilita il \textit{memory locking} sul segmento
-  di memoria condivisa. Solo l'amministratore può utilizzare questo comando.
 \end{basedescript}
 i primi tre comandi sono gli stessi già visti anche per le code di messaggi e
 gli insiemi di semafori, gli ultimi due sono delle estensioni specifiche
 previste da Linux, che permettono di abilitare e disabilitare il meccanismo
-della memoria virtuale\index{memoria virtuale} per il segmento.
+della memoria virtuale \index{memoria~virtuale} per il segmento.
 
 L'argomento \param{buf} viene utilizzato solo con i comandi \const{IPC\_STAT}
 e \const{IPC\_SET} nel qual caso esso dovrà puntare ad una struttura
@@ -2546,12 +2555,12 @@ il suo prototipo 
 La funzione inserisce un segmento di memoria condivisa all'interno dello
 spazio di indirizzi del processo, in modo che questo possa accedervi
 direttamente, la situazione dopo l'esecuzione di \func{shmat} è illustrata in
-\figref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
-ricordi quanto illustrato al proposito in \secref{sec:proc_mem_layout}). In
+fig.~\ref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
+ricordi quanto illustrato al proposito in sez.~\ref{sec:proc_mem_layout}). In
 particolare l'indirizzo finale del segmento dati (quello impostato da
-\func{brk}, vedi \secref{sec:proc_mem_sbrk}) non viene influenzato. Si tenga
-presente infine che la funzione ha successo anche se il segmento è stato
-marcato per la cancellazione.
+\func{brk}, vedi sez.~\ref{sec:proc_mem_sbrk_alloca}) non viene influenzato.
+Si tenga presente infine che la funzione ha successo anche se il segmento è
+stato marcato per la cancellazione.
 
 \begin{figure}[htb]
   \centering
@@ -2611,7 +2620,7 @@ In caso di successo la funzione aggiorna anche i seguenti campi di
   aumentato di uno.
 \end{itemize*} 
 
-Come accennato in \secref{sec:proc_fork} un segmento di memoria condivisa
+Come accennato in sez.~\ref{sec:proc_fork} un segmento di memoria condivisa
 agganciato ad un processo viene ereditato da un figlio attraverso una
 \func{fork}, dato che quest'ultimo riceve una copia dello spazio degli
 indirizzi del padre. Invece, dato che attraverso una \func{exec} viene
@@ -2632,7 +2641,7 @@ dell'interfaccia, \funcd{shmdt}, il cui prototipo 
   
   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
     errore, la funzione fallisce solo quando non c'è un segmento agganciato
-    all'indirizzo \func{shmaddr}, con \var{errno} che assume il valore
+    all'indirizzo \param{shmaddr}, con \var{errno} che assume il valore
     \errval{EINVAL}.}
 \end{functions}
 
@@ -2668,7 +2677,7 @@ viene tolta dallo spazio di indirizzi del processo.
 Come esempio di uso di queste funzioni vediamo come implementare una serie di
 funzioni di libreria che ne semplifichino l'uso, automatizzando le operazioni
 più comuni; il codice, contenuto nel file \file{SharedMem.c}, è riportato in
-\figref{fig:ipc_sysv_shm_func}.
+fig.~\ref{fig:ipc_sysv_shm_func}.
 
 La prima funzione (\texttt{\small 3--16}) è \func{ShmCreate} che, data una
 chiave, crea il segmento di memoria condivisa restituendo il puntatore allo
@@ -2698,7 +2707,7 @@ chiave ed il puntatore associati al segmento di memoria condivisa, prima lo
 sgancia dal processo e poi lo rimuove. Il primo passo (\texttt{\small 37}) è
 la chiamata a \func{shmdt} per sganciare il segmento, restituendo
 (\texttt{\small 38--39}) un valore -1 in caso di errore. Il passo successivo
-(\texttt{\small 41}) è utilizzare \func{shmget} per ottenre l'identificatore
+(\texttt{\small 41}) è utilizzare \func{shmget} per ottenere l'identificatore
 associato al segmento data la chiave \var{key}. Al solito si restituisce un
 valore di -1 (\texttt{\small 42--45}) in caso di errore, mentre se tutto va
 bene si conclude restituendo un valore nullo.
@@ -2710,7 +2719,7 @@ accessi.  Per questo motivo, quando la comunicazione fra processi 
 sequenziale, altri meccanismi come le pipe, le fifo o i socket, che non
 necessitano di sincronizzazione esplicita, sono da preferire. Essa diventa
 l'unico meccanismo possibile quando la comunicazione non è
-sequenziale\footnote{come accennato in \secref{sec:ipc_sysv_mq} per la
+sequenziale\footnote{come accennato in sez.~\ref{sec:ipc_sysv_mq} per la
   comunicazione non sequenziale si possono usare le code di messaggi,
   attraverso l'uso del campo \var{mtype}, ma solo se quest'ultima può essere
   effettuata in forma di messaggio.} o quando non può avvenire secondo una
@@ -2734,7 +2743,7 @@ directory, link simbolici, file normali, ecc.) che saranno salvati in un
 segmento di memoria condivisa cui altri processi potranno accedere per
 ricavare la parte di informazione che interessa.
 
-In \figref{fig:ipc_dirmonitor_main} si è riportata la sezione principale del
+In fig.~\ref{fig:ipc_dirmonitor_main} si è riportata la sezione principale del
 corpo del programma server, insieme alle definizioni delle altre funzioni
 usate nel programma e delle variabili globali, omettendo tutto quello che
 riguarda la gestione delle opzioni e la stampa delle istruzioni di uso a
@@ -2761,17 +2770,17 @@ Il programma, dopo la sezione, omessa, relativa alla gestione delle opzioni da
 riga di comando (che si limitano alla eventuale stampa di un messaggio di
 aiuto a video ed all'impostazione della durata dell'intervallo con cui viene
 ripetuto il calcolo delle proprietà della directory) controlla (\texttt{\small
-  20--23}) che sia stato specificato il parametro necessario contenente il
-nome della directory da tenere sotto controllo, senza il quale esce
-immediatamente con un messaggio di errore.
+  20--23}) che sia stato specificato l'argomento necessario contenente il nome
+della directory da tenere sotto controllo, senza il quale esce immediatamente
+con un messaggio di errore.
 
-Poi, per verificare che il parametro specifichi effettivamente una directory,
+Poi, per verificare che l'argomento specifichi effettivamente una directory,
 si esegue (\texttt{\small 24--26}) su di esso una \func{chdir}, uscendo
 immediatamente in caso di errore.  Questa funzione serve anche per impostare
 la directory di lavoro del programma nella directory da tenere sotto
 controllo, in vista del successivo uso della funzione
 \func{daemon}.\footnote{si noti come si è potuta fare questa scelta,
-  nonostante le indicazioni illustrate in \secref{sec:sess_daemon}, per il
+  nonostante le indicazioni illustrate in sez.~\ref{sec:sess_daemon}, per il
   particolare scopo del programma, che necessita comunque di restare
   all'interno di una directory.} Infine (\texttt{\small 27--29}) si installano
 i gestori per i vari segnali di terminazione che, avendo a che fare con un
@@ -2792,8 +2801,8 @@ abbia successo. Con l'indirizzo \var{shmptr} cos
 accedere alla memoria condivisa, che, per come abbiamo lo abbiamo definito,
 sarà vista nella forma data da \struct{DirProp}. Infine (\texttt{\small
   36--39}) utilizzando sempre la stessa chiave, si crea, tramite le funzioni
-di interfaccia già descritte in \secref{sec:ipc_sysv_sem}, anche un mutex, che
-utilizzeremo per regolare l'accesso alla memoria condivisa.
+di interfaccia già descritte in sez.~\ref{sec:ipc_sysv_sem}, anche un mutex,
+che utilizzeremo per regolare l'accesso alla memoria condivisa.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -2825,13 +2834,13 @@ l'opzione \code{-p} con una \func{sleep}.
 
 Si noti come per il calcolo dei valori da mantenere nella memoria condivisa si
 sia usata ancora una volta la funzione \func{DirScan}, già utilizzata (e
-descritta in dettaglio) in \secref{sec:file_dir_read}, che ci permette di
+descritta in dettaglio) in sez.~\ref{sec:file_dir_read}, che ci permette di
 effettuare la scansione delle voci della directory, chiamando per ciascuna di
 esse la funzione \func{ComputeValues}, che esegue tutti i calcoli necessari.
 
-Il codice di quest'ultima è riportato in \figref{fig:ipc_dirmonitor_sub}. Come
-si vede la funzione (\texttt{\small 2--16}) è molto semplice e si limita a
-chiamare (\texttt{\small 5}) la funzione \func{stat} sul file indicato da
+Il codice di quest'ultima è riportato in fig.~\ref{fig:ipc_dirmonitor_sub}.
+Come si vede la funzione (\texttt{\small 2--16}) è molto semplice e si limita
+a chiamare (\texttt{\small 5}) la funzione \func{stat} sul file indicato da
 ciascuna voce, per ottenerne i dati, che poi utilizza per incrementare i vari
 contatori nella memoria condivisa, cui accede grazie alla variabile globale
 \var{shmptr}.
@@ -2842,14 +2851,14 @@ effettuare nessun controllo e si pu
 condivisa usando \var{shmptr} per riempire i campi della struttura
 \struct{DirProp}; così prima (\texttt{\small 6--7}) si sommano le dimensioni
 dei file ed il loro numero, poi, utilizzando le macro di
-\tabref{tab:file_type_macro}, si contano (\texttt{\small 8--14}) quanti ce ne
-sono per ciascun tipo.
-
-In \figref{fig:ipc_dirmonitor_sub} è riportato anche il codice (\texttt{\small
-  17--23}) del gestore dei segnali di terminazione, usato per chiudere il
-programma. Esso, oltre a provocare l'uscita del programma, si incarica anche
-di cancellare tutti gli oggetti di intercomunicazione non più necessari.  Per
-questo anzitutto (\texttt{\small 19}) acquisisce il mutex con
+tab.~\ref{tab:file_type_macro}, si contano (\texttt{\small 8--14}) quanti ce
+ne sono per ciascun tipo.
+
+In fig.~\ref{fig:ipc_dirmonitor_sub} è riportato anche il codice
+(\texttt{\small 17--23}) del gestore dei segnali di terminazione, usato per
+chiudere il programma. Esso, oltre a provocare l'uscita del programma, si
+incarica anche di cancellare tutti gli oggetti di intercomunicazione non più
+necessari.  Per questo anzitutto (\texttt{\small 19}) acquisisce il mutex con
 \func{MutexLock}, per evitare di operare mentre un client sta ancora leggendo
 i dati, dopo di che (\texttt{\small 20}) distacca e rimuove il segmento di
 memoria condivisa usando \func{ShmRemove}.  Infine (\texttt{\small 21})
@@ -2867,7 +2876,7 @@ rimuove il mutex con \func{MutexRemove} ed esce (\texttt{\small 22}).
 \end{figure}
 
 Il codice del client usato per leggere le informazioni mantenute nella memoria
-condivisa è riportato in \figref{fig:ipc_dirmonitor_client}. Al solito si è
+condivisa è riportato in fig.~\ref{fig:ipc_dirmonitor_client}. Al solito si è
 omessa la sezione di gestione delle opzioni e la funzione che stampa a video
 le istruzioni; il codice completo è nei sorgenti allegati, nel file
 \file{ReadMonitor.c}.
@@ -2966,7 +2975,7 @@ key        msqid      owner      perms      used-bytes   messages
 %% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
 %% riferimento alle strutture con cui il kernel implementa i segmenti di memoria
 %% condivisa; uno schema semplificato della struttura è illustrato in
-%% \figref{fig:ipc_shm_struct}. 
+%% fig.~\ref{fig:ipc_shm_struct}. 
 
 %% \begin{figure}[htb]
 %%   \centering
@@ -2982,7 +2991,7 @@ key        msqid      owner      perms      used-bytes   messages
 \section{Tecniche alternative}
 \label{sec:ipc_alternatives}
 
-Come abbiamo detto in \secref{sec:ipc_sysv_generic}, e ripreso nella
+Come abbiamo detto in sez.~\ref{sec:ipc_sysv_generic}, e ripreso nella
 descrizione dei singoli oggetti che ne fan parte, il \textit{SysV IPC}
 presenta numerosi problemi; in \cite{APUE}\footnote{in particolare nel
   capitolo 14.}  Stevens ne effettua una accurata analisi (alcuni dei concetti
@@ -2996,7 +3005,7 @@ alternative, che vogliamo riprendere in questa sezione.
 Le code di messaggi sono probabilmente il meno usato degli oggetti del
 \textit{SysV IPC}; esse infatti nacquero principalmente come meccanismo di
 comunicazione bidirezionale quando ancora le pipe erano unidirezionali; con la
-disponibilità di \func{socketpair} (vedi \secref{sec:ipc_socketpair}) o
+disponibilità di \func{socketpair} (vedi sez.~\ref{sec:ipc_socketpair}) o
 utilizzando una coppia di pipe, si può ottenere questo risultato senza
 incorrere nelle complicazioni introdotte dal \textit{SysV IPC}.
 
@@ -3013,7 +3022,7 @@ relativamente poco diffuso.
 \label{sec:ipc_file_lock}
 
 \index{file!di lock|(}
-Come illustrato in \secref{sec:ipc_sysv_sem} i semafori del \textit{SysV IPC}
+Come illustrato in sez.~\ref{sec:ipc_sysv_sem} i semafori del \textit{SysV IPC}
 presentano una interfaccia inutilmente complessa e con alcuni difetti
 strutturali, per questo quando si ha una semplice esigenza di sincronizzazione
 per la quale basterebbe un semaforo binario (quello che abbiamo definito come
@@ -3025,20 +3034,20 @@ La prima possibilit
 dei \textsl{file di lock} (per i quali esiste anche una opportuna directory,
 \file{/var/lock}, nel filesystem standard). Per questo si usa la
 caratteristica della funzione \func{open} (illustrata in
-\secref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
+sez.~\ref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
   standard POSIX.1, ciò non toglie che in alcune implementazioni questa
   tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si
-  è comunque soggetti alla possibilità di una race   
-  condition\index{race condition}.} che essa ritorni un errore quando usata
-con i flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la creazione di
-un \textsl{file di lock} può essere eseguita atomicamente, il processo che
-crea il file con successo si può considerare come titolare del lock (e della
+  è comunque soggetti alla possibilità di una \itindex{race~condition}
+  \textit{race condition}.} che essa ritorni un errore quando usata con i
+flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la creazione di un
+\textsl{file di lock} può essere eseguita atomicamente, il processo che crea
+il file con successo si può considerare come titolare del lock (e della
 risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata
 ad \func{unlink}.
 
 Un esempio dell'uso di questa funzione è mostrato dalle funzioni
-\func{LockFile} ed \func{UnlockFile} riportate in \figref{fig:ipc_file_lock}
-(sono contenute in \file{LockFile.c}, un'altro dei sorgenti allegati alla
+\func{LockFile} ed \func{UnlockFile} riportate in fig.~\ref{fig:ipc_file_lock}
+(sono contenute in \file{LockFile.c}, un altro dei sorgenti allegati alla
 guida) che permettono rispettivamente di creare e rimuovere un \textsl{file di
   lock}. Come si può notare entrambe le funzioni sono elementari; la prima
 (\texttt{\small 4--10}) si limita ad aprire il file di lock (\texttt{\small
@@ -3057,23 +3066,24 @@ cancella con \func{unlink}.
 \end{figure}
 
 Uno dei limiti di questa tecnica è che, come abbiamo già accennato in
-\secref{sec:file_open}, questo comportamento di \func{open} può non funzionare
-(la funzione viene eseguita, ma non è garantita l'atomicità dell'operazione)
-se il filesystem su cui si va ad operare è su NFS; in tal caso si può adottare
-una tecnica alternativa che prevede l'uso della \func{link} per creare come
-\textsl{file di lock} un hard link ad un file esistente; se il link esiste già
-e la funzione fallisce, significa che la risorsa è bloccata e potrà essere
-sbloccata solo con un \func{unlink}, altrimenti il link è creato ed il lock
-acquisito; il controllo e l'eventuale acquisizione sono atomici; la soluzione
-funziona anche su NFS, ma ha un'altro difetto è che è quello di poterla usare
-solo se si opera all'interno di uno stesso filesystem.
+sez.~\ref{sec:file_open}, questo comportamento di \func{open} può non
+funzionare (la funzione viene eseguita, ma non è garantita l'atomicità
+dell'operazione) se il filesystem su cui si va ad operare è su NFS; in tal
+caso si può adottare una tecnica alternativa che prevede l'uso della
+\func{link} per creare come \textsl{file di lock} un hard link ad un file
+esistente; se il link esiste già e la funzione fallisce, significa che la
+risorsa è bloccata e potrà essere sbloccata solo con un \func{unlink},
+altrimenti il link è creato ed il lock acquisito; il controllo e l'eventuale
+acquisizione sono atomici; la soluzione funziona anche su NFS, ma ha un altro
+difetto è che è quello di poterla usare solo se si opera all'interno di uno
+stesso filesystem.
 
 Un generale comunque l'uso di un \textsl{file di lock} presenta parecchi
 problemi, che non lo rendono una alternativa praticabile per la
 sincronizzazione: anzitutto in caso di terminazione imprevista del processo,
 si lascia allocata la risorsa (il \textsl{file di lock}) e questa deve essere
 sempre cancellata esplicitamente.  Inoltre il controllo della disponibilità
-può essere eseguito solo con una tecnica di \textit{polling}\index{polling},
+può essere eseguito solo con una tecnica di \textit{polling}\itindex{polling},
 ed è quindi molto inefficiente.
 
 La tecnica dei file di lock ha comunque una sua utilità, e può essere usata
@@ -3091,14 +3101,14 @@ disponibile.\index{file!di lock|)}
 Dato che i file di lock\index{file!di lock} presentano gli inconvenienti
 illustrati in precedenza, la tecnica alternativa di sincronizzazione più
 comune è quella di fare ricorso al \textit{file locking}\index{file!locking}
-(trattato in \secref{sec:file_locking}) usando \func{fcntl} su un file creato
-per l'occasione per ottenere un write lock. In questo modo potremo usare il
-lock come un \textit{mutex}: per bloccare la risorsa basterà acquisire il
-lock, per sbloccarla basterà rilasciare il lock. Una richiesta fatta con un
-write lock metterà automaticamente il processo in stato di attesa, senza
-necessità di ricorrere al \textit{polling}\index{polling} per determinare la
-disponibilità della risorsa, e al rilascio della stessa da parte del processo
-che la occupava si otterrà il nuovo lock atomicamente.
+(trattato in sez.~\ref{sec:file_locking}) usando \func{fcntl} su un file
+creato per l'occasione per ottenere un write lock. In questo modo potremo
+usare il lock come un \textit{mutex}: per bloccare la risorsa basterà
+acquisire il lock, per sbloccarla basterà rilasciare il lock. Una richiesta
+fatta con un write lock metterà automaticamente il processo in stato di
+attesa, senza necessità di ricorrere al \textit{polling}\itindex{polling} per
+determinare la disponibilità della risorsa, e al rilascio della stessa da
+parte del processo che la occupava si otterrà il nuovo lock atomicamente.
 
 Questo approccio presenta il notevole vantaggio che alla terminazione di un
 processo tutti i lock acquisiti vengono rilasciati automaticamente (alla
@@ -3114,30 +3124,31 @@ leggermente pi
   \end{minipage} 
   \normalsize 
   \caption{Il codice delle funzioni che permettono per la gestione dei 
-    \textit{mutex} con il file locking\index{file!locking}.}
+    \textit{mutex} con il \index{file!locking} \textit{file locking}.}
   \label{fig:ipc_flock_mutex}
 \end{figure}
 
 Il codice delle varie funzioni usate per implementare un mutex utilizzando il
-file locking\index{file!locking} è riportato in \figref{fig:ipc_flock_mutex};
-si è mantenuta volutamente una struttura analoga alle precedenti funzioni che
-usano i semafori, anche se le due interfacce non possono essere completamente
-equivalenti, specie per quanto riguarda la rimozione del mutex.
+\textit{file locking} \index{file!locking} è riportato in
+fig.~\ref{fig:ipc_flock_mutex}; si è mantenuta volutamente una struttura
+analoga alle precedenti funzioni che usano i semafori, anche se le due
+interfacce non possono essere completamente equivalenti, specie per quanto
+riguarda la rimozione del mutex.
 
 La prima funzione (\texttt{\small 1--5}) è \func{CreateMutex}, e serve a
 creare il mutex; la funzione è estremamente semplice, e si limita
 (\texttt{\small 4}) a creare, con una opportuna chiamata ad \func{open}, il
-file che sarà usato per il successivo file locking, assicurandosi che non
-esista già (nel qual caso segnala un errore); poi restituisce il file
+file che sarà usato per il successivo \textit{file locking}, assicurandosi che
+non esista già (nel qual caso segnala un errore); poi restituisce il file
 descriptor che sarà usato dalle altre funzioni per acquisire e rilasciare il
 mutex.
 
 La seconda funzione (\texttt{\small 6--10}) è \func{FindMutex}, che, come la
 precedente, è stata definita per mantenere una analogia con la corrispondente
 funzione basata sui semafori. Anch'essa si limita (\texttt{\small 9}) ad
-aprire il file da usare per il file locking, solo che in questo caso le
-opzioni di \func{open} sono tali che il file in questione deve esistere di
-già.
+aprire il file da usare per il \index{file!locking} \textit{file locking},
+solo che in questo caso le opzioni di \func{open} sono tali che il file in
+questione deve esistere di già.
 
 La terza funzione (\texttt{\small 11--22}) è \func{LockMutex} e serve per
 acquisire il mutex. La funzione definisce (\texttt{\small 14}) e inizializza
@@ -3146,15 +3157,16 @@ write lock sul file, che poi (\texttt{\small 21}) viene richiesto con
 \func{fcntl}, restituendo il valore di ritorno di quest'ultima. Se il file è
 libero il lock viene acquisito e la funzione ritorna immediatamente;
 altrimenti \func{fcntl} si bloccherà (si noti che la si è chiamata con
-\func{F\_SETLKW}) fino al rilascio del lock.
+\const{F\_SETLKW}) fino al rilascio del lock.
 
 La quarta funzione (\texttt{\small 24--34}) è \func{UnlockMutex} e serve a
 rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo
 caso si inizializza (\texttt{\small 28--31}) la struttura \var{lock} per il
 rilascio del lock, che viene effettuato (\texttt{\small 33}) con la opportuna
-chiamata a \func{fcntl}. Avendo usato il file locking in semantica POSIX (si
-riveda quanto detto \secref{sec:file_posix_lock}) solo il processo che ha
-precedentemente eseguito il lock può sbloccare il mutex.
+chiamata a \func{fcntl}. Avendo usato il \index{file!locking} \textit{file
+  locking} in semantica POSIX (si riveda quanto detto
+sez.~\ref{sec:file_posix_lock}) solo il processo che ha precedentemente
+eseguito il lock può sbloccare il mutex.
 
 La quinta funzione (\texttt{\small 36--39}) è \func{RemoveMutex} e serve a
 cancellare il mutex. Anche questa funzione è stata definita per mantenere una
@@ -3183,8 +3195,8 @@ successo, ad indicare che il mutex 
 
 Basandosi sulla semantica dei file lock POSIX valgono tutte le considerazioni
 relative al comportamento di questi ultimi fatte in
-\secref{sec:file_posix_lock}; questo significa ad esempio che, al contrario di
-quanto avveniva con l'interfaccia basata sui semafori, chiamate multiple a
+sez.~\ref{sec:file_posix_lock}; questo significa ad esempio che, al contrario
+di quanto avveniva con l'interfaccia basata sui semafori, chiamate multiple a
 \func{UnlockMutex} o \func{LockMutex} non si cumulano e non danno perciò
 nessun inconveniente.
 
@@ -3192,13 +3204,14 @@ nessun inconveniente.
 \subsection{Il \textit{memory mapping} anonimo}
 \label{sec:ipc_mmap_anonymous}
 
+\itindbeg{memory~mapping}
 Abbiamo già visto che quando i processi sono \textsl{correlati}\footnote{se
   cioè hanno almeno un progenitore comune.} l'uso delle pipe può costituire
 una valida alternativa alle code di messaggi; nella stessa situazione si può
 evitare l'uso di una memoria condivisa facendo ricorso al cosiddetto
 \textit{memory mapping} anonimo.
 
-In \secref{sec:file_memory_map} abbiamo visto come sia possibile mappare il
+In sez.~\ref{sec:file_memory_map} abbiamo visto come sia possibile mappare il
 contenuto di un file nella memoria di un processo, e che, quando viene usato
 il flag \const{MAP\_SHARED}, le modifiche effettuate al contenuto del file
 vengono viste da tutti i processi che lo hanno mappato. Utilizzare questa
@@ -3219,15 +3232,15 @@ il \textit{memory mapping} anonimo.\footnote{nei sistemi derivati da SysV una
   restano in memoria e possono essere riletti secondo le stesse modalità usate
   nel \textit{memory mapping} anonimo.} Vedremo come utilizzare questa tecnica
 più avanti, quando realizzeremo una nuova versione del monitor visto in
-\secref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
-
+sez.~\ref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
+\itindend{memory~mapping}
 
 
-\section{La comunicazione fra processi di POSIX}
+\section{Il sistema di comunicazione fra processi di POSIX}
 \label{sec:ipc_posix}
 
 Per superare i numerosi problemi del \textit{SysV IPC}, evidenziati per i suoi
-aspetti generali in coda a \secref{sec:ipc_sysv_generic} e per i singoli
+aspetti generali in coda a sez.~\ref{sec:ipc_sysv_generic} e per i singoli
 oggetti nei paragrafi successivi, lo standard POSIX.1b ha introdotto dei nuovi
 meccanismi di comunicazione, che vanno sotto il nome di POSIX IPC, definendo
 una interfaccia completamente nuova, che tratteremo in questa sezione.
@@ -3245,16 +3258,16 @@ tuttavia dei patch e una libreria aggiuntiva.
 
 La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
 degli identificatori e delle chiavi visti nel SysV IPC, per passare ai
-\textit{Posix IPC names}\index{Posix IPC names}, che sono sostanzialmente
+\textit{POSIX IPC names}\itindex{POSIX~IPC~names}, che sono sostanzialmente
 equivalenti ai nomi dei file. Tutte le funzioni che creano un oggetto di IPC
-Posix prendono come primo argomento una stringa che indica uno di questi nomi;
+POSIX prendono come primo argomento una stringa che indica uno di questi nomi;
 lo standard è molto generico riguardo l'implementazione, ed i nomi stessi
 possono avere o meno una corrispondenza sul filesystem; tutto quello che è
 richiesto è che:
 \begin{itemize}
 \item i nomi devono essere conformi alle regole che caratterizzano i
-  \textit{pathname}, in particolare non essere più lunghi di \const{PATH\_MAX}
-  byte e terminati da un carattere nullo.
+  \itindex{pathname}\textit{pathname}, in particolare non essere più lunghi di
+  \const{PATH\_MAX} byte e terminati da un carattere nullo.
 \item se il nome inizia per una \texttt{/} chiamate differenti allo stesso
   nome fanno riferimento allo stesso oggetto, altrimenti l'interpretazione del
   nome dipende dall'implementazione.
@@ -3270,10 +3283,10 @@ implementazione.\footnote{tanto che Stevens in \cite{UNP2} cita questo caso
 quanto riguarda la memoria condivisa, che per quanto riguarda le code di
 messaggi, tutto viene creato usando come radici delle opportune directory
 (rispettivamente \file{/dev/shm} e \file{/dev/mqueue}, per i dettagli si
-faccia riferimento a \secref{sec:ipc_posix_shm} e \secref{sec:ipc_posix_mq})
-ed i nomi specificati nelle relative funzioni sono considerati come un
-pathname assoluto (comprendente eventuali sottodirectory) rispetto a queste
-radici. 
+faccia riferimento a sez.~\ref{sec:ipc_posix_shm} e
+sez.~\ref{sec:ipc_posix_mq}) ed i nomi specificati nelle relative funzioni
+sono considerati come un \itindsub{pathname}{assoluto}\textit{pathname}
+assoluto (comprendente eventuali sottodirectory) rispetto a queste radici.
 
 Il vantaggio degli oggetti di IPC POSIX è comunque che essi vengono inseriti
 nell'albero dei file, e possono essere maneggiati con le usuali funzioni e
@@ -3287,9 +3300,9 @@ file normali.
 
 In particolare i permessi associati agli oggetti di IPC POSIX sono identici ai
 permessi dei file, e il controllo di accesso segue esattamente la stessa
-semantica (quella illustrata in \secref{sec:file_access_control}), invece di
+semantica (quella illustrata in sez.~\ref{sec:file_access_control}), invece di
 quella particolare (si ricordi quanto visto in
-\secref{sec:ipc_sysv_access_control}) usata per gli oggetti del SysV IPC. Per
+sez.~\ref{sec:ipc_sysv_access_control}) usata per gli oggetti del SysV IPC. Per
 quanto riguarda l'attribuzione dell'utente e del gruppo proprietari
 dell'oggetto alla creazione di quest'ultimo essa viene effettuata secondo la
 semantica SysV (essi corrispondono cioè a userid e groupid effettivi del
@@ -3303,9 +3316,9 @@ processo che esegue la creazione).
 Le code di messaggi non sono ancora supportate nel kernel ufficiale, esiste
 però una implementazione sperimentale di Michal Wronski e Krzysztof
 Benedyczak,\footnote{i patch al kernel e la relativa libreria possono essere
-  trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc}
-  {http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}, questi sono stati
-  inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}.  In
+trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc}
+{\textsf{http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}}, questi sono
+stati inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}.  In
 generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
 usate, dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono
 più comodi, e che in casi più complessi la comunicazione può essere gestita
@@ -3354,7 +3367,7 @@ di messaggi POSIX 
     di successo e -1 in caso di errore; nel quel caso \var{errno} assumerà i
     valori:
     \begin{errlist}
-    \item[\errcode{EACCESS}] Il processo non ha i privilegi per accedere al
+    \item[\errcode{EACCES}] Il processo non ha i privilegi per accedere al
       alla memoria secondo quanto specificato da \param{oflag}.
     \item[\errcode{EEXIST}] Si è specificato \const{O\_CREAT} e
       \const{O\_EXCL} ma la coda già esiste.
@@ -3379,7 +3392,7 @@ stesso oggetto, consentendo cos
 La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
 possono essere specificati per \param{oflag}, che deve essere specificato come
 maschera binaria; i valori possibili per i vari bit sono quelli visti in
-\tabref{tab:file_open_flags} dei quali però \func{mq\_open} riconosce solo i
+tab.~\ref{tab:file_open_flags} dei quali però \func{mq\_open} riconosce solo i
 seguenti:
 \begin{basedescript}{\desclabelwidth{2cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{O\_RDONLY}] Apre la coda solo per la ricezione di messaggi. Il
@@ -3415,7 +3428,7 @@ solo i permessi di lettura e scrittura. Oltre ai permessi di creazione possono
 essere specificati anche gli attributi specifici della coda tramite
 l'argomento \param{attr}; quest'ultimo è un puntatore ad una apposita
 struttura \struct{mq\_attr}, la cui definizione è riportata in
-\figref{fig:ipc_mq_attr}.
+fig.~\ref{fig:ipc_mq_attr}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -3474,7 +3487,7 @@ Rimuove una coda di messaggi.
 
 Anche in questo caso il comportamento della funzione è analogo a quello di
 \func{unlink} per i file,\footnote{di nuovo l'implementazione di Linux usa
-  direttamente \func{unlink}.} la funzione rimove la coda \param{name}, così
+  direttamente \func{unlink}.} la funzione rimuove la coda \param{name}, così
 che una successiva chiamata a \func{mq\_open} fallisce o crea una coda
 diversa. 
 
@@ -3636,6 +3649,9 @@ differenza di quanto avveniva con le code di messaggi di SysV che permettono
 invece la selezione in base al valore del campo \var{mtype}. Qualora non
 interessi usare la priorità dei messaggi si
 
+% TODO vericare questa interruzione di paragrafo 
+% TODO inserire i dati di /proc/sys/fs/mqueue 
+
 Qualora la coda sia vuota entrambe le funzioni si bloccano, a meno che non si
 sia selezionata la modalità non bloccante; in tal caso entrambe ritornano
 immediatamente con l'errore \errcode{EAGAIN}. Anche in questo caso la sola
@@ -3677,9 +3693,9 @@ processo alla volta per ciascuna coda.
 
 Il comportamento di \func{mq\_notify} dipende dal valore dell'argomento
 \param{notification}, che è un puntatore ad una apposita struttura
-\struct{sigevent}, (definita in \figref{fig:file_sigevent}) introdotta dallo
+\struct{sigevent}, (definita in fig.~\ref{fig:file_sigevent}) introdotta dallo
 standard POSIX.1b per gestire la notifica di eventi; per altri dettagli si può
-vedere quanto detto in \secref{sec:file_asyncronous_io} a proposito dell'uso
+vedere quanto detto in sez.~\ref{sec:file_asyncronous_io} a proposito dell'uso
 della stessa struttura per l'invio dei segnali usati per l'I/O asincrono.
 
 Attraverso questa struttura si possono impostare le modalità con cui viene
@@ -3689,11 +3705,11 @@ essere posto a \const{SIGEV\_SIGNAL}\footnote{il meccanismo di notifica basato
   implementato.} ed il campo \var{sigev\_signo} deve indicare il valore del
 segnale che sarà inviato al processo. Inoltre il campo \var{sigev\_value} è il
 puntatore ad una struttura \struct{sigval\_t} (definita in
-\figref{fig:sig_sigval}) che permette di restituire al gestore del segnale un
+fig.~\ref{fig:sig_sigval}) che permette di restituire al gestore del segnale un
 valore numerico o un indirizzo,\footnote{per il suo uso si riveda la
-  trattazione fatta in \secref{sec:sig_real_time} a proposito dei segnali
+  trattazione fatta in sez.~\ref{sec:sig_real_time} a proposito dei segnali
   real-time.} posto che questo sia installato nella forma estesa vista in
-\secref{sec:sig_sigaction}.
+sez.~\ref{sec:sig_sigaction}.
 
 La funzione registra il processo chiamante per la notifica se
 \param{notification} punta ad una struttura \struct{sigevent} opportunamente
@@ -3727,14 +3743,14 @@ estrarre i messaggi presenti dalla coda.
 
 L'invio del segnale di notifica avvalora alcuni campi di informazione
 restituiti al gestore attraverso la struttura \struct{siginfo\_t} (definita in
-\figref{fig:sig_siginfo_t}). In particolare \var{si\_pid} viene impostato al
+fig.~\ref{fig:sig_siginfo_t}). In particolare \var{si\_pid} viene impostato al
 valore del \acr{pid} del processo che ha emesso il segnale, \var{si\_uid}
 all'userid effettivo, \var{si\_code} a \const{SI\_MESGQ}, e \var{si\_errno} a
 0. Questo ci dice che, se si effettua la ricezione dei messaggi usando
 esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni
 sul processo che ha inserito un messaggio usando un gestore per il segnale in
 forma estesa\footnote{di nuovo si faccia riferimento a quanto detto al
-  proposito in \secref{sec:sig_sigaction} e \secref{sec:sig_real_time}.}
+  proposito in sez.~\ref{sec:sig_sigaction} e sez.~\ref{sec:sig_real_time}.}
 
 
 
@@ -3749,18 +3765,19 @@ implementa solo a livello di thread e non di processi.\footnote{questo
   sincronizzazione fra processi diversi.} Esiste però anche una libreria
 realizzata da Konstantin Knizhnik, che reimplementa l'interfaccia POSIX usando
 i semafori di SysV IPC, e che non vale comunque la pena di usare visto che i
-problemi sottolineati in \secref{sec:ipc_sysv_sem} rimangono, anche se
+problemi sottolineati in sez.~\ref{sec:ipc_sysv_sem} rimangono, anche se
 mascherati.
 
 In realtà a partire dal kernel 2.5.7 è stato introdotto un meccanismo di
 sincronizzazione completamente nuovo, basato sui cosiddetti
-\textit{futex}\footnote{la sigla sta per \textit{faxt user mode mutex}.}, con
+\textit{futex}\footnote{la sigla sta per \textit{fast user mode mutex}.}, con
 il quale dovrebbe essere possibile implementare una versione nativa dei
 semafori; esso è già stato usato con successo per reimplementare in maniera
 più efficiente tutte le direttive di sincronizzazione previste per i thread
 POSIX. L'interfaccia corrente è stata stabilizzata a partire dal kernel
 2.5.40.
 
+% TODO vedere se ci sono novità e trattare la cosa.
 
 
 
@@ -3776,7 +3793,7 @@ tutti i suoi contenuti in memoria,\footnote{il filesystem \texttt{tmpfs} 
   utilizzabile anche per la memoria condivisa; esso infatti non ha dimensione
   fissa, ed usa direttamente la cache interna del kernel (che viene usata
   anche per la shared memory in stile SysV). In più i suoi contenuti, essendo
-  trattati direttamente dalla memoria virtuale\index{memoria virtuale} possono
+  trattati direttamente dalla memoria virtuale\index{memoria~virtuale} possono
   essere salvati sullo swap automaticamente.} che viene attivato abilitando
 l'opzione \texttt{CONFIG\_TMPFS} in fase di compilazione del kernel.
 
@@ -3815,20 +3832,20 @@ Apre un segmento di memoria condivisa.
 \end{prototype}
 
 La funzione apre un segmento di memoria condivisa identificato dal nome
-\param{name}. Come già spiegato in \secref{sec:ipc_posix_generic} questo nome
+\param{name}. Come già spiegato in sez.~\ref{sec:ipc_posix_generic} questo nome
 può essere specificato in forma standard solo facendolo iniziare per \file{/}
 e senza ulteriori \file{/}, Linux supporta comunque nomi generici, che
-verranno intepretati prendendo come radice \file{/dev/shm}.\footnote{occorre
+verranno interpretati prendendo come radice \file{/dev/shm}.\footnote{occorre
   pertanto evitare di specificare qualcosa del tipo \file{/dev/shm/nome}
-  all'interno di \param{name}, perché questo comporta, da parte delle routine
-  di libereria, il tentativo di accedere a \file{/dev/shm/dev/shm/nome}.}
+  all'interno di \param{name}, perché questo comporta, da parte delle funzioni
+  di libreria, il tentativo di accedere a \file{/dev/shm/dev/shm/nome}.}
 
 La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
 possono essere specificati per \param{oflag}, che deve essere specificato come
 maschera binaria comprendente almeno uno dei due valori \const{O\_RDONLY} e
 \const{O\_RDWR}; i valori possibili per i vari bit sono quelli visti in
-\tabref{tab:file_open_flags} dei quali però \func{shm\_open} riconosce solo i
-seguenti:
+tab.~\ref{tab:file_open_flags} dei quali però \func{shm\_open} riconosce solo
+i seguenti:
 \begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{O\_RDONLY}] Apre il file descriptor associato al segmento di
   memoria condivisa per l'accesso in sola lettura.
@@ -3849,20 +3866,20 @@ In caso di successo la funzione restituisce un file descriptor associato al
 segmento di memoria condiviso con le stesse modalità di
 \func{open}\footnote{in realtà, come accennato, \func{shm\_open} è un semplice
   wrapper per \func{open}, usare direttamente quest'ultima avrebbe lo stesso
-  effetto.}  viste in \secref{sec:file_open}; in particolare viene impostato
+  effetto.}  viste in sez.~\ref{sec:file_open}; in particolare viene impostato
 il flag \const{FD\_CLOEXEC}.  Chiamate effettuate da diversi processi usando
 lo stesso nome, restituiranno file descriptor associati allo stesso segmento
-(così come, nel caso di file di dati, essi sono associati allo stesso inode).
-In questo modo è possibile effettuare una chiamata ad \func{mmap} sul file
-descriptor restituito da \func{shm\_open} ed i processi vedranno lo stesso
-segmento di memoria condivisa.
+(così come, nel caso di file di dati, essi sono associati allo stesso
+\index{inode}inode).  In questo modo è possibile effettuare una chiamata ad
+\func{mmap} sul file descriptor restituito da \func{shm\_open} ed i processi
+vedranno lo stesso segmento di memoria condivisa.
 
 Quando il nome non esiste il segmento può essere creato specificando
 \const{O\_CREAT}; in tal caso il segmento avrà (così come i nuovi file)
 lunghezza nulla. Dato che un segmento di lunghezza nulla è di scarsa utilità,
 per impostarne la dimensione si deve usare \func{ftruncate} (vedi
-\secref{sec:file_file_size}), prima di mapparlo in memoria con \func{mmap}. Si
-tenga presente che una volta chiamata \func{mmap} si può chiudere il file
+sez.~\ref{sec:file_file_size}), prima di mapparlo in memoria con \func{mmap}.
+Si tenga presente che una volta chiamata \func{mmap} si può chiudere il file
 descriptor (con \func{close}), senza che la mappatura ne risenta.
 
 
@@ -3901,8 +3918,8 @@ descriptor che fa riferimento ad un segmento distinto da eventuali precedenti.
 
 Come esempio per l'uso di queste funzioni vediamo come è possibile riscrivere
 una interfaccia semplificata analoga a quella vista in
-\secref{fig:ipc_sysv_shm_func} per la memoria condivisa in stile SysV. Il
-codice, riportato in \figref{fig:ipc_posix_shmmem}, è sempre contenuto nel
+fig.~\ref{fig:ipc_sysv_shm_func} per la memoria condivisa in stile SysV. Il
+codice, riportato in fig.~\ref{fig:ipc_posix_shmmem}, è sempre contenuto nel
 file \file{SharedMem.c} dei sorgenti allegati.
 
 La prima funzione (\texttt{\small 1--24}) è \func{CreateShm} che, dato un nome
@@ -3938,7 +3955,7 @@ cancellare un segmento di memoria condivisa. Dato che al contrario di quanto
 avveniva con i segmenti del SysV IPC gli oggetti allocati nel kernel vengono
 rilasciati automaticamente quando nessuna li usa più, tutto quello che c'è da
 fare (\texttt{\small 44}) in questo caso è chiamare \func{shm\_unlink},
-retituendo al chiamante il valore di ritorno.
+restituendo al chiamante il valore di ritorno.
 
 
 
@@ -3946,3 +3963,53 @@ retituendo al chiamante il valore di ritorno.
 %%% mode: latex
 %%% TeX-master: "gapil"
 %%% End: 
+
+% LocalWords:  like fifo System POSIX RPC Calls Common Object Request Brocker
+% LocalWords:  Architecture descriptor kernel unistd int filedes errno EMFILE
+% LocalWords:  ENFILE EFAULT BUF sez fig fork Stevens siblings EOF read SIGPIPE
+% LocalWords:  EPIPE shell CGI Gateway Interface HTML JPEG URL mime type gs dup
+% LocalWords:  barcode PostScript race condition stream BarCodePage WriteMess
+% LocalWords:  size PS switch wait popen pclose stdio const char command NULL
+% LocalWords:  EINVAL cap fully buffered Ghostscript l'Encapsulated epstopsf of
+% LocalWords:  PDF EPS lseek ESPIPE PPM Portable PixMap format pnmcrop PNG pnm
+% LocalWords:  pnmmargin png BarCode inode filesystem l'inode mknod mkfifo RDWR
+% LocalWords:  ENXIO deadlock client reinviate fortunes fortunefilename daemon
+% LocalWords:  FortuneServer FortuneParse FortuneClient pid libgapil LD LIBR<ARY
+% LocalWords:  PATH linker pathname ps tmp killall fortuned crash socket domain
+% LocalWords:  socketpair BSD sys protocol sv EAFNOSUPPORT EPROTONOSUPPORT AF
+% LocalWords:  EOPNOTSUPP SOCK SysV IPC Process Comunication ipc perm key exec
+% LocalWords:  header ftok proj stat libc SunOS glibc XPG dell'inode number uid
+% LocalWords:  cuid cgid gid tab MSG shift group umask seq MSGMNI SEMMNI SHMMNI
+% LocalWords:  shmmni msgmni sem sysctl IPCMNI IPCTestId msgget EACCES EEXIST
+% LocalWords:  CREAT EXCL EIDRM ENOENT ENOSPC ENOMEM novo proc MSGMAX msgmax ds
+% LocalWords:  MSGMNB msgmnb linked list msqid msgid linux msg qnum lspid lrpid
+% LocalWords:  rtime ctime qbytes first last cbytes msgctl semctl shmctl ioctl
+% LocalWords:  cmd struct buf EPERM RMID msgsnd msgbuf msgp msgsz msgflg EAGAIN
+% LocalWords:  NOWAIT EINTR mtype mtext long message sizeof LENGTH ts sleep BIG
+% LocalWords:  msgrcv ssize msgtyp NOERROR EXCEPT ENOMSG multiplexing select ls
+% LocalWords:  poll polling queue MQFortuneServer write init HandSIGTERM 
+% LocalWords:  MQFortuneClient mqfortuned mutex risorse' inter semaphore semget
+% LocalWords:  nsems SEMMNS SEMMSL semid otime semval sempid semncnt semzcnt nr
+% LocalWords:  SEMVMX SEMOPM semop SEMMNU SEMUME SEMAEM semnum union semun arg
+% LocalWords:  ERANGE SETALL SETVAL GETALL array GETNCNT GETPID GETVAL GETZCNT
+% LocalWords:  sembuf sops unsigned nsops UNDO flg nsop num undo pending semadj
+% LocalWords:  sleeper scheduler running next semundo MutexCreate semunion lock
+% LocalWords:  MutexFind wrapper MutexRead MutexLock MutexUnlock unlock locking
+% LocalWords:  MutexRemove shmget SHMALL SHMMAX SHMMIN shmid shm segsz atime FD
+% LocalWords:  dtime lpid cpid nattac shmall shmmax SHMLBA SHMSEG EOVERFLOW brk
+% LocalWords:  memory shmat shmdt void shmaddr shmflg SVID RND RDONLY rounded
+% LocalWords:  SIGSEGV nattch exit SharedMem ShmCreate memset fill ShmFind home
+% LocalWords:  ShmRemove DirMonitor DirProp chdir GaPiL shmptr DirScan ipcs NFS
+% LocalWords:  ComputeValues ReadMonitor touch SIGTERM dirmonitor unlink fcntl
+% LocalWords:  LockFile UnlockFile CreateMutex FindMutex LockMutex SETLKW GETLK
+% LocalWords:  UnlockMutex RemoveMutex ReadMutex UNLCK WRLCK RDLCK mapping MAP
+% LocalWords:  SHARED ANONYMOUS thread patch names strace system call userid Di
+% LocalWords:  groupid Michal Wronski Krzysztof Benedyczak wrona posix mqueue
+% LocalWords:  lmqueue gcc mount mqd name oflag attr maxmsg msgsize receive ptr
+% LocalWords:  send WRONLY NONBLOCK close mqdes EBADF getattr setattr mqstat
+% LocalWords:  omqstat curmsgs flags timedsend len prio timespec abs EMSGSIZE
+% LocalWords:  ETIMEDOUT timedreceive getaddr notify sigevent notification l'I
+% LocalWords:  EBUSY sigev SIGNAL signo value sigval siginfo all'userid MESGQ
+% LocalWords:  Konstantin Knizhnik futex tmpfs ramfs cache shared swap CONFIG
+% LocalWords:  lrt blocks PAGECACHE TRUNC CLOEXEC mmap ftruncate munmap FindShm
+% LocalWords:  CreateShm RemoveShm