X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=09ff74b333fdba0fa749f6e27d1bd350a9ae9ef7;hp=fca22f02a1581a663fec2d7b75112657e9824a79;hb=5eaf11a5e3e4daaee677554b68f4ba3c92c67b84;hpb=fd86592a845b5f76ad43ba2374ca0b798ffca595

diff --git a/ipc.tex b/ipc.tex
index fca22f0..09ff74b 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -561,7 +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```\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per
+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.
 
@@ -2940,18 +2941,18 @@ modalit
 
 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ì
+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
+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
+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 dimensione totale, ecc.) che
+Nel nostro caso implementeremo un ``\textsl{monitor}'' di una directory: un
+processo si incaricherà di tenere sotto controllo alcuni parametri relativi ad
+una 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.
 
@@ -3025,12 +3026,13 @@ caratteristica della funzione \func{open} (illustrata in
 \secref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
   standard POSIX.1, ciò non toglie che in alcune implementazioni questa
   tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si
-  è comunque soggetti alla possibilità di una race condition.} che essa
-ritorni un errore quando usata con i flag di \const{O\_CREAT} e
-\const{O\_EXCL}. In tal modo la creazione di un \textsl{file di lock} può
-essere eseguita atomicamente, il processo che crea il file con successo si può
-considerare come titolare del lock (e della risorsa ad esso associata) mentre
-il rilascio si può eseguire con una chiamata ad \func{unlink}.
+  è comunque soggetti alla possibilità di una race   
+  condition\index{race condition}.} che essa ritorni un errore quando usata
+con i flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la creazione di
+un \textsl{file di lock} può essere eseguita atomicamente, il processo che
+crea il file con successo si può considerare come titolare del lock (e della
+risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata
+ad \func{unlink}.
 
 Un esempio dell'uso di questa funzione è mostrato dalle funzioni
 \func{LockFile} ed \func{UnlockFile} riportate in \figref{fig:ipc_file_lock}