X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=f3a2ec75f9ad64d8adc21a1c330fdc08d5fdcf2a;hp=25f0f301bedd7480c59dbddf8faed23d3885171a;hb=dcf2c2df897955ff3503a7c426025457ab456fd7;hpb=96d16340f5828ce9dbdd023a15978274909deb89

diff --git a/ipc.tex b/ipc.tex
index 25f0f30..f3a2ec7 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -1,6 +1,6 @@
 %% ipc.tex
 %%
-%% Copyright (C) 2000-2011 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2012 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 "Un preambolo",
@@ -74,7 +74,7 @@ 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.
 
-\begin{figure}[htb]
+\begin{figure}[!htb]
   \centering
   \includegraphics[height=5cm]{img/pipe}
   \caption{Schema della struttura di una pipe.}
@@ -90,7 +90,7 @@ compresi quelli associati ad una pipe (secondo la situazione illustrata in
 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]
+\begin{figure}[!htb]
   \centering
   \includegraphics[height=5cm]{img/pipefork}
   \caption{Schema dei collegamenti ad una pipe, condivisi fra processo padre e
@@ -114,7 +114,7 @@ essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
 pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
 (vale a dire che la funzione \func{read} ritornerà restituendo 0).  Se invece
 si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
-processo riceverà il segnale \const{SIGPIPE}, e la funzione di scrittura
+processo riceverà il segnale \signal{SIGPIPE}, e la funzione di scrittura
 restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
 segnale sia ignorato o bloccato).
 
@@ -159,7 +159,7 @@ JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
 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]
+\begin{figure}[!htb]
   \centering
   \includegraphics[height=5cm]{img/pipeuse}
   \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
@@ -190,9 +190,9 @@ 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]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/BarCodePage.c}
   \end{minipage} 
   \normalsize 
@@ -375,9 +375,9 @@ per primo, si bloccherà in attesa di ricevere sullo standard input il
 risultato dell'elaborazione del precedente, benché quest'ultimo venga invocato
 dopo.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/BarCode.c}
   \end{minipage} 
   \normalsize 
@@ -418,13 +418,13 @@ 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 \index{inode} inode che risiede sul filesystem, così che i
+attraverso un \itindex{inode} inode che risiede sul filesystem, così che i
 processi le possono usare senza dovere per forza essere in una relazione di
 \textsl{parentela}.
 
 Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
 attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
-\index{inode} l'inode allocato sul filesystem serve infatti solo a fornire un
+\itindex{inode} l'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 sez.~\ref{sec:ipc_pipes}.
@@ -496,7 +496,7 @@ 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.
 
-\begin{figure}[htb]
+\begin{figure}[!htb]
   \centering
   \includegraphics[height=9cm]{img/fifoserver}
   \caption{Schema dell'utilizzo delle fifo nella realizzazione di una
@@ -516,9 +516,9 @@ ed \var{n}, che indica il numero di frasi tenute in memoria, ad un valore
 diverso da quelli preimpostati. Il codice completo è nel file
 \file{FortuneServer.c}.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/FortuneServer.c}
   \end{minipage} 
   \normalsize 
@@ -607,9 +607,9 @@ 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.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/FortuneClient.c}
   \end{minipage} 
   \normalsize 
@@ -619,7 +619,7 @@ principale del programma e le definizioni delle variabili. Il codice completo
 \end{figure}
 
 La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà
-essere utilizzata per ricevere la risposta dal server.  Si usa il \acr{pid}
+essere utilizzata per ricevere la risposta dal server.  Si usa il \ids{PID}
 del processo per essere sicuri di avere un nome univoco; dopo di che
 (\texttt{\small 13-18}) si procede alla creazione del relativo file, uscendo
 in caso di errore (a meno che il file non sia già presente sul filesystem).
@@ -646,15 +646,15 @@ scrittura e l'apertura si sarebbe bloccata indefinitamente.
 Verifichiamo allora il comportamento dei nostri programmi, in questo, come in
 altri esempi precedenti, si fa uso delle varie funzioni di servizio, che sono
 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 \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:
+occorrerà definire la variabile di ambiente \envvar{LD\_LIBRARY\_PATH} in modo
+che il linker dinamico possa accedervi.
+
+In generale questa variabile indica il \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}
@@ -707,7 +707,7 @@ complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
   che esamina questa architettura in \cite{APUE}, nota come sia impossibile
   per il server sapere se un client è andato in crash, con la possibilità di
   far restare le fifo temporanee sul filesystem, di come sia necessario
-  intercettare \const{SIGPIPE} dato che un client può terminare dopo aver
+  intercettare \signal{SIGPIPE} dato che un client può terminare dopo aver
   fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel
   nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
 fifo non è adatta a risolvere questo tipo di problemi, che possono essere
@@ -817,7 +817,7 @@ utilizzando, con tutte le conseguenze (negative) del caso.
 Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV
   IPC} vengono creati direttamente dal kernel, e sono accessibili solo
 specificando il relativo \textsl{identificatore}. Questo è un numero
-progressivo (un po' come il \acr{pid} dei processi) che il kernel assegna a
+progressivo (un po' come il \ids{PID} dei processi) che il kernel assegna a
 ciascuno di essi quanto vengono creati (sul procedimento di assegnazione
 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
@@ -839,12 +839,12 @@ mantiene varie proprietà ed informazioni associate all'oggetto.
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/ipc_perm.h}
   \end{minipage} 
   \normalsize 
   \caption{La struttura \structd{ipc\_perm}, come definita in
-    \file{sys/ipc.h}.}
+    \headfile{sys/ipc.h}.}
   \label{fig:ipc_ipc_perm}
 \end{figure}
 
@@ -882,17 +882,17 @@ 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 \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.}
+che deve specificare il \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}, la \acr{glibc}
+  usa 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)}
-con i 16 bit meno significativi \index{inode} dell'inode del file
+con i 16 bit meno significativi \itindex{inode} dell'inode del file
 \param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano
 i possibili errori), e gli 8 bit meno significativi del numero del dispositivo
 su cui è il file.  Diventa perciò relativamente facile ottenere delle
@@ -937,7 +937,7 @@ 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
 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},
+  simboliche ivi definite occorrerà includere il file \headfile{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
   scrittura per il proprietario, da utilizzare, con gli opportuni shift, pure
@@ -947,7 +947,7 @@ 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 impostati
-rispettivamente al valore dell'user-ID e del group-ID effettivo del processo
+rispettivamente al valore dell'\ids{UID} e del \ids{GID} 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.
 
@@ -967,12 +967,12 @@ controlli è simile a quello dei file, ed avviene secondo questa sequenza:
 \begin{itemize*}
 \item se il processo ha i privilegi di amministratore l'accesso è sempre
   consentito. 
-\item se l'user-ID effettivo del processo corrisponde o al valore del campo
+\item se l'\ids{UID} 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 è
     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
+\item se il \ids{GID} effettivo del processo corrisponde o al
   valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
   per il gruppo in \var{mode} è appropriato l'accesso è consentito.
 \item se il permesso per gli altri è appropriato l'accesso è consentito.
@@ -1021,8 +1021,8 @@ Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino
   altri limiti relativi al \textit{SysV IPC}) solo con una ricompilazione del
   kernel, andando a modificarne la definizione nei relativi header file.  A
   partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
-  scrivendo sui file \procrelfile{/proc/sys/kernel}{shmmni},
-  \procrelfile{/proc/sys/kernel}{msgmni} e \procrelfile{/proc/sys/kernel}{sem}
+  scrivendo sui file \sysctlrelfile{kernel}{shmmni},
+  \sysctlrelfile{kernel}{msgmni} e \sysctlrelfile{kernel}{sem}
   di \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.} e per ciascuno di
 essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
 incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
@@ -1036,9 +1036,9 @@ di quel tipo,\footnote{questo vale fino ai kernel della serie 2.2.x, dalla
   valore è 32768.}  si evita così il riutilizzo degli stessi numeri, e si fa
 sì che l'identificatore assuma tutti i valori possibili.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/IPCTestId.c}
   \end{minipage} 
   \normalsize 
@@ -1182,11 +1182,11 @@ Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti
 negli header e corrispondenti alle prime tre costanti riportate in
 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 \procrelfile{/proc/sys/kernel}{msgmax},
-\procrelfile{/proc/sys/kernel}{msgmnb} e
-\procrelfile{/proc/sys/kernel}{msgmni} di \file{/proc/sys/kernel/}.
+file \sysctlrelfile{kernel}{msgmax},
+\sysctlrelfile{kernel}{msgmnb} e
+\sysctlrelfile{kernel}{msgmni} di \file{/proc/sys/kernel/}.
 
-\begin{figure}[htb]
+\begin{figure}[!htb]
   \centering \includegraphics[width=13cm]{img/mqstruct}
   \caption{Schema della struttura di una coda messaggi.}
   \label{fig:ipc_mq_schema}
@@ -1213,7 +1213,7 @@ cui queste strutture vengono mantenute dal kernel.\footnote{lo schema
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/msqid_ds.h}
   \end{minipage} 
   \normalsize 
@@ -1223,18 +1223,18 @@ cui queste strutture vengono mantenute dal kernel.\footnote{lo schema
 \end{figure}
 
 A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
-definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura il
-kernel mantiene le principali informazioni riguardo lo stato corrente della
+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
   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 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.
+  \file{include/linux/msg.h}, e fanno riferimento alla definizione della
+  omonima struttura usata nel kernel.} In fig.~\ref{fig:ipc_msqid_ds} sono
+elencati i campi significativi definiti in \headfile{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
@@ -1244,7 +1244,7 @@ gli altri campi invece:
 \item il campo \var{msg\_qnum}, che esprime il numero di messaggi presenti
   sulla coda, viene inizializzato a 0.
 \item i campi \var{msg\_lspid} e \var{msg\_lrpid}, che esprimono
-  rispettivamente il \acr{pid} dell'ultimo processo che ha inviato o ricevuto
+  rispettivamente il \ids{PID} dell'ultimo processo che ha inviato o ricevuto
   un messaggio sulla coda, sono inizializzati a 0.
 \item i campi \var{msg\_stime} e \var{msg\_rtime}, che esprimono
   rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo
@@ -1303,7 +1303,7 @@ eseguire; i valori possibili sono:
   riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
   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
+  con \ids{UID} effettivo corrispondente al creatore o al proprietario della
   coda, o all'amministratore.
 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
   della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in
@@ -1353,12 +1353,12 @@ messaggio.  La dimensione massima per il testo di un messaggio non può
 comunque superare il limite \const{MSGMAX}.
 
 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
-\var{mtype} come nell'esempio; esso infatti serve ad identificare il tipo di
-messaggio e deve essere sempre specificato come intero positivo di tipo
-\ctyp{long}.  Il campo \var{mtext} invece può essere di qualsiasi tipo e
+la definizione contenuta in \headfile{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 \var{mtype} come nell'esempio; esso infatti serve ad identificare il
+tipo di messaggio e deve essere sempre specificato come intero positivo di
+tipo \ctyp{long}.  Il campo \var{mtext} invece può essere di qualsiasi tipo e
 dimensione, e serve a contenere il testo del messaggio.
 
 In generale pertanto per inviare un messaggio con \func{msgsnd} si usa
@@ -1377,7 +1377,7 @@ dovrà essere pari a \const{LENGTH}).
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/msgbuf.h}
   \end{minipage} 
   \normalsize 
@@ -1416,7 +1416,7 @@ Una volta completato con successo l'invio del messaggio sulla coda, la
 funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
 vengono modificati:
 \begin{itemize*}
-\item Il valore di \var{msg\_lspid}, che viene impostato al \acr{pid} del
+\item Il valore di \var{msg\_lspid}, che viene impostato al \ids{PID} del
   processo chiamante.
 \item Il valore di \var{msg\_qnum}, che viene incrementato di uno.
 \item Il valore \var{msg\_stime}, che viene impostato al tempo corrente.
@@ -1502,7 +1502,7 @@ Una volta completata con successo l'estrazione del messaggio dalla coda, la
 funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare
 vengono modificati:
 \begin{itemize*}
-\item Il valore di \var{msg\_lrpid}, che viene impostato al \acr{pid} del
+\item Il valore di \var{msg\_lrpid}, che viene impostato al \ids{PID} del
   processo chiamante.
 \item Il valore di \var{msg\_qnum}, che viene decrementato di uno.
 \item Il valore \var{msg\_rtime}, che viene impostato al tempo corrente.
@@ -1531,9 +1531,9 @@ server di \textit{fortunes} usando queste al posto delle fifo. In questo caso
 useremo una sola coda di messaggi, usando il tipo di messaggio per comunicare
 in maniera indipendente con client diversi.
 
-\begin{figure}[!bht]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/MQFortuneServer.c}
   \end{minipage} 
   \normalsize 
@@ -1547,7 +1547,7 @@ 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
 per permettere una comunicazione indipendente fra il server ed i vari client,
-usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile
+usando il \ids{PID} di questi ultimi come identificativo. Questo è possibile
 in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
 non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla
 base del loro tipo.
@@ -1581,9 +1581,9 @@ il ciclo principale (\texttt{\small 33--40}). Questo inizia (\texttt{\small
   34}) con il porsi in attesa di un messaggio di richiesta da parte di un
 client; si noti infatti come \func{msgrcv} richieda un messaggio con
 \var{mtype} uguale a 1: questo è il valore usato per le richieste dato che
-corrisponde al \acr{pid} di \cmd{init}, che non può essere un client. L'uso
+corrisponde al \ids{PID} di \cmd{init}, che non può essere un client. L'uso
 del flag \const{MSG\_NOERROR} è solo per sicurezza, dato che i messaggi di
-richiesta sono di dimensione fissa (e contengono solo il \acr{pid} del
+richiesta sono di dimensione fissa (e contengono solo il \ids{PID} del
 client).
 
 Se non sono presenti messaggi di richiesta \func{msgrcv} si bloccherà,
@@ -1595,7 +1595,7 @@ calcolandone (\texttt{\small 37}) la dimensione.
 
 Per poter permettere a ciascun client di ricevere solo la risposta indirizzata
 a lui il tipo del messaggio in uscita viene inizializzato (\texttt{\small 38})
-al valore del \acr{pid} del client ricevuto nel messaggio di richiesta.
+al valore del \ids{PID} del client ricevuto nel messaggio di richiesta.
 L'ultimo passo del ciclo (\texttt{\small 39}) è inviare sulla coda il
 messaggio di risposta. Si tenga conto che se la coda è piena anche questa
 funzione potrà bloccarsi fintanto che non venga liberato dello spazio.
@@ -1605,9 +1605,9 @@ parte di un segnale; in tal caso verrà eseguito (\texttt{\small 45--48}) il
 gestore \code{HandSIGTERM}, che semplicemente si limita a cancellare la coda
 (\texttt{\small 46}) ed ad uscire (\texttt{\small 47}).
 
-\begin{figure}[!bht]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/MQFortuneClient.c}
   \end{minipage} 
   \normalsize 
@@ -1633,13 +1633,13 @@ il programma termina immediatamente.
 
 Una volta acquisito l'identificatore della coda il client compone il
 messaggio di richiesta (\texttt{\small 12--13}) in \var{msg\_read}, usando 1
-per il tipo ed inserendo il proprio \acr{pid} come dato da passare al server.
+per il tipo ed inserendo il proprio \ids{PID} come dato da passare al server.
 Calcolata (\texttt{\small 14}) la dimensione, provvede (\texttt{\small 15}) ad
 immettere la richiesta sulla coda. 
 
 A questo punto non resta che (\texttt{\small 16}) rileggere dalla coda la
 risposta del server richiedendo a \func{msgrcv} di selezionare i messaggi di
-tipo corrispondente al valore del \acr{pid} inviato nella richiesta. L'ultimo
+tipo corrispondente al valore del \ids{PID} inviato nella richiesta. L'ultimo
 passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il
 messaggio ricevuto.
  
@@ -1686,8 +1686,8 @@ viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura
 della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
 il problema delle fifo che restavano nel filesystem). In questo caso però il
 problemi sono maggiori, sia perché è molto più facile esaurire la memoria
-dedicata ad una coda di messaggi che gli \index{inode} inode di un filesystem,
-sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
+dedicata ad una coda di messaggi che gli \itindex{inode} inode di un filesystem,
+sia perché, con il riutilizzo dei \ids{PID} da parte dei processi, un client
 eseguito in un momento successivo potrebbe ricevere un messaggio non
 indirizzato a lui.
 
@@ -1796,7 +1796,7 @@ semaforo all'uscita del processo.
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/semid_ds.h}
   \end{minipage} 
   \normalsize 
@@ -1838,7 +1838,7 @@ funzioni di controllo.
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/sem.h}
   \end{minipage} 
   \normalsize 
@@ -1851,7 +1851,7 @@ 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.
-\item[\var{sempid}] il \acr{pid} dell'ultimo processo che ha eseguito una
+\item[\var{sempid}] il \ids{PID} dell'ultimo processo che ha eseguito una
   operazione sul semaforo.
 \item[\var{semncnt}] il numero di processi in attesa che esso venga
   incrementato.
@@ -1888,7 +1888,7 @@ 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 tab.~\ref{tab:ipc_sem_limits}. Alcuni di questi limiti sono
 al solito accessibili e modificabili attraverso \func{sysctl} o scrivendo
-direttamente nel file \procfile{/proc/sys/kernel/sem}.
+direttamente nel file \sysctlfile{kernel/sem}.
 
 La funzione che permette di effettuare le varie operazioni di controllo sui
 semafori (fra le quali, come accennato, è impropriamente compresa anche la
@@ -1928,7 +1928,7 @@ specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/semun.h}
   \end{minipage} 
   \normalsize 
@@ -1957,14 +1957,14 @@ seguenti:
 \item[\const{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture
   dati, con effetto immediato. Tutti i processi che erano stato di
   \textit{sleep} vengono svegliati, ritornando con un errore di
-  \errcode{EIDRM}.  L'user-ID effettivo del processo deve corrispondere o al
+  \errcode{EIDRM}.  L'\ids{UID} effettivo del processo deve corrispondere o al
   creatore o al proprietario dell'insieme, o all'amministratore. L'argomento
   \param{semnum} viene ignorato.
 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
   dell'insieme. I valori devono essere passati in una struttura
   \struct{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i
   campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno
-  significativi di \var{sem\_perm.mode}. L'user-ID effettivo del processo deve
+  significativi di \var{sem\_perm.mode}. L'\ids{UID} effettivo del processo deve
   corrispondere o al creatore o al proprietario dell'insieme, o
   all'amministratore.  L'argomento \param{semnum} viene ignorato.
 \item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo
@@ -1977,7 +1977,7 @@ seguenti:
   \struct{sem}); va invocata con tre argomenti.  Occorre avere il permesso di
   lettura.
 \item[\const{GETPID}] Restituisce come valore di ritorno della funzione il
-  \acr{pid} dell'ultimo processo che ha compiuto una operazione sul semaforo
+  \ids{PID} dell'ultimo processo che ha compiuto una operazione sul semaforo
   \param{semnum} dell'insieme \param{semid} (corrispondente al campo
   \var{sempid} di \struct{sem}); va invocata con tre argomenti.  Occorre avere
   il permesso di lettura.
@@ -2074,7 +2074,7 @@ effettivamente eseguite se e soltanto se è possibile effettuarle tutte quante.
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/sembuf.h}
   \end{minipage} 
   \normalsize 
