Reindicizzazioni

[gapil.git] / ipc.tex

diff --git a/ipc.tex b/ipc.tex
index 33319a7c6e1929b5d97b97632327910ca6498fae..9b7ac1a21a90ed2c395f4542f728556604db5f25 100644 (file)
--- 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
 
 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
 
 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
 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
 
 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
 
 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.
 
 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}.  
 
 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
 
 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
   \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}
 
   \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)}
 
 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
 
 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
 \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}
 
 
 \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
 
 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
 %
 % 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
 \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}
 
 
 \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 
     \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}
     \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
 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)
 
 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
 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}{
 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
 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 è:
 
 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}
 %$
 
 \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
 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