X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=0c6a4f218d7e376a0b205abb481384fd67eefafa;hp=c7f2c4ac14cb41424d78040deb1eaf58f116d89b;hb=39154797992fca1134da0f4456dfbe2f37d82269;hpb=96256b851638bcd0bae29eafa53a22b01815490d

diff --git a/ipc.tex b/ipc.tex
index c7f2c4a..0c6a4f2 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -561,9 +561,8 @@ Il secondo caso 
 processo alla volta (nel qual caso basta usare due fifo, una per leggere ed
 una per scrivere), le cose diventano invece molto più complesse quando si
 vuole effettuare una comunicazione fra il server ed un numero imprecisato di
-client; se il primo infatti può ricevere le richieste attraverso una fifo
-``nota'', per le risposte non si può fare altrettanto, dato che, per la
-struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
+client; se il primo infatti può ricevere le richieste attraverso una fifo```\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per
+la struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
 leggerli, quando i dati inviati sono destinati a loro.
 
 Per risolvere questo problema, si può usare un'architettura come quella
@@ -1922,7 +1921,7 @@ della risorsa; in generale per
 utilizzando il valore del contatore come indicatore del ``numero di risorse''
 ancora disponibili.
 
-Il sistema di comunicazione interprocesso di \textit{SysV IPC} prevede anche i
+Il sistema di comunicazione inter-processo di \textit{SysV IPC} prevede anche i
 semafori, ma gli oggetti utilizzati non sono semafori singoli, ma gruppi di
 semafori detti \textsl{insiemi} (o \textit{semaphore set}); la funzione che
 permette di creare o ottenere l'identificatore di un insieme di semafori è
@@ -2939,20 +2938,20 @@ sequenziale\footnote{come accennato in \secref{sec:ipc_sysv_mq} per la
   effettuata in forma di messaggio.} o quando non può avvenire secondo una
 modalità predefinita.
 
-Un esempio classico di uso della memoria condivisa è quello del ``monitor'',
-in cui essa viene per scambiare informazioni fra un processo ``server'' che vi
-scrive dei dati di interesse generale che ha ottenuto, e tutti i processi
-``client'' interessati agli stessi dati che così possono leggerli in maniera
-completamente asincrona.  Con questo schema di funzionamento da una parte si
-evita che ciascun processo ``client'' debbia compiere l'operazione,
-potenzialmente onerosa, di ricavare e trattare i dati, e dall'altra si evita
-al processo ``server'' di dover gestire l'invio a tutti i client di tutti i
-dati (non potendo il server sapere quali di essi servono effettivamente al
-singolo client).
+Un esempio classico di uso della memoria condivisa è quello del
+``\textit{monitor}'', in cui essa viene per scambiare informazioni fra un
+processo ``server'' che vi scrive dei dati di interesse generale che ha
+ottenuto, e tutti i processi ``client'' interessati agli stessi dati che così
+possono leggerli in maniera completamente asincrona.  Con questo schema di
+funzionamento da una parte si evita che ciascun processo ``client'' debba
+compiere l'operazione, potenzialmente onerosa, di ricavare e trattare i dati,
+e dall'altra si evita al processo ``server'' di dover gestire l'invio a tutti
+i client di tutti i dati (non potendo il server sapere quali di essi servono
+effettivamente al singolo client).
 
 Nel nostro caso implementeremo un ``monitor'' di una directory: un processo si
 incaricherà di tenere sotto controllo alcuni parametri relativi ad una
-directory (il numero dei file contenuti, la dimenzione totale, ecc.) che
+directory (il numero dei file contenuti, la dimensione totale, ecc.) che
 saranno salvati in un segmento di memoria condivisa cui altri processi
 potranno accedere per ricavare la parte di informazione che interessa.