X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=9b7ac1a21a90ed2c395f4542f728556604db5f25;hp=33319a7c6e1929b5d97b97632327910ca6498fae;hb=be0113897fdc6774f0dcc3f9c91fe5e76c5dd0a5;hpb=7208522fd60468969d96dba5d8dd2cbd24b75b89

diff --git a/ipc.tex b/ipc.tex
index 33319a7..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
@@ -539,9 +539,8 @@ una \textit{fifo} in scrittura anche se non ci sono ancora processi il
 lettura. Infine è possibile anche usare la \textit{fifo} all'interno di un
 solo processo, nel qual caso però occorre stare molto attenti alla possibili
 situazioni di stallo: se si cerca di leggere da una \textit{fifo} che non
-contiene dati si avrà infatti un \itindex{deadlock} \textit{deadlock}
-immediato, dato che il processo si blocca e quindi non potrà mai eseguire le
-funzioni di scrittura.
+contiene dati si avrà infatti un \textit{deadlock} immediato, dato che il
+processo si blocca e quindi non potrà mai eseguire le funzioni di scrittura.
 
 Per la loro caratteristica di essere accessibili attraverso il filesystem, è
 piuttosto frequente l'utilizzo di una \textit{fifo} come canale di
@@ -739,7 +738,7 @@ 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
+state raccolte nella libreria \file{libgapil.so}, e per poterla usare
 occorrerà definire la variabile di ambiente \envvar{LD\_LIBRARY\_PATH} in modo
 che il linker dinamico possa accedervi.
 
@@ -865,11 +864,11 @@ 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}.  
 
-A partire dal kernel 2.6.27 la funzione supporta anche l'uso dei flag
-\const{SOCK\_NONBLOCK} e \const{SOCK\_CLOEXEC} (trattati in
-sez.~\ref{sec:sock_type}) nell'indicazione del tipo di socket, con effetto
-identico agli analoghi \const{O\_CLOEXEC} e \const{O\_NONBLOCK} di una
-\func{open} (vedi tab.~\ref{tab:open_operation_flag}).
+A partire dal kernel 2.6.27 la funzione supporta nell'indicazione del tipo di
+socket anche i due flag \const{SOCK\_NONBLOCK} e \const{SOCK\_CLOEXEC}
+(trattati in sez.~\ref{sec:sock_type}), con effetto identico agli analoghi
+\const{O\_CLOEXEC} e \const{O\_NONBLOCK} di una \func{open} (vedi
+tab.~\ref{tab:open_operation_flag}).
 
 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 socket
@@ -947,7 +946,7 @@ mantiene varie proprietà ed informazioni associate all'oggetto.
   \end{minipage} 
   \normalsize 
   \caption{La struttura \structd{ipc\_perm}, come definita in
-    \headfile{sys/ipc.h}.}
+    \headfiled{sys/ipc.h}.}
   \label{fig:ipc_ipc_perm}
 \end{figure}
 
@@ -995,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
@@ -1316,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}
 
@@ -1343,7 +1342,7 @@ adeguata i principi di funzionamento delle code di messaggi.
 
 A ciascuna coda è associata una struttura \struct{msqid\_ds} la cui
 definizione è riportata in fig.~\ref{fig:ipc_msqid_ds} ed a cui si accede
-includendo  \headfile{sys/msg.h};
+includendo \headfiled{sys/msg.h};
 %
 % INFO: sotto materiale obsoleto e non interessante
 % In questa struttura il
@@ -1836,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}
@@ -2084,7 +2083,7 @@ specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
     \includestruct{listati/semun.h}
   \end{minipage} 
   \normalsize 
-  \caption{La definizione dei possibili valori di una \direct{union}
+  \caption{La definizione dei possibili valori di una \dirct{union}
     \structd{semun}, usata come quarto argomento della funzione
     \func{semctl}.}
   \label{fig:ipc_semun}
@@ -4263,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)
@@ -4567,7 +4566,7 @@ 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 almeno 600 o la macro \macro{\_POSIX\_C\_SOURCE} ad un valore
 uguale o maggiore di \texttt{200112L} prima di includere
-\headfile{semaphore.h}, la funzione è \funcd{sem\_timedwait}, ed il suo
+\headfiled{semaphore.h}, la funzione è \funcd{sem\_timedwait}, ed il suo
 prototipo è:
 
 \begin{funcproto}{
@@ -4627,8 +4626,8 @@ dall'argomento \param{sem}, se questo era nullo la relativa risorsa risulterà
 sbloccata, cosicché un altro processo (o \itindex{thread} \textit{thread})
 eventualmente bloccato in una \func{sem\_wait} sul semaforo possa essere
 svegliato e rimesso in esecuzione.  Si tenga presente che la funzione è sicura
-\index{funzioni!sicure} per l'uso all'interno di un gestore di segnali (si
-ricordi quanto detto in sez.~\ref{sec:sig_signal_handler}).
+per l'uso all'interno di un gestore di segnali (si ricordi quanto detto in
+sez.~\ref{sec:sig_signal_handler}).
 
 Se invece di operare su un semaforo se ne volesse semplicemente leggere il
 valore, si potrà usare la funzione \funcd{sem\_getvalue}, il cui prototipo è:
@@ -5012,10 +5011,10 @@ message: ciao
 \end{Console}
 %$
 
-E si noterà come nel momento in cui si è lanciato \file{message\_setter} le
-stampe di \file{message\_getter} si bloccheranno, come corretto, dopo aver
-registrato un valore nullo per il semaforo.  Il programma infatti resterà
-bloccato nella \func{sem\_wait} (quella di riga (\texttt{\small 37}) in
+E si noterà come nel momento in cui si lancia \file{message\_setter} le stampe
+di \file{message\_getter} si bloccheranno, come corretto, dopo aver registrato
+un valore nullo per il semaforo.  Il programma infatti resterà bloccato nella
+\func{sem\_wait} (quella di riga (\texttt{\small 37}) in
 fig.~\ref{fig:ipc_posix_sem_shm_message_server}) fino alla scadenza
 dell'attesa di \file{message\_setter} (con l'esecuzione della \func{sem\_post}
 della riga (\texttt{\small 29}) di