@@ -2159,7 +2159,7 @@ possibili:
 \end{basedescript}
 
 In caso di successo della funzione viene aggiornato il campo \var{sempid} per
-ogni semaforo modificato al valore del \acr{pid} del processo chiamante;
+ogni semaforo modificato al valore del \ids{PID} del processo chiamante;
 inoltre vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e
 \var{sem\_ctime}.
 
@@ -2183,7 +2183,7 @@ struttura del \textit{SysV IPC} è stata modificata, ma le definizioni relative
 a queste strutture restano per compatibilità.\footnote{in particolare con le
   vecchie versioni delle librerie del C, come le libc5.}
 
-\begin{figure}[htb]
+\begin{figure}[!htb]
   \centering \includegraphics[width=13cm]{img/semtruct}
   \caption{Schema della struttura di un insieme di semafori.}
   \label{fig:ipc_sem_schema}
@@ -2193,7 +2193,7 @@ Alla creazione di un nuovo insieme viene allocata una nuova strutture
 \struct{semid\_ds} ed il relativo vettore di strutture \struct{sem}. Quando si
 richiede una operazione viene anzitutto verificato che tutte le operazioni
 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
+kernel crea una struttura \kstruct{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}.}. 
@@ -2213,7 +2213,7 @@ 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
+per ciascun insieme di semafori una apposita struttura \kstruct{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.
@@ -2224,7 +2224,7 @@ all'insieme di cui fa parte il semaforo, che viene usata per invalidare le
 strutture se questo viene cancellato o per azzerarle se si è eseguita una
 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
+  \kstruct{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
@@ -2250,9 +2250,9 @@ 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à. 
 
-\begin{figure}[!bht]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/Mutex.c}
   \end{minipage} 
   \normalsize 
@@ -2319,7 +2319,7 @@ 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 sez.~\ref{sec:ipc_lock_file} come sia possibile ottenere
 un'interfaccia analoga a quella appena illustrata, senza incorrere in questi
-problemi, usando il \index{file!locking} \textit{file locking}.
+problemi, usando il \itindex{file~locking} \textit{file locking}.
 
 
 \subsection{Memoria condivisa}
@@ -2380,7 +2380,7 @@ norma, significa insieme a dei semafori.
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/shmid_ds.h}
   \end{minipage} 
   \normalsize 
@@ -2405,10 +2405,10 @@ invece:
 \item i campi \var{shm\_atime} e \var{shm\_dtime}, che esprimono
   rispettivamente il tempo dell'ultima volta che il segmento è stato
   agganciato o sganciato da un processo, vengono inizializzati a zero.
-\item il campo \var{shm\_lpid}, che esprime il \acr{pid} del processo che ha
+\item il campo \var{shm\_lpid}, che esprime il \ids{PID} del processo che ha
   eseguito l'ultima operazione, viene inizializzato a zero.
-\item il campo \var{shm\_cpid}, che esprime il \acr{pid} del processo che ha
-  creato il segmento, viene inizializzato al \acr{pid} del processo chiamante.
+\item il campo \var{shm\_cpid}, che esprime il \ids{PID} del processo che ha
+  creato il segmento, viene inizializzato al \ids{PID} del processo chiamante.
 \item il campo \var{shm\_nattac}, che esprime il numero di processi agganciati
   al segmento viene inizializzato a zero.
 \end{itemize}
@@ -2434,14 +2434,14 @@ che permettono di cambiarne il valore.
     & \textbf{Significato} \\
     \hline
     \hline
-    \const{SHMALL}& 0x200000&\procrelfile{/proc/sys/kernel}{shmall}
+    \const{SHMALL}& 0x200000&\sysctlrelfile{kernel}{shmall}
                             & Numero massimo di pagine che 
                               possono essere usate per i segmenti di
                               memoria condivisa.\\
-    \const{SHMMAX}&0x2000000&\procrelfile{/proc/sys/kernel}{shmmax} 
+    \const{SHMMAX}&0x2000000&\sysctlrelfile{kernel}{shmmax} 
                             & Dimensione massima di un segmento di memoria
                               condivisa.\\ 
-    \const{SHMMNI}&     4096&\procrelfile{/proc/sys/kernel}{msgmni}
+    \const{SHMMNI}&     4096&\sysctlrelfile{kernel}{msgmni}
                             & Numero massimo di segmenti di memoria condivisa
                               presenti nel kernel.\\ 
     \const{SHMMIN}&        1& ---         & Dimensione minima di un segmento di
@@ -2485,7 +2485,7 @@ un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è:
     \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o
       \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
+      valore del \ids{GID} o dell'\ids{UID} è troppo grande per essere
       memorizzato nella struttura puntata da \param{buf}.
     \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è
       valido.
@@ -2504,7 +2504,7 @@ corrispondente comportamento della funzione, sono i seguenti:
 \item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
   rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
   processo ad esso agganciato si sarà staccato. Questo comando può essere
-  eseguito solo da un processo con user-ID effettivo corrispondente o al
+  eseguito solo da un processo con \ids{UID} effettivo corrispondente o al
   creatore del segmento, o al proprietario del segmento, o all'amministratore.
 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
   del segmento.  Per modificare i valori di \var{shm\_perm.mode},
@@ -2567,9 +2567,8 @@ particolare l'indirizzo finale del segmento dati (quello impostato da
 Si tenga presente infine che la funzione ha successo anche se il segmento è
 stato marcato per la cancellazione.
 
-\begin{figure}[htb]
-  \centering
-  \includegraphics[height=10cm]{img/sh_memory_layout}
+\begin{figure}[!htb]
+  \centering \includegraphics[height=10cm]{img/sh_memory_layout}
   \caption{Disposizione dei segmenti di memoria di un processo quando si è
     agganciato un segmento di memoria condivisa.}
   \label{fig:ipc_shmem_layout}
