X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=5fdc8a01ab4ab963508b821f071b9102d72a4743;hp=0c53338765e9b18bd0c8c3d3c39ce3d905416859;hb=25de957ddf731370bec1eb74b13cf35aa7886d1b;hpb=718a0a24b34dce09e40eafc33c02ae494d100181;ds=sidebyside

diff --git a/fileadv.tex b/fileadv.tex
index 0c53338..5fdc8a0 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -33,10 +33,11 @@ mappato in memoria.
 Abbiamo visto in \secref{sec:sig_gen_beha}, affrontando la suddivisione fra
 \textit{fast} e \textit{slow} system call, che in certi casi le funzioni di
 I/O possono bloccarsi indefinitamente.\footnote{si ricordi però che questo può
-  accadere solo per le pipe, i socket ed alcuni file di dispositivo; sui file
-  normali le funzioni di lettura e scrittura ritornano sempre subito.}  Ad
-esempio le operazioni di lettura possono bloccarsi quando non ci sono dati
-disponibili sul descrittore su cui si sta operando.
+  accadere solo per le pipe, i socket\index{socket} ed alcuni file di
+  dispositivo\index{file!di dispositivo}; sui file normali le funzioni di
+  lettura e scrittura ritornano sempre subito.}  Ad esempio le operazioni di
+lettura possono bloccarsi quando non ci sono dati disponibili sul descrittore
+su cui si sta operando.
 
 Questo comportamento causa uno dei problemi più comuni che ci si trova ad
 affrontare nelle operazioni di I/O, che è quello che si verifica quando si
@@ -44,7 +45,7 @@ devono eseguire operazioni che possono bloccarsi su pi
 mentre si è bloccati su uno di essi su di un'altro potrebbero essere presenti
 dei dati; così che nel migliore dei casi si avrebbe una lettura ritardata
 inutilmente, e nel peggiore si potrebbe addirittura arrivare ad un
-\textit{deadlock}.
+\textit{deadlock}\index{deadlock}.
 
 Abbiamo già accennato in \secref{sec:file_open} che è possibile prevenire
 questo tipo di comportamento aprendo un file in modalità
@@ -75,9 +76,9 @@ funzioni in grado di sospendere l'esecuzione di un processo in attesa che
 l'accesso diventi possibile.  Il primo ad introdurre questa modalità di
 operazione, chiamata usualmente \textit{I/O multiplexing}, è stato
 BSD,\footnote{la funzione è apparsa in BSD4.2 e standardizzata in BSD4.4, ma è
-  stata portata su tutti i sistemi che supportano i \textit{socket}, compreso
-  le varianti di System V.}  con la funzione \func{select}, il cui prototipo
-è:
+  stata portata su tutti i sistemi che supportano i
+  \textit{socket}\index{socket}, compreso le varianti di System V.}  con la
+funzione \func{select}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/time.h}
   \headdecl{sys/types.h}
@@ -388,13 +389,13 @@ in eccesso, e si dovr
 attivi.
 
 Benché la modalità di apertura asincrona di un file possa risultare utile in
-varie occasioni (in particolar modo con i socket e gli altri file per i quali
-le funzioni di I/O sono system call lente), essa è comunque limitata alla
-notifica della disponibilità del file descriptor per le operazioni di I/O, e
-non ad uno svolgimento asincrono delle medesime.  Lo standard POSIX.1b
-definisce anche una interfaccia apposita per l'I/O asincrono, che prevede un
-insieme di funzioni dedicate, completamente separate rispetto a quelle usate
-normalmente.
+varie occasioni (in particolar modo con i socket\index{socket} e gli altri
+file per i quali le funzioni di I/O sono system call lente), essa è comunque
+limitata alla notifica della disponibilità del file descriptor per le
+operazioni di I/O, e non ad uno svolgimento asincrono delle medesime.  Lo
+standard POSIX.1b definisce anche una interfaccia apposita per l'I/O
+asincrono, che prevede un insieme di funzioni dedicate, completamente separate
+rispetto a quelle usate normalmente.
 
 In generale questa interfaccia è completamente astratta e può essere
 implementata sia direttamente nel kernel, che in user space attraverso l'uso
@@ -1223,6 +1224,7 @@ mappatura in memoria non ha alcun effetto sulla stessa.
 \section{Il file locking}
 \label{sec:file_locking}
 
+\index{file!locking|(}
 In \secref{sec:file_sharing} abbiamo preso in esame le modalità in cui un
 sistema unix-like gestisce la condivisione dei file da parte di processi
 diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti
@@ -1267,7 +1269,7 @@ un opportuno protocollo.
 In generale si distinguono due tipologie di \textit{file lock}:\footnote{di
   seguito ci riferiremo sempre ai blocchi di accesso ai file con la
   nomenclatura inglese di \textit{file lock}, o più brevemente con
-  \textit{lock}, per evitare confuzioni linguistiche con il blocco di un
+  \textit{lock}, per evitare confusioni linguistiche con il blocco di un
   processo (cioè la condizione in cui il processo viene posto in stato di
   \textit{sleep}).} la prima è il cosiddetto \textit{shared lock}, detto anche
 \textit{read lock} in quanto serve a bloccare l'accesso in scrittura su un
@@ -1319,7 +1321,7 @@ delle varie possibilit
 
 Si tenga presente infine che il controllo di accesso è effettuato quando si
 apre un file, l'unico controllo residuo è che il tipo di lock che si vuole
-otternere deve essere compatibile con le modalità di apertura dello stesso (di
+ottenere deve essere compatibile con le modalità di apertura dello stesso (di
 lettura per un read lock e di scrittura per un write lock).
 
 %%  Si ricordi che
@@ -1390,16 +1392,16 @@ dell'implementazione del file locking in stile BSD in Linux; il punto
 fondamentale da capire è che un lock, qualunque sia l'interfaccia che si usa,
 anche se richiesto attraverso un file descriptor, agisce sempre su un file;
 perciò le informazioni relative agli eventuali \textit{file lock} sono
-mantenute a livello di inode,\footnote{in particolare, come accennato in
-  \figref{fig:file_flock_struct}, i \textit{file lock} sono mantenuti un una
-  \textit{linked list}\index{linked list} di strutture \var{file\_lock}. La
-  lista è referenziata dall'indirizzo di partenza mantenuto dal campo
-  \var{i\_flock} della struttura \var{inode} (per le definizioni esatte si
-  faccia riferimento al file \file{fs.h} nei sorgenti del kernel).  Un bit del
-  campo \var{fl\_flags} di specifica se si tratta di un lock in semantica BSD
-  (\const{FL\_FLOCK}) o POSIX (\const{FL\_POSIX}).} dato che questo è l'unico
-riferimento in comune che possono avere due processi diversi che aprono lo
-stesso file.
+mantenute a livello di inode\index{inode},\footnote{in particolare, come
+  accennato in \figref{fig:file_flock_struct}, i \textit{file lock} sono
+  mantenuti un una \textit{linked list}\index{linked list} di strutture
+  \var{file\_lock}. La lista è referenziata dall'indirizzo di partenza
+  mantenuto dal campo \var{i\_flock} della struttura \var{inode} (per le
+  definizioni esatte si faccia riferimento al file \file{fs.h} nei sorgenti
+  del kernel).  Un bit del campo \var{fl\_flags} di specifica se si tratta di
+  un lock in semantica BSD (\const{FL\_FLOCK}) o POSIX (\const{FL\_POSIX}).}
+dato che questo è l'unico riferimento in comune che possono avere due processi
+diversi che aprono lo stesso file.
 
 \begin{figure}[htb]
   \centering
@@ -1481,8 +1483,8 @@ essa viene usata solo secondo il prototipo:
     \item[\errcode{EDEADLK}] Si è richiesto un lock su una regione bloccata da
       un altro processo che è a sua volta in attesa dello sblocco di un lock
       mantenuto dal processo corrente; si avrebbe pertanto un
-      \textit{deadlock}. Non è garantito che il sistema riconosca sempre
-      questa situazione.
+      \textit{deadlock}\index{deadlock}. Non è garantito che il sistema
+      riconosca sempre questa situazione.
     \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale prima
       di poter acquisire un lock.
     \end{errlist}
@@ -1609,7 +1611,7 @@ stato effettivamente acquisito.
 
 \begin{figure}[htb]
   \centering \includegraphics[width=9cm]{img/file_lock_dead}
-  \caption{Schema di una situazione di \textit{deadlock}.}
+  \caption{Schema di una situazione di \textit{deadlock}\index{deadlock}.}
   \label{fig:file_flock_dead}
 \end{figure}
 
@@ -1624,8 +1626,8 @@ volta di ottenere un lock sulla regione A? Questa 
 porta ad un \textit{deadlock}\index{deadlock}, dato che a quel punto anche il
 processo 2 si bloccherebbe, e niente potrebbe sbloccare l'altro processo. Per
 questo motivo il kernel si incarica di rilevare situazioni di questo tipo, ed
-impedirle restituendo un errore di \errcode{EDEADLK} alla funzione che cerca di
-acquisire un lock che porterebbe ad un \textit{deadlock}.
+impedirle restituendo un errore di \errcode{EDEADLK} alla funzione che cerca
+di acquisire un lock che porterebbe ad un \textit{deadlock}.
 
 \begin{figure}[!bht]
   \centering \includegraphics[width=13cm]{img/file_posix_lock}
@@ -1647,9 +1649,9 @@ esso 
   \var{fl\_start} e \var{fl\_end}.  La struttura è comunque la stessa, solo
   che in questo caso nel campo \var{fl\_flags} è impostato il bit
   \const{FL\_POSIX} ed il campo \var{fl\_file} non viene usato.} il lock è
-sempre associato all'inode, solo che in questo caso la titolarità non viene
-identificata con il riferimento ad una voce nella file table, ma con il valore
-del \acr{pid} del processo.
+sempre associato all'inode\index{inode}, solo che in questo caso la titolarità
+non viene identificata con il riferimento ad una voce nella file table, ma con
+il valore del \acr{pid} del processo.
 
 Quando si richiede un lock il kernel effettua una scansione di tutti i lock
 presenti sul file\footnote{scandisce cioè la linked list delle strutture
@@ -1680,7 +1682,7 @@ lock relativi al file cui esso faceva riferimento, anche se questi fossero
 stati creati usando altri file descriptor che restano aperti.
 
 Dato che il controllo sull'accesso ai lock viene eseguito sulla base del
-\acr{pid} del processo, possiamo anche prendere in cosiderazione un'altro
+\acr{pid} del processo, possiamo anche prendere in considerazione un'altro
 degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
 richiedono dei lock su regioni che si sovrappongono fra loro all'interno
 stesso processo. Siccome il controllo, come nel caso della rimozione, si basa
@@ -1689,7 +1691,7 @@ avranno sempre successo.
 
 Nel caso della semantica BSD, essendo i lock relativi a tutto un file e non
 accumulandosi,\footnote{questa ultima caratteristica è vera in generale, se
-  cioè si richiede più volte lo stesso file lock, o più lock sula stessa
+  cioè si richiede più volte lo stesso file lock, o più lock sulla stessa
   sezione di file, le richieste non si cumulano e basta una sola richiesta di
   rilascio per cancellare il lock.}  la cosa non ha alcun effetto; la funzione
 ritorna con successo, senza che il kernel debba modificare la lista dei lock.
@@ -1899,7 +1901,7 @@ Failed lock: Resource temporarily unavailable
 \end{verbatim}%$
 \end{minipage}\vspace{1mm}
 \par\noindent
-come ci aspettimo questo non sarà consentito.
+come ci aspettiamo questo non sarà consentito.
 
 Il programma di norma esegue il tentativo di acquisire il lock in modalità non
 bloccante, se però usiamo l'opzione \cmd{-b} possiamo impostare la modalità
@@ -1914,7 +1916,7 @@ opzione:
 \end{minipage}\vspace{1mm}
 \par\noindent
 il primo comando acquisisce subito un read lock, e quindi non cambia nulla, ma
-se proviamo adesso a richidere un write lock che non potrà essere acquisito
+se proviamo adesso a richiedere un write lock che non potrà essere acquisito
 otterremo:
 
 \vspace{1mm}
@@ -2099,11 +2101,12 @@ lock\footnote{alcuni sistemi, come HP-UX, sono ancora pi
   comportamento non ha molto senso, dato che comunque qualunque accesso
   diretto al file è consentito.} in Linux è stata però fatta la scelta
 implementativa\footnote{per i dettagli si possono leggere le note relative
-  all'implementazione, mantenute insime ai sorgenti del kernel nel file
+  all'implementazione, mantenute insieme ai sorgenti del kernel nel file
   \file{Documentation/mandatory.txt}.}  di seguire questo comportamento
 soltanto quando si chiama \func{mmap} con l'opzione \const{MAP\_SHARED} (nel
 qual caso la funzione fallisce con il solito \errcode{EAGAIN}) che comporta la
 possibilità di modificare il file.
+\index{file!locking|)}