Correzioni sul mandatory locking

diff --git a/fileadv.tex b/fileadv.tex
index 454e5952eed60696c60055c516744b7537349d63..5ef95b01caa30217522f1f8bda0ada27457d1374 100644 (file)
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -1937,9 +1937,9 @@ Lock acquired
 \end{minipage}\vspace{1mm}
 \par\noindent
 che ci mostra come i due tipi di lock siano assolutamente indipendenti; per
-questo motivo occorre sempre tenere presente quale delle due semantiche
-disponibili stanno usando i programmi con cui si interagisce, dato che
-applicare dei lock usando l'altra non avrebbe nessun effetto.
+questo motivo occorre sempre tenere presente quale fra le due semantiche
+disponibili stanno usando i programmi con cui si interagisce, dato che i lock
+applicati con l'altra non avrebbero nessun effetto.
 
 
 
@@ -1947,10 +1947,10 @@ applicare dei lock usando l'altra non avrebbe nessun effetto.
 \label{sec:file_lockf}
 
 Abbiamo visto come l'interfaccia POSIX per il file locking sia molto più
-potente e flessibile di quella di BSD, ma è anche molto più complicata da
-usare per le varie opzioni da passare a \func{fcntl}. Per questo motivo è
-disponibile anche una interfaccia semplificata (ripresa da System V) che
-utilizza la funzione \func{lockf}, il cui prototipo è:
+potente e flessibile di quella di BSD, questo comporta anche una maggiore
+complessità per via delle varie opzioni da passare a \func{fcntl}. Per questo
+motivo è disponibile anche una interfaccia semplificata (ripresa da System V)
+che utilizza la funzione \func{lockf}, il cui prototipo è:
 \begin{prototype}{sys/file.h}{int lockf(int fd, int cmd, off\_t len)}
   
   Applica, controlla o rimuove un \textit{file lock} sul file \param{fd}.
@@ -2040,9 +2040,9 @@ per filesystem in fase di montaggio (specificando l'apposita opzione di
 \func{mount} riportata in \tabref{tab:sys_mount_flags}, o con l'opzione
 \cmd{mand} per il comando).
 
-Si tenga presente inoltre che il \textit{mandatory locking} funziona
-sull'interfaccia POSIX di \func{fcntl}, questo significa che non ha nessun
-effetto sui lock richiesti con l'interfaccia di \func{flock}, ed inoltre che
+Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
+sull'interfaccia POSIX di \func{fcntl}. Questo ha due conseguenze: che non si
+ha nessun effetto sui lock richiesti con l'interfaccia di \func{flock}, e che
 la granularità del lock è quella del singolo byte, come per \func{fcntl}.
 
 La sintassi di acquisizione dei lock è esattamente la stessa vista in
@@ -2074,17 +2074,19 @@ lock (le prime due sempre, la terza solo nel caso che la riduzione delle
 dimensioni del file vada a sovrapporsi ad una regione bloccata).
 
 L'ultimo aspetto della interazione del \textit{mandatory locking} con le
-funzioni di accesso ai file è quello relativo ai file mappati in memoria
-appena trattati in \secref{sec:file_memory_map}; anche in tal caso infatti,
+funzioni di accesso ai file è quello relativo ai file mappati in memoria (che
+abbiamo trattato in \secref{sec:file_memory_map}); anche in tal caso infatti,
 quando si esegue la mappatura con l'opzione \macro{MAP\_SHARED}, si ha un
 accesso al contenuto del file. Lo standard SVID prevede che sia impossibile
 eseguire il memory mapping di un file su cui sono presenti dei
 lock\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
   impediscono anche in caso di \textit{advisory locking}, anche se questo non
-  ha molto senso.} in Linux è stata però fatta la scelta implementativa di
-seguire questo comportamento soltanto quando si chiama \func{mmap} con
-l'opzione \macro{MAP\_SHARED} (nel qual caso la funzione fallisce con il
-solito \macro{EAGAIN}). 
+  ha molto senso.} in Linux è stata però fatta la scelta
+implementativa\footnote{per i dettagli si possono leggere le note nel kernel,
+  mantenute nel file \file{Documentation/mandatory.txt}.} di seguire questo
+comportamento soltanto quando si chiama \func{mmap} con l'opzione
+\macro{MAP\_SHARED} (nel qual caso la funzione fallisce con il solito
+\macro{EAGAIN}).