X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=abb9aef11b7a026258ba4df5d189501f74168010;hp=bb175495677ccd7c52a83b7db0ac7eac36b3f00e;hb=0d526e9c3fd5ccb8a3ea860c578f20f48d89f2a4;hpb=a0fdff527cf9690c0d16c48182bda2865b79f501

diff --git a/ipc.tex b/ipc.tex
index bb17549..abb9aef 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -20,9 +20,12 @@ implementati con un ulteriore livello sopra i meccanismi elementari.
 \section{La comunicazione fra processi tradizionale}
 \label{sec:ipc_unix}
 
-Il primo meccanismo di comunicazione fra processi usato dai sistemi unix-like
-è quello delle \textit{pipe}, in questa sezione descriveremo le sue basi, le
-funzioni che ne gestiscono l'uso e le varie forme in cui si è evoluto.
+Il primo meccanismo di comunicazione fra processi usato dai sistemi unix-like,
+e quello che viene correntemente usato di più, è quello delle \textit{pipe},
+che sono una delle caratteristiche peculiari del sistema, in particolar modo
+dell'interfaccia a linea di comando. In questa sezione descriveremo le sue
+basi, le funzioni che ne gestiscono l'uso e le varie forme in cui si è
+evoluto.
 
 
 \subsection{Le \textit{pipe} standard}
@@ -37,12 +40,12 @@ due processi, nella forma di un \textsl{tubo} (da cui il nome) in cui uno dei
 processi immette dati che poi arriveranno all'altro.
 
 
-La funzione che permette di creare una \textit{pipe} è appunto \func{pipe}; il
-suo prototipo è:
+La funzione che permette di creare una pipe è appunto \func{pipe}; il suo
+prototipo è:
 \begin{prototype}{unistd.h}
 {int pipe(int filedes[2])} 
   
-Crea una coppia di file descriptor associati ad una \textit{pipe}.
+Crea una coppia di file descriptor associati ad una pipe.
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
     errore, nel qual caso \var{errno} potrà assumere i valori \macro{EMFILE},
@@ -51,37 +54,55 @@ Crea una coppia di file descriptor associati ad una \textit{pipe}.
 
 La funzione restituisce una coppia di file descriptor nell'array
 \param{filedes}; il primo aperto in lettura ed il secondo in scrittura. Il
-concetto di funzionamento di una \textit{pipe} è relativamente semplice,
-quello che si scrive nel file descriptor aperto in scrittura viene
-ripresentato tale e quale nel file descriptor aperto in lettura, da cui può
-essere riletto.
+concetto di funzionamento di una pipe è relativamente semplice, quello che si
+scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
+nel file descriptor aperto in lettura, da cui può essere riletto.
 
 I file descriptor infatti non sono connessi a nessun file reale, ma ad un
-buffer nel kernel (la cui dimensione è specificata dalla costante
-\macro{PIPE\_BUF}, vedi \secref{sec:sys_file_limits}), di modo che scrivendo
-in uno si può rileggere dall'altro.
+buffer nel kernel (la cui dimensione, vedi \secref{sec:sys_file_limits}, è
+specificata dalla costante \macro{PIPE\_BUF} illustrata in
+\figref{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 attaverso la pipe.
+
+\begin{figure}[htb]
+  \centering
+  \includegraphics[height=5cm]{img/pipe}
+  \caption{Schema della struttura di una pipe.}
+  \label{fig:ipc_pipe_singular}
+\end{figure}
 
 Chiaramente creare una pipe all'interno di un processo non serve a niente; se
 però ricordiamo quanto esposto in \secref{sec:file_sharing} 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, compresi quelli
-associati ad una pipe; in questo modo se uno dei processi scrive su un capo
-della pipe, l'altro può leggere. 
-
-Tutto ciò ci mosta come sia immediato realizzare un meccanismo di
-comunicazione fra processi attraverso una pipe utilizzando le ordinarie
+associati ad una pipe (secondo la situazione illustrata in
+\figref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
+capo della pipe, l'altro può leggere.
+
+\begin{figure}[htb]
+  \centering
+  \includegraphics[height=5cm]{img/pipefork}
+  \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
+  processo attraverso una \func{fork}.}
+  \label{fig:ipc_pipe_fork}
+\end{figure}
+
+Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
+comunicazione fra processi attraverso una pipe, utilizzando le ordinarie
 proprietà dei file, ma ci mostra anche qual'è il principale\footnote{Stevens
   riporta in APUE come limite anche il fatto che la comunicazione è
   unidirezionale, in realtà questo è un limite facilemente risolvibile usando
-  una coppia di \textit{pipe}.} limite nell'uso delle \textit{pipe}. È
-necessario infatti che i processi possano condividere i file descriptor della
-\textit{pipe}, e per questo essi devono comunque derivare da uno stesso
-processo padre che ha aperto la pipe, o, più comunemente, essere nella
-relazione padre/figlio.
-
-
+  una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
+processi possano condividere i file descriptor della pipe, e per questo essi
+devono comunque derivare da uno stesso processo padre che ha aperto la pipe,
+o, più comunemente, essere nella relazione padre/figlio.
 
+Per capire meglio il funzionamento di una pipe faremo un esempio di quello che
+è l'uso più comune, di una pipe, quello fatto dalla shell, che permette di
+inviare automaticamente l'output (usando lo standard output) di un programma
+sull'input di un'altro.
 
 
 
@@ -94,8 +115,6 @@ interne del kernel, sono stati introdotti dei nuovi oggetti, le \textit{fifo},
 che invece possono risiedere sul filesystem, e che i processi possono usare
 per le comunicazioni senza dovere per forza essere in relazione diretta. 
 
-
-
   
 \section{La comunicazione fra processi di System V}
 \label{sec:ipc_sysv}