@@ -2578,7 +2577,7 @@ stato marcato per la cancellazione.
 L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{lo standard
   SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
   come il valore di ritorno della funzione; in Linux è stato così con le
-  \acr{libc4} e le \acr{libc5}, con il passaggio alle \acr{glibc} il tipo di
+  \acr{libc4} e le \acr{libc5}, con il passaggio alla \acr{glibc} il tipo di
   \param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
   ritorno un \ctyp{void *}.} deve essere associato il segmento, se il valore
 specificato è \val{NULL} è il sistema a scegliere opportunamente un'area di
@@ -2609,7 +2608,7 @@ L'uso di \const{SHM\_RDONLY} permette di agganciare il segmento in sola
 lettura (si ricordi che anche le pagine di memoria hanno dei permessi), in tal
 caso un tentativo di scrivere sul segmento comporterà una
 \itindex{segment~violation} violazione di accesso con l'emissione di un
-segnale di \const{SIGSEGV}. Il comportamento usuale di \func{shmat} è quello
+segnale di \signal{SIGSEGV}. Il comportamento usuale di \func{shmat} è quello
 di agganciare il segmento con l'accesso in lettura e scrittura (ed il processo
 deve aver questi permessi in \var{shm\_perm}), non è prevista la possibilità
 di agganciare un segmento in sola scrittura.
@@ -2619,7 +2618,7 @@ In caso di successo la funzione aggiorna anche i seguenti campi di
 \begin{itemize*}
 \item il tempo \var{shm\_atime} dell'ultima operazione di aggancio viene
   impostato al tempo corrente.
-\item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul
+\item il \ids{PID} \var{shm\_lpid} dell'ultimo processo che ha operato sul
   segmento viene impostato a quello del processo corrente.
 \item il numero \var{shm\_nattch} di processi agganciati al segmento viene
   aumentato di uno.
@@ -2660,7 +2659,7 @@ In caso di successo la funzione aggiorna anche i seguenti campi di
 \begin{itemize*}
 \item il tempo \var{shm\_dtime} dell'ultima operazione di sganciamento viene
   impostato al tempo corrente.
-\item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul
+\item il \ids{PID} \var{shm\_lpid} dell'ultimo processo che ha operato sul
   segmento viene impostato a quello del processo corrente.
 \item il numero \var{shm\_nattch} di processi agganciati al segmento viene
   decrementato di uno.
@@ -2668,9 +2667,9 @@ In caso di successo la funzione aggiorna anche i seguenti campi di
 inoltre la regione di indirizzi usata per il segmento di memoria condivisa
 viene tolta dallo spazio di indirizzi del processo.
 
-\begin{figure}[!bht]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/SharedMem.c}
   \end{minipage} 
   \normalsize 
@@ -2750,14 +2749,14 @@ ricavare la parte di informazione che interessa.
 
 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
-video; al solito il codice completo si trova con i sorgenti allegati nel file
-\file{DirMonitor.c}.
+usate nel programma e delle \index{variabili!globali} variabili globali,
+omettendo tutto quello che riguarda la gestione delle opzioni e la stampa
+delle istruzioni di uso a video; al solito il codice completo si trova con i
+sorgenti allegati nel file \file{DirMonitor.c}.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/DirMonitor.c}
   \end{minipage} 
   \normalsize 
@@ -2765,11 +2764,11 @@ video; al solito il codice completo si trova con i sorgenti allegati nel file
   \label{fig:ipc_dirmonitor_main}
 \end{figure}
 
-Il programma usa delle variabili globali (\texttt{\small 2--14}) per mantenere
-i valori relativi agli oggetti usati per la comunicazione inter-processo; si è
-definita inoltre una apposita struttura \struct{DirProp} che contiene i dati
-relativi alle proprietà che si vogliono mantenere nella memoria condivisa, per
-l'accesso da parte dei client.
+Il programma usa delle \index{variabili!globali} variabili globali
+(\texttt{\small 2--14}) per mantenere i valori relativi agli oggetti usati per
+la comunicazione inter-processo; si è definita inoltre una apposita struttura
+\struct{DirProp} che contiene i dati relativi alle proprietà che si vogliono
+mantenere nella memoria condivisa, per l'accesso da parte dei client.
 
 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
@@ -2782,9 +2781,9 @@ con un messaggio di errore.
 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,
+la \index{directory~di~lavoro} 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 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
@@ -2809,9 +2808,9 @@ sarà vista nella forma data da \struct{DirProp}. Infine (\texttt{\small
 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]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/ComputeValues.c}
   \end{minipage} 
   \normalsize 
@@ -2825,17 +2824,17 @@ intercomunicazione il programma entra nel ciclo principale (\texttt{\small
 Il primo passo (\texttt{\small 41}) è eseguire \func{daemon} per proseguire
 con l'esecuzione in background come si conviene ad un programma demone; si
 noti che si è mantenuta, usando un valore non nullo del primo argomento, la
-directory di lavoro corrente.  Una volta che il programma è andato in
-background l'esecuzione prosegue (\texttt{\small 42--48}) all'interno di un
-ciclo infinito: si inizia (\texttt{\small 43}) bloccando il mutex con
-\func{MutexLock} per poter accedere alla memoria condivisa (la funzione si
-bloccherà automaticamente se qualche client sta leggendo), poi (\texttt{\small
-  44}) si cancellano i valori precedentemente immagazzinati nella memoria
-condivisa con \func{memset}, e si esegue (\texttt{\small 45}) un nuovo calcolo
-degli stessi utilizzando la funzione \func{DirScan}; infine (\texttt{\small
-  46}) si sblocca il mutex con \func{MutexUnlock}, e si attende
-(\texttt{\small 47}) per il periodo di tempo specificato a riga di comando con
-l'opzione \code{-p} con una \func{sleep}.
+\index{directory~di~lavoro} directory di lavoro corrente.  Una volta che il
+programma è andato in background l'esecuzione prosegue (\texttt{\small
+  42--48}) all'interno di un ciclo infinito: si inizia (\texttt{\small 43})
+bloccando il mutex con \func{MutexLock} per poter accedere alla memoria
+condivisa (la funzione si bloccherà automaticamente se qualche client sta
+leggendo), poi (\texttt{\small 44}) si cancellano i valori precedentemente
+immagazzinati nella memoria condivisa con \func{memset}, e si esegue
+(\texttt{\small 45}) un nuovo calcolo degli stessi utilizzando la funzione
+\func{DirScan}; infine (\texttt{\small 46}) si sblocca il mutex con
+\func{MutexUnlock}, e si attende (\texttt{\small 47}) per il periodo di tempo
+specificato a riga di comando con 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
@@ -2847,8 +2846,8 @@ 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}.
+contatori nella memoria condivisa, cui accede grazie alla
+\index{variabili!globali} variabile globale \var{shmptr}.
 
 Dato che la funzione è chiamata da \func{DirScan}, si è all'interno del ciclo
 principale del programma, con un mutex acquisito, perciò non è necessario
