From: Simone Piccardi <piccardi@gnulinux.it>
Date: Mon, 10 Jun 2002 20:43:40 +0000 (+0000)
Subject: Revisione
X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=21f7d0f48d68450dd105427b89df37b765616033;p=gapil.git

Revisione
---

diff --git a/ipc.tex b/ipc.tex
index abb9aef..b8c703a 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -9,7 +9,7 @@ diversi, come quelli tradizionali che coinvolgono \textit{pipe} e
 \textit{fifo} e i meccanismi di intercomunicazione di System V.
 
 Tralasceremo invece tutte le problematiche relative alla comunicazione
-attraverso la rete (e le relative interfacce) che saranno affrontate in gran
+attraverso la rete (e le relative interfacce) che saranno affrontate in
 dettaglio in un secondo tempo.  Non affronteremo invece meccanismi più
 complessi ed evoluti come le RPC (\textit{Remote Procedure Calls}) e CORBA
 (\textit{Common Object Request Brocker Architecture}) che in genere sono
@@ -59,11 +59,12 @@ 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, 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.
+buffer nel kernel, la cui dimensione è specificata dalla costante
+\macro{PIPE\_BUF}, (vedi \secref{sec:sys_file_limits}); lo schema di
+funzionamento di una pipe è illustrato 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
@@ -100,8 +101,8 @@ 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
+è il loro uso più comune, analogo a quello effettuato della shell, e che
+consiste nell'inviare l'output di un processo (usando lo standard output)
 sull'input di un'altro.
 
 
@@ -109,11 +110,14 @@ sull'input di un'altro.
 \subsection{Le \textit{pipe} con nome, o \textit{fifo}}
 \label{sec:ipc_named_pipe}
 
-Per poter superare il problema delle \textit{pipe} originali, che consentono
-la comunicazione solo fra processi correlati, passando attraverso strutture
-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. 
+Per poter superare il problema delle \textit{pipe}, illustrato in
+\secref{sec:ipc_pipes}, che ne consente l'uso solo fra procesi con un
+progenitore comune o nella relazione padre/figlio, lo standard POSIX.1
+definisce 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}