From: Simone Piccardi <piccardi@gnulinux.it>
Date: Sun, 2 Jun 2002 20:35:42 +0000 (+0000)
Subject: si prosegue molto lentamente
X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=commitdiff_plain;h=9e911ba375f804da62b1874c5b38d96a0e1bd07d

si prosegue molto lentamente
---

diff --git a/ipc.tex b/ipc.tex
index 24ec8f4..1331c9c 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -36,13 +36,6 @@ ed un altro legge. Si viene cos
 due processi, nella forma di un \textsl{tubo} (da cui il nome) in cui uno dei
 processi immette dati che poi arriveranno all'altro.
 
-Perché questo accada però, e questo è 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}.} e limite nell'uso delle \textit{pipe}, è necessario che
-questi processi possano condividere il file descriptor della \textit{pipe};
-per questo essi devono comunque derivare da uno stesso processo padre, o, più
-comunemente, essere nella relazione padre/figlio.
 
 La funzione che permette di creare una \textit{pipe} è appunto \func{pipe}; il
 suo prototipo è:
@@ -57,7 +50,35 @@ Crea una coppia di file descriptor associati ad una \textit{pipe}.
 \end{prototype}
 
 La funzione restituisce una coppia di file descriptor nell'array
-\param{filedes}; il primo aperto in lettura ed il secondo in scrittura
+\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.
+
+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.
+
+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
+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.
 
 
 
@@ -72,7 +93,7 @@ per le comunicazioni senza dovere per forza essere in relazione diretta.
 
 
 
-
+  
 \section{La comunicazione fra processi di System V}
 \label{sec:ipc_sysv}
 
diff --git a/system.tex b/system.tex
index e2b9a4c..ced0465 100644
--- a/system.tex
+++ b/system.tex
@@ -392,7 +392,7 @@ riportate in \tabref{tab:sys_file_macro}.
     \hline                
     \macro{NAME\_MAX}&  14  & lunghezza in byte di un nome di file. \\
     \macro{PATH\_MAX}& 256  & lunghezza in byte di pathname.\\
-    \macro{PIPE\_BUF}& 512  & byte scrivibili atomicamente in una pipe\\
+    \macro{PIPE\_BUF}&4096  & byte scrivibili atomicamente in una pipe\\
     \macro{LINK\_MAX}   &8  & numero massimo di link a un file\\
     \macro{MAX\_CANON}&255  & spazio disponibile nella coda di input
                               canonica del terminale\\