@@ -2869,9 +2868,9 @@ i dati, dopo di che (\texttt{\small 20}) distacca e rimuove il segmento di
 memoria condivisa usando \func{ShmRemove}.  Infine (\texttt{\small 21})
 rimuove il mutex con \func{MutexRemove} ed esce (\texttt{\small 22}).
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6 cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/ReadMonitor.c}
   \end{minipage} 
   \normalsize 
@@ -2959,7 +2958,7 @@ Totale  72 file, per 489887 byte
 %$
 
 A questo punto possiamo far uscire il server inviandogli un segnale di
-\const{SIGTERM} con il comando \code{killall dirmonitor}, a questo punto
+\signal{SIGTERM} con il comando \code{killall dirmonitor}, a questo punto
 ripetendo la lettura, otterremo un errore:
 \begin{Verbatim}
 [piccardi@gont sources]$ ./readmon 
@@ -2987,7 +2986,7 @@ key        msqid      owner      perms      used-bytes   messages
 %% condivisa; uno schema semplificato della struttura è illustrato in
 %% fig.~\ref{fig:ipc_shm_struct}. 
 
-%% \begin{figure}[htb]
+%% \begin{figure}[!htb]
 %%   \centering
 %%   \includegraphics[width=10cm]{img/shmstruct}
 %%    \caption{Schema dell'implementazione dei segmenti di memoria condivisa in
@@ -3071,9 +3070,9 @@ guida) che permettono rispettivamente di creare e rimuovere un \textsl{file di
   9}) nella modalità descritta, mentre la seconda (\texttt{\small 11--17}) lo
 cancella con \func{unlink}.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/LockFile.c}
   \end{minipage} 
   \normalsize 
@@ -3118,9 +3117,9 @@ accedere alla seriale si limita a segnalare che la risorsa non è disponibile.
 
 Dato che i \index{file!di lock} file di lock presentano gli inconvenienti
 illustrati in precedenza, la tecnica alternativa di sincronizzazione più
-comune è quella di fare ricorso al \index{file!locking} \textit{file locking}
-(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
+comune è quella di fare ricorso al \itindex{file~locking} \textit{file
+  locking} (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
@@ -3135,19 +3134,19 @@ non consuma risorse permanentemente allocate nel sistema. Lo svantaggio è che,
 dovendo fare ricorso a delle operazioni sul filesystem, esso è in genere
 leggermente più lento.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/MutexLocking.c}
   \end{minipage} 
   \normalsize 
   \caption{Il codice delle funzioni che permettono per la gestione dei 
-    \textit{mutex} con il \index{file!locking} \textit{file locking}.}
+    \textit{mutex} con il \itindex{file~locking} \textit{file locking}.}
   \label{fig:ipc_flock_mutex}
 \end{figure}
 
 Il codice delle varie funzioni usate per implementare un mutex utilizzando il
