X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=742846d1d9729b2b5f0bdc327f539f21af28c131;hp=c7af63283aa8f317c9b47ccd05779bfefaf91b3a;hb=922de35645e21550b70e2e5fe5ced103a0d2e0b4;hpb=4cbeb0e4fa1d31da798c8e68108eb6785586ab34

diff --git a/ipc.tex b/ipc.tex
index c7af632..742846d 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -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}.
@@ -892,7 +892,7 @@ gli 8 bit meno significativi.\footnote{nelle libc4 e libc5, come avviene in
 
 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
@@ -1686,7 +1686,7 @@ 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,
+dedicata ad una coda di messaggi che gli \itindex{inode} inode di un filesystem,
 sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
 eseguito in un momento successivo potrebbe ricevere un messaggio non
 indirizzato a lui.
@@ -3868,7 +3868,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.