X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=81ca6a8238aa46dd37d4a78931bcb5e1c1d95d7b;hp=49f342f4f42264c5cb266203acbe2c4d91be28f2;hb=8e2e77dff8f3cffb28ddf982280dff6fc015eb19;hpb=46a0b60524792834439820af5e8267ce8ff9dc39

diff --git a/ipc.tex b/ipc.tex
index 49f342f..81ca6a8 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -74,6 +74,9 @@ 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.
 
+% TODO: la dimensione è cambiata a 64k (vedi man 7 pipe) e può essere
+% modificata con F_SETPIPE_SZ dal 2.6.35 (vedi fcntl)
+
 \begin{figure}[!htb]
   \centering
   \includegraphics[height=5cm]{img/pipe}
@@ -82,7 +85,7 @@ indicano la direzione del flusso dei dati.
 \end{figure}
 
 Chiaramente creare una pipe all'interno di un singolo processo non serve a
-niente; se però ricordiamo quanto esposto in sez.~\ref{sec:file_sharing}
+niente; se però ricordiamo quanto esposto in sez.~\ref{sec:file_shared_access}
 riguardo al comportamento dei file descriptor nei processi figli, è immediato
 capire come una pipe possa diventare un meccanismo di intercomunicazione. Un
 processo figlio infatti condivide gli stessi file descriptor del padre,
@@ -184,11 +187,10 @@ Il programma ci servirà anche come esempio dell'uso delle funzioni di
 duplicazione dei file descriptor che abbiamo trattato in
 sez.~\ref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
 funzioni infatti che è possibile dirottare gli stream standard dei processi
-(che abbiamo visto in sez.~\ref{sec:file_std_descr} e
-sez.~\ref{sec:file_std_stream}) sulla pipe. In
-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.
+(che abbiamo visto in tab.~\ref{tab:file_std_files} e
+sez.~\ref{sec:file_stream}) sulla pipe. In 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}[!htbp]
   \footnotesize \centering
@@ -302,9 +304,9 @@ che sarà aperto in sola lettura (e quindi associato allo standard output del
 programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
 quindi associato allo standard input) in caso di \code{"w"}.
 
-Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
-stream visti in cap.~\ref{cha:files_std_interface}, anche se è collegato ad
-una pipe e non ad un file, e viene sempre aperto in modalità
+Lo \textit{stream} restituito da \func{popen} è identico a tutti gli effetti
+ai \textit{file stream} visti in sez.~\ref{sec:files_std_interface}, anche se
+è collegato ad una pipe e non ad un file, e viene sempre aperto in modalità
 \textit{fully-buffered} (vedi sez.~\ref{sec:file_buffering}); l'unica
 differenza con gli usuali stream è che dovrà essere chiuso dalla seconda delle
 due nuove funzioni, \funcd{pclose}, il cui prototipo è:
@@ -431,7 +433,7 @@ quello illustrato per le pipe in sez.~\ref{sec:ipc_pipes}.
 
 Abbiamo già visto in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
 \func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
-processo non avrà che da aprire il relativo \index{file!speciale} file
+processo non avrà che da aprire il relativo \index{file!speciali} file
 speciale o in lettura o scrittura; nel primo caso sarà collegato al capo di
 uscita della fifo, e dovrà leggere, nel secondo al capo di ingresso, e dovrà
 scrivere.
@@ -3053,7 +3055,7 @@ La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare
 dei \textsl{file di lock} (per i quali esiste anche una opportuna directory,
 \file{/var/lock}, nel filesystem standard). Per questo si usa la
 caratteristica della funzione \func{open} (illustrata in
-sez.~\ref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
+sez.~\ref{sec:file_open_close}) che prevede\footnote{questo è quanto dettato dallo
   standard POSIX.1, ciò non toglie che in alcune implementazioni questa
   tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si
   è comunque soggetti alla possibilità di una \itindex{race~condition}
@@ -3085,7 +3087,7 @@ cancella con \func{unlink}.
 \end{figure}
 
 Uno dei limiti di questa tecnica è che, come abbiamo già accennato in
-sez.~\ref{sec:file_open}, questo comportamento di \func{open} può non
+sez.~\ref{sec:file_open_close}, questo comportamento di \func{open} può non
 funzionare (la funzione viene eseguita, ma non è garantita l'atomicità
 dell'operazione) se il filesystem su cui si va ad operare è su NFS; in tal
 caso si può adottare una tecnica alternativa che prevede l'uso della
@@ -3419,7 +3421,7 @@ diversi.
 La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
 possono essere specificati per \param{oflag}, che deve essere specificato come
 maschera binaria; i valori possibili per i vari bit sono quelli visti in
-tab.~\ref{tab:file_open_flags} dei quali però \func{mq\_open} riconosce solo i
+sez.~\ref{sec:file_open_close} dei quali però \func{mq\_open} riconosce solo i
 seguenti:
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{O\_RDONLY}] Apre la coda solo per la ricezione di messaggi. Il
@@ -3849,7 +3851,7 @@ La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
 possono essere specificati per \param{oflag}, che deve essere specificato come
 maschera binaria comprendente almeno uno dei due valori \const{O\_RDONLY} e
 \const{O\_RDWR}; i valori possibili per i vari bit sono quelli visti in
-tab.~\ref{tab:file_open_flags} dei quali però \func{shm\_open} riconosce solo
+sez.~\ref{sec:file_open_close} dei quali però \func{shm\_open} riconosce solo
 i seguenti:
 \begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{O\_RDONLY}] Apre il file descriptor associato al segmento di
@@ -3871,7 +3873,7 @@ In caso di successo la funzione restituisce un file descriptor associato al
 segmento di memoria condiviso con le stesse modalità di
 \func{open}\footnote{in realtà, come accennato, \func{shm\_open} è un semplice
   wrapper per \func{open}, usare direttamente quest'ultima avrebbe lo stesso
-  effetto.}  viste in sez.~\ref{sec:file_open}; in particolare viene impostato
+  effetto.}  viste in sez.~\ref{sec:file_open_close}; in particolare viene 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 di dati, essi sono associati allo stesso
@@ -4037,7 +4039,7 @@ automaticamente un nome nella forma \texttt{sem.qualchenome}.\footnote{si ha
 L'argomento \param{oflag} è quello che controlla le modalità con cui opera la
 funzione, ed è passato come maschera binaria; i bit corrispondono a quelli
 utilizzati per l'analogo argomento di \func{open}, anche se dei possibili
-valori visti in sez.~\ref{sec:file_open} sono utilizzati soltanto
+valori visti in sez.~\ref{sec:file_open_close} sono utilizzati soltanto
 \const{O\_CREAT} e \const{O\_EXCL}.
 
 Se si usa \const{O\_CREAT} si richiede la creazione del semaforo qualora