-\textit{file locking} \index{file!locking} è riportato in
+\textit{file locking} \itindex{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
@@ -3164,7 +3163,7 @@ 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 \index{file!locking} \textit{file locking},
+aprire il file da usare per il \itindex{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à.
 
@@ -3181,7 +3180,7 @@ 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 \index{file!locking} \textit{file
+chiamata a \func{fcntl}. Avendo usato il \itindex{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.
@@ -3270,7 +3269,7 @@ una interfaccia completamente nuova, che tratteremo in questa sezione.
 
 Oggi Linux supporta tutti gli oggetti definito nello standard POSIX per l'IPC,
 ma a lungo non è stato così; la memoria condivisa è presente a partire dal
-kernel 2.4.x, i semafori sono forniti dalle \acr{glibc} nella sezione che
+kernel 2.4.x, i semafori sono forniti dalla \acr{glibc} nella sezione che
 implementa i \itindex{thread} \textit{thread} POSIX di nuova generazione che
 richiedono il kernel 2.6, le code di messaggi sono supportate a partire dal
 kernel 2.6.6.
@@ -3285,8 +3284,8 @@ 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
-  \itindex{pathname} \textit{pathname}, in particolare non essere più lunghi di
-  \const{PATH\_MAX} byte e terminati da un carattere nullo.
+  \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.
@@ -3325,7 +3324,7 @@ quella particolare (si ricordi quanto visto in
 sez.~\ref{sec:ipc_sysv_access_control}) che viene 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: corrispondono cioè a user-ID e group-ID effettivi
+secondo la semantica SysV: corrispondono cioè a \ids{UID} e \ids{GID} effettivi
 del processo che esegue la creazione.
 
 
@@ -3335,8 +3334,7 @@ del processo che esegue la creazione.
 Le code di messaggi POSIX sono supportate da Linux a partire dalla versione
 2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e
   Krzysztof Benedyczak, e le relative informazioni si possono trovare su
-  \href{http://www.geocities.com/wronski12/posix_ipc/index.html}
-  {\textsf{http://www.geocities.com/wronski12/posix\_ipc/index.html}}.} In
+  \url{http://www.geocities.com/wronski12/posix_ipc/index.html}.} In
 generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
 usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e
 che in casi più complessi la comunicazione può essere gestita direttamente con
@@ -3348,7 +3346,7 @@ relativi patch) occorre utilizzare la libreria \file{libmqueue}\footnote{i
   programmi che usano le code di messaggi cioè devono essere compilati
   aggiungendo l'opzione \code{-lmqueue} al comando \cmd{gcc}; in
   corrispondenza all'inclusione del supporto nel kernel ufficiale anche
-  \file{libmqueue} è stata inserita nelle \acr{glibc}, a partire dalla
+  \file{libmqueue} è stata inserita nella \acr{glibc}, a partire dalla
   versione 2.3.4 delle medesime.} che contiene le funzioni dell'interfaccia
 POSIX.\footnote{in realtà l'implementazione è realizzata tramite delle
   opportune chiamate ad \func{ioctl} sui file del filesystem speciale su cui
@@ -3454,7 +3452,7 @@ cui definizione è riportata in fig.~\ref{fig:ipc_mq_attr}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\textwidth}
     \includestruct{listati/mq_attr.h}
   \end{minipage} 
   \normalsize
@@ -3660,7 +3658,7 @@ Se la dimensione specificata da \param{msg\_len} non è sufficiente a contenere
 il messaggio, entrambe le funzioni, al contrario di quanto avveniva nelle code
 di messaggi di SysV, ritornano un errore di \errcode{EMSGSIZE} senza estrarre
 il messaggio.  È pertanto opportuno eseguire sempre una chiamata a
-\func{mq\_getaddr} prima di eseguire una ricezione, in modo da ottenere la
+\func{mq\_getattr} prima di eseguire una ricezione, in modo da ottenere la
 dimensione massima dei messaggi sulla coda, per poter essere in grado di
 allocare dei buffer sufficientemente ampi per la lettura.
 
@@ -3731,7 +3729,7 @@ valori di tab.~\ref{tab:sigevent_sigev_notify}.\footnote{la pagina di manuale
   \const{SIGEV\_SIGNAL}).} Il metodo consigliato è quello di usare
 \const{SIGEV\_SIGNAL} usando il campo \var{sigev\_signo} per indicare il quale
 segnale deve essere inviato al processo. Inoltre il campo \var{sigev\_value} è
-un puntatore ad una struttura \struct{sigval\_t} (definita in
+un puntatore ad una struttura \struct{sigval} (definita in
 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 sez.~\ref{sec:sig_real_time} a proposito dei segnali
@@ -3773,7 +3771,7 @@ questa operazione prima di 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
 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}
+valore del \ids{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
@@ -3792,9 +3790,9 @@ il filesystem \texttt{tmpfs}, uno speciale filesystem che mantiene tutti i
 suoi contenuti in memoria, che viene attivato abilitando l'opzione
 \texttt{CONFIG\_TMPFS} in fase di compilazione del kernel.
 
-Per potere utilizzare l'interfaccia POSIX per la memoria condivisa le
-\acr{glibc}\footnote{le funzioni sono state introdotte con le glibc-2.2.}
-richiedono di compilare i programmi con l'opzione \code{-lrt}; inoltre è
+Per potere utilizzare l'interfaccia POSIX per la memoria condivisa la
+\acr{glibc}\footnote{le funzioni sono state introdotte con la versione 2.2.}
+richiede di compilare i programmi con l'opzione \code{-lrt}; inoltre è
 necessario che in \file{/dev/shm} sia montato un filesystem \texttt{tmpfs};
 questo di norma viene fatto aggiungendo una riga del tipo di:
 \begin{verbatim}
@@ -3869,7 +3867,7 @@ segmento di memoria condiviso con le stesse modalità di
 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
-\index{inode} inode).  In questo modo è possibile effettuare una chiamata ad
+\itindex{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.
 
@@ -3903,9 +3901,9 @@ con lo stesso nome, la chiamata a \func{shm\_open} fallirà, a meno di non aver
 usato \const{O\_CREAT}, in quest'ultimo caso comunque si otterrà un file
 descriptor che fa riferimento ad un segmento distinto da eventuali precedenti.
 
-\begin{figure}[!htb]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/MemShared.c}
   \end{minipage} 
   \normalsize 
@@ -3967,7 +3965,7 @@ dei semafori POSIX che li realizzava solo a livello di \itindex{thread}
   erano visibili solo all'interno dei \itindex{thread} \textit{thread} creati
   da un singolo processo, e non potevano essere usati come meccanismo di
   sincronizzazione fra processi diversi.} fornita attraverso la sezione delle
-estensioni \textit{real-time} delle \acr{glibc}.\footnote{quelle che si
+estensioni \textit{real-time} della \acr{glibc}.\footnote{quelle che si
   accedono collegandosi alla libreria \texttt{librt}.} Esisteva inoltre una
 libreria che realizzava (parzialmente) l'interfaccia POSIX usando le funzioni
 dei semafori di SysV IPC (mantenendo così tutti i problemi sottolineati in
@@ -3977,7 +3975,7 @@ 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{fast user mode mutex}.} con
 il quale è stato possibile implementare una versione nativa dei semafori
-POSIX.  Grazie a questo con i kernel della serie 2.6 e le nuove versioni delle
+POSIX.  Grazie a questo con i kernel della serie 2.6 e le nuove versioni della
 \acr{glibc} che usano questa nuova infrastruttura per quella che viene quella
 che viene chiamata \textit{New Posix Thread Library}, sono state implementate
 anche tutte le funzioni dell'interfaccia dei semafori POSIX.
@@ -4005,7 +4003,7 @@ esistente o per crearne uno nuovi, i relativi prototipi sono:
     successo e \const{SEM\_FAILED} in caso di errore; nel quel caso
     \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\errcode{EACCESS}] il semaforo esiste ma non si hanno permessi
+    \item[\errcode{EACCES}] il semaforo esiste ma non si hanno permessi
       sufficienti per accedervi.
     \item[\errcode{EEXIST}] si sono specificati \const{O\_CREAT} e
       \const{O\_EXCL} ma il semaforo esiste.
@@ -4020,12 +4018,12 @@ esistente o per crearne uno nuovi, i relativi prototipi sono:
 
 L'argomento \param{name} definisce il nome del semaforo che si vuole
 utilizzare, ed è quello che permette a processi diversi di accedere allo
-stesso semaforo. Questo deve essere specificato con un pathname nella forma
-\texttt{/qualchenome}, che non ha una corrispondenza diretta con un pathname
-reale; con Linux infatti i file associati ai semafori sono mantenuti nel
-filesystem virtuale \texttt{/dev/shm}, e gli viene assegnato automaticamente
-un nome nella forma \texttt{sem.qualchenome}.\footnote{si ha cioè una
-  corrispondenza per cui \texttt{/qualchenome} viene rimappato, nella
+stesso semaforo. Questo deve essere specificato con un \textit{pathname} nella
+forma \texttt{/qualchenome}, che non ha una corrispondenza diretta con un
+\textit{pathname} reale; con Linux infatti i file associati ai semafori sono
+mantenuti nel filesystem virtuale \texttt{/dev/shm}, e gli viene assegnato
+automaticamente un nome nella forma \texttt{sem.qualchenome}.\footnote{si ha
+  cioè una corrispondenza per cui \texttt{/qualchenome} viene rimappato, nella
   creazione tramite \func{sem\_open}, su \texttt{/dev/shm/sem.qualchenome}.}
 
 L'argomento \param{oflag} è quello che controlla le modalità con cui opera la
@@ -4056,8 +4054,8 @@ presente che, come accennato in sez.~\ref{sec:ipc_posix_generic}, i semafori
 usano la semantica standard dei file per quanto riguarda i controlli di
 accesso. 
 
-Questo significa che un nuovo semaforo viene sempre creato con l'user-ID ed il
-group-ID effettivo del processo chiamante, e che i permessi indicati con
+Questo significa che un nuovo semaforo viene sempre creato con l'\ids{UID} ed
+il \ids{GID} effettivo del processo chiamante, e che i permessi indicati con
 \param{mode} vengono filtrati dal valore della \itindex{umask} \textit{umask}
 del processo.  Inoltre per poter aprire un semaforo è necessario avere su di
 esso sia il permesso di lettura che quello di scrittura.
@@ -4130,8 +4128,8 @@ programma possa proseguire.
 
 La seconda variante di \func{sem\_wait} è una estensione specifica che può
 essere utilizzata soltanto se viene definita la macro \macro{\_XOPEN\_SOURCE}
-ad un valore di 600 prima di includere \texttt{semaphore.h}, la funzione è
-\func{sem\_timedwait}, ed il suo prototipo è:
+ad un valore di 600 prima di includere \headfile{semaphore.h}, la funzione è
+\funcd{sem\_timedwait}, ed il suo prototipo è:
 \begin{functions}
   \headdecl{semaphore.h} 
 
@@ -4263,7 +4261,7 @@ lo si cancelli esplicitamente. Per far questo si può utilizzare la funzione
   \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
     errore; nel quel caso \var{errno} assumerà i valori:
     \begin{errlist}
-    \item[\errcode{EACCESS}] non si hanno i permessi necessari a cancellare il
+    \item[\errcode{EACCES}] non si hanno i permessi necessari a cancellare il
       semaforo.
     \item[\errcode{ENAMETOOLONG}] il nome indicato è troppo lungo.
     \item[\errcode{ENOENT}] il semaforo \param{name} non esiste.
@@ -4315,8 +4313,8 @@ Qualora il semaforo debba essere condiviso dai \itindex{thread}
 \textit{thread} di uno stesso processo (nel qual caso si parla di
 \textit{thread-shared semaphore}), occorrerà che \param{sem} sia l'indirizzo
 di una variabile visibile da tutti i \itindex{thread} \textit{thread}, si
-dovrà usare cioè una variabile globale o una variabile allocata dinamicamente
-nello \itindex{heap} \textit{heap}.
+dovrà usare cioè una \index{variabili!globali} variabile globale o una
+variabile allocata dinamicamente nello \itindex{heap} \textit{heap}.
 
 Qualora il semaforo debba essere condiviso fra più processi (nel qual caso si
 parla di \textit{process-shared semaphore}) la sola scelta possibile per
@@ -4371,9 +4369,9 @@ scritti due semplici programmi con i quali è possibile rispettivamente
 monitorare il contenuto di un segmento di memoria condivisa e modificarne il
 contenuto. 
 
-\begin{figure}[!h]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/message_getter.c}
   \end{minipage} 
   \normalsize 
@@ -4398,9 +4396,9 @@ dall'altro programma prima di averla finita di stampare.
 
 La parte iniziale del programma contiene le definizioni (\texttt{\small 1--8})
 del gestore del segnale usato per liberare le risorse utilizzate, delle
-variabili globali contenenti i nomi di default del segmento di memoria
-condivisa e del semaforo (il default scelto è \texttt{messages}), e delle
-altre variabili utilizzate dal programma.
+\index{variabili!globali} variabili globali contenenti i nomi di default del
+segmento di memoria condivisa e del semaforo (il default scelto è
+\texttt{messages}), e delle altre variabili utilizzate dal programma.
 
 Come prima istruzione (\texttt{\small 10}) si è provveduto ad installare un
 gestore di segnale che consentirà di effettuare le operazioni di pulizia
@@ -4444,9 +4442,9 @@ controllo. Il primo passo (\texttt{\small 30--34}) è quello di acquisire (con
 semaforo ad inizio del ciclo; seguito (\texttt{\small 35--36}) dal tempo
 corrente.
 
-\begin{figure}[!h]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/HandSigInt.c}
   \end{minipage} 
   \normalsize 
@@ -4464,16 +4462,16 @@ ciclo.
 
 Per uscire in maniera corretta dal programma sarà necessario interromperlo con
 il break da tastiera (\texttt{C-c}), che corrisponde all'invio del segnale
-\const{SIGINT}, per il quale si è installato (\texttt{\small 10}) una
+\signal{SIGINT}, per il quale si è installato (\texttt{\small 10}) una
 opportuna funzione di gestione, riportata in
 fig.~\ref{fig:ipc_posix_sem_shm_message_server_handler}. La funzione è molto
 semplice e richiama le funzioni di rimozione sia per il segmento di memoria
 condivisa che per il semaforo, garantendo così che possa essere riaperto
 ex-novo senza errori in un futuro riutilizzo del comando.
 
-\begin{figure}[!h]
+\begin{figure}[!htbp]
   \footnotesize \centering
-  \begin{minipage}[c]{15cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/message_setter.c}
   \end{minipage} 
   \normalsize 
@@ -4622,7 +4620,7 @@ testo alla terminazione di quest'ultimo.
 % 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 LIBRARY Library libmqueue FAILED EACCESS has
+% LocalWords:  CreateShm RemoveShm LIBRARY Library libmqueue FAILED has
 % LocalWords:  ENAMETOOLONG qualchenome RESTART trywait XOPEN SOURCE timedwait
 % LocalWords:  process getvalue sval execve pshared ENOSYS heap PAGE destroy it
 % LocalWords:  xffffffff Arrays owner perms Queues used bytes messages device