X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=9b7ac1a21a90ed2c395f4542f728556604db5f25;hp=01c4c5b825fcc97a8b97e28e7685ea2a6885ab1b;hb=be0113897fdc6774f0dcc3f9c91fe5e76c5dd0a5;hpb=99fa5a06cd27160cf673e3483ad552d32efa2c05

diff --git a/ipc.tex b/ipc.tex
index 01c4c5b..9b7ac1a 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -505,12 +505,12 @@ essere in una relazione di \textsl{parentela}.
 
 Utilizzando una \textit{fifo} tutti i dati passeranno, come per le
 \textit{pipe}, attraverso un buffer nel kernel, senza transitare dal
-filesystem. Il fatto che siano associate ad un \itindex{inode}
-\textit{inode} presente sul filesystem serve infatti solo a fornire un punto
-di accesso per i processi, che permetta a questi ultimi di accedere alla
-stessa \textit{fifo} senza avere nessuna relazione, con una semplice
-\func{open}. Il comportamento delle funzioni di lettura e scrittura è identico
-a quello illustrato per le \textit{pipe} in sez.~\ref{sec:ipc_pipes}.
+filesystem. Il fatto che siano associate ad un \textit{inode} presente sul
+filesystem serve infatti solo a fornire un punto di accesso per i processi,
+che permetta a questi ultimi di accedere alla stessa \textit{fifo} senza avere
+nessuna relazione, con una semplice \func{open}. Il comportamento delle
+funzioni di lettura e scrittura è identico a quello illustrato per le
+\textit{pipe} in sez.~\ref{sec:ipc_pipes}.
 
 Abbiamo già trattato in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
 \func{mkfifo} che permettono di creare una \textit{fifo}. Per utilizzarne una
@@ -994,12 +994,12 @@ 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 \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
-collisioni, specie se i file sono su dispositivi con lo stesso \textit{minor
-  number}, come \file{/dev/hda1} e \file{/dev/sda1}.
+con i 16 bit meno significativi 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 collisioni, specie se i
+file sono su dispositivi con lo stesso \textit{minor number}, come
+\file{/dev/hda1} e \file{/dev/sda1}.
 
 In genere quello che si fa è utilizzare un file comune usato dai programmi che
 devono comunicare (ad esempio un header comune, o uno dei programmi che devono
@@ -1315,21 +1315,21 @@ l'uso di \func{sysctl} o scrivendo nei file \sysctlrelfile{kernel}{msgmax},
 \itindbeg{linked~list}
 
 Una coda di messaggi è costituita da una \textit{linked list}.\footnote{una
-  \itindex{linked~list} \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 uno schema semplificato con cui
-queste strutture vengono mantenute dal kernel. Lo schema illustrato in realtà
-è una semplificazione di quello usato fino ai kernel della serie 2.2. A
-partire della serie 2.4 la gestione delle code di messaggi è effettuata in
-maniera diversa (e non esiste una struttura \struct{msqid\_ds} nel kernel), ma
-abbiamo mantenuto lo schema precedente dato che illustra in maniera più che
-adeguata i principi di funzionamento delle code di messaggi.
+  \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 uno schema semplificato con cui queste strutture vengono mantenute
+dal kernel. Lo schema illustrato in realtà è una semplificazione di quello
+usato fino ai kernel della serie 2.2. A partire della serie 2.4 la gestione
+delle code di messaggi è effettuata in maniera diversa (e non esiste una
+struttura \struct{msqid\_ds} nel kernel), ma abbiamo mantenuto lo schema
+precedente dato che illustra in maniera più che adeguata i principi di
+funzionamento delle code di messaggi.
 
 \itindend{linked~list}
 
@@ -1835,9 +1835,9 @@ lettura della risposta, quest'ultima resta nella coda (così come per le
 \textit{fifo} si aveva il problema delle \textit{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
-\itindex{inode} \textit{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.
+\textit{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.
 
 
 \subsection{I semafori}
@@ -4262,9 +4262,9 @@ sez.~\ref{sec:file_open_close}. Inoltre sul file descriptor viene sempre
 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 ordinari, essi sono associati
-allo stesso \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.
+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.
 
 Quando il nome non esiste si può creare un nuovo segmento specificando
 \const{O\_CREAT}; in tal caso il segmento avrà (così come i nuovi file)