Correzioni

diff --git a/ipc.tex b/ipc.tex
index cd9c68fed1b9596b3bf07e68eb041f09b5aa82df..bdbdf2c13d9068e85617b49f2ff16cc321cf416e 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -110,6 +110,13 @@ processo ricever
 restituirà un errore di \macro{EPIPE} (al ritorno del manipolatore, o qualora
 il segnale sia ignorato o bloccato).
 
 restituirà un errore di \macro{EPIPE} (al ritorno del manipolatore, o qualora
 il segnale sia ignorato o bloccato).
 

+La dimensione del buffer della pipe (\macro{PIPE\_BUF}) ci dà inoltre un'altra
+importante informazione riguardo il comportamento delle operazioni di lettura
+e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
+quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
+si effettui una scrittura di una quantità di dati superiore l'operazione verrà
+effettuata in più riprese, consentendo l'intromissione di scritture effettuate
+da altri processi.

 
 
 \subsection{Un esempio dell'uso delle pipe}
 
 
 \subsection{Un esempio dell'uso delle pipe}


@@ -158,7 +165,7 @@ intermedio su un file temporaneo. Questo per
 \textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
 evidente race condition in caso di accesso simultaneo a detto
 file.\footnote{il problema potrebbe essere superato determinando in anticipo
 \textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
 evidente race condition in caso di accesso simultaneo a detto
 file.\footnote{il problema potrebbe essere superato determinando in anticipo

-  un nome appropiato per il file temporaneo, che verrebbe utilizzato dai vari
+  un nome appropriato per il file temporaneo, che verrebbe utilizzato dai vari

   sotto-processi, e cancellato alla fine della loro esecuzione; ma a questo le
   cose non sarebbero più tanto semplici.}  L'uso di una pipe invece permette
 di risolvere il problema in maniera semplice ed elegante.
   sotto-processi, e cancellato alla fine della loro esecuzione; ma a questo le
   cose non sarebbero più tanto semplici.}  L'uso di una pipe invece permette
 di risolvere il problema in maniera semplice ed elegante.


@@ -295,7 +302,7 @@ capo in scrittura della seconda pipe, e attende la conclusione del figlio
 (\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
 conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
 necessaria, infatti, se non venisse chiusa, \cmd{gs}, che legge il suo
 (\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
 conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
 necessaria, infatti, se non venisse chiusa, \cmd{gs}, che legge il suo

-stardard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati
+standard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati

 in ingresso (l'unico modo che un programma ha per sapere che l'input è
 terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
 non ritornerebbe.
 in ingresso (l'unico modo che un programma ha per sapere che l'input è
 terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
 non ritornerebbe.


@@ -342,7 +349,7 @@ funzioni, \func{pclose}, il cui prototipo 
 \begin{prototype}{stdio.h}
 {int pclose(FILE *stream)}
 
 \begin{prototype}{stdio.h}
 {int pclose(FILE *stream)}
 

-Chiude il file \param{stream}, restituito da una prededente \func{popen}
+Chiude il file \param{stream}, restituito da una precedente \func{popen}

 attendendo la terminazione del processo ad essa associato.
   
 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
 attendendo la terminazione del processo ad essa associato.
   
 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di


@@ -402,7 +409,7 @@ programmi 
 effettivamente eseguiti. Questo non comporta nessun problema dato che la
 lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
 per primo, si bloccherà in attesa di ricevere sullo standard input il
 effettivamente eseguiti. Questo non comporta nessun problema dato che la
 lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
 per primo, si bloccherà in attesa di ricevere sullo standard input il

-risultato dell'elaborazione del precendente, benchè quest'ultimo venga
+risultato dell'elaborazione del precedente, benchè quest'ultimo venga

 invocato dopo.
 
 \begin{figure}[!htb]
 invocato dopo.
 
 \begin{figure}[!htb]


@@ -494,7 +501,7 @@ processo non avr
 scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
 leggere, nel secondo al capo di ingresso, e dovrà scrivere.
 
 scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
 leggere, nel secondo al capo di ingresso, e dovrà scrivere.
 

-Il kernel crea una sigola pipe per ciascuna fifo che sia stata aperta, che può
+Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può

 essere acceduta contemporaneamente da più processi, sia in lettura che in
 scrittura. Dato che per funzionare deve essere aperta in entrambe le
 direzioni, per una fifo di norma la funzione \func{open} si blocca se viene
 essere acceduta contemporaneamente da più processi, sia in lettura che in
 scrittura. Dato che per funzionare deve essere aperta in entrambe le
 direzioni, per una fifo di norma la funzione \func{open} si blocca se viene


@@ -507,8 +514,8 @@ l'errore di \macro{ENXIO} fintanto che non verr
 
 In Linux\footnote{lo standard POSIX lascia indefinito questo comportamento.} è
 possibile aprire le fifo anche in lettura/scrittura, operazione che avrà
 
 In Linux\footnote{lo standard POSIX lascia indefinito questo comportamento.} è
 possibile aprire le fifo anche in lettura/scrittura, operazione che avrà

-sempre successo qualunque sia la modalità di apertura (bloccante e non
-bloccante); questo può essere utilizzato per aprire comunque una fifo in
+sempre successo immediato qualunque sia la modalità di apertura (bloccante e
+non bloccante); questo può essere utilizzato per aprire comunque una fifo in

 scrittura anche se non ci sono ancora processi il lettura; è possibile anche
 usare la fifo all'interno di un solo processo, nel qual caso però occorre
 stare molto attenti alla possibili deadlock.\footnote{se si cerca di leggere
 scrittura anche se non ci sono ancora processi il lettura; è possibile anche
 usare la fifo all'interno di un solo processo, nel qual caso però occorre
 stare molto attenti alla possibili deadlock.\footnote{se si cerca di leggere


@@ -521,30 +528,35 @@ stare molto attenti alla possibili deadlock.\footnote{se si cerca di leggere
 \section{La comunicazione fra processi di System V}
 \label{sec:ipc_sysv}
 
 \section{La comunicazione fra processi di System V}
 \label{sec:ipc_sysv}
 

-Per ovviare ai vari limiti dei meccanismo tradizionale di comunicazione fra
-processi visto in \secref{sec:ipc_unix}, nello sviluppo di System V vennero
-introdotti una serie di nuovi oggetti e relative interfacce che garantissero
-una maggiore flessibilità; in questa sezione esamineremo quello che viene
-ormai chiamato il \textit{System V Inter-Process Comunication System}, più
-comunemente noto come \textit{SystemV IPC}.
+Benché le pipe (e le fifo) siano ancora ampiamente usate, esse presentano
+numerosi limiti, il principale dei quali è che il meccanismo di comunicazione
+è rigidamente sequenziale; una situazione in cui un processo scrive qualcosa
+che molti altri devono poter leggere non può essere implementata con una pipe.
+
+Per superarne i vari limiti, nello sviluppo di System V vennero introdotti una
+serie di nuovi oggetti di comunicazione e relative interfacce id
+programmazione che garantissero una maggiore flessibilità; in questa sezione
+esamineremo quello che viene ormai chiamato il \textsl{Sistema di
+  comunicazione inter-processo} di System V , più comunemente noto come
+\textit{System V IPC (Inter-Process Comunication)}.

  
 
 \subsection{Code di messaggi}
 \label{sec:ipc_messque}
 
  
 
 \subsection{Code di messaggi}
 \label{sec:ipc_messque}
 

-Il primo oggetto introdotto dal \textit{SystemV IPC} è quello delle code di
+Il primo oggetto introdotto dal \textit{System V IPC} è quello delle code di

 messaggi.
 
 \subsection{Semafori}
 \label{sec:ipc_semaph}
 
 messaggi.
 
 \subsection{Semafori}
 \label{sec:ipc_semaph}
 

-Il secondo oggetto introdotto dal \textit{SystemV IPC} è quello dei semafori.
+Il secondo oggetto introdotto dal \textit{System V IPC} è quello dei semafori.

 
 
 \subsection{Memoria condivisa}
 \label{sec:ipc_shar_mem}
 
 
 
 \subsection{Memoria condivisa}
 \label{sec:ipc_shar_mem}
 

-Il terzo oggetto introdotto dal \textit{SystemV IPC} è quello della memoria
+Il terzo oggetto introdotto dal \textit{System V IPC} è quello della memoria

 condivisa.
 
 %%% Local Variables: 
 condivisa.
 
 %%% Local Variables: