X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileunix.tex;h=bfaab858ad4566a48af8e5c4240b5eb3b2a17356;hp=1bae4dd1a392cb4148cb7e9b20698647c13b8d53;hb=2ba81410053202b58aec9ce40344794d1c131491;hpb=c49e97bdcba8e4da8578d5a048a5764a622aff1e

diff --git a/fileunix.tex b/fileunix.tex
index 1bae4dd..bfaab85 100644
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -304,7 +304,8 @@ descriptor con il valore pi
                          a 31 bit. \\
     \hline
     \hline  % modalità di operazione coi file
-    \const{O\_APPEND}  & Il file viene aperto in append mode. Prima di ciascuna
+    \const{O\_APPEND}  & Il file viene aperto in \itindex{append~mode}
+                         \textit{append mode}. Prima di ciascuna 
                          scrittura la posizione corrente viene sempre impostata
                          alla fine del file. Con NFS si può avere una
                          corruzione del file se più di un processo scrive allo
@@ -355,9 +356,10 @@ descriptor con il valore pi
   \label{tab:file_open_flags}
 \end{table}
 
-\footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed
-  il kernel deve simularla, ma questo comporta la possibilità di una race
-  condition, vedi sez.~\ref{sec:file_atomic}.}
+\footnotetext[4]{il problema è che NFS non supporta la scrittura in
+  \itindex{append~mode} \textit{append}, ed il kernel deve simularla, ma
+  questo comporta la possibilità di una \itindex{race~condition} \textit{race
+    condition}, vedi sez.~\ref{sec:file_atomic}.}
 
 \footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da
   una \func{read} con un valore nullo e non con un errore, questo introduce
@@ -493,9 +495,10 @@ positivo come numero di byte dall'inizio del file. Tutte le operazioni di
 lettura e scrittura avvengono a partire da questa posizione che viene
 automaticamente spostata in avanti del numero di byte letti o scritti.
 
-In genere (a meno di non avere richiesto la modalità \const{O\_APPEND}) questa
-posizione viene impostata a zero all'apertura del file. È possibile impostarla
-ad un valore qualsiasi con la funzione \funcd{lseek}, il cui prototipo è:
+In genere (a meno di non avere richiesto la modalità \itindex{append~mode}
+\const{O\_APPEND}) questa posizione viene impostata a zero all'apertura del
+file. È possibile impostarla ad un valore qualsiasi con la funzione
+\funcd{lseek}, il cui prototipo è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{unistd.h}
@@ -708,11 +711,11 @@ scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo 
 Come nel caso di \func{read} la funzione tenta di scrivere \param{count} byte
 a partire dalla posizione corrente nel file e sposta automaticamente la
 posizione in avanti del numero di byte scritti. Se il file è aperto in
-modalità \const{O\_APPEND} i dati vengono sempre scritti alla fine del file.
-Lo standard POSIX richiede che i dati scritti siano immediatamente disponibili
-ad una \func{read} chiamata dopo che la \func{write} che li ha scritti è
-ritornata; ma dati i meccanismi di caching non è detto che tutti i filesystem
-supportino questa capacità.
+modalità \itindex{append~mode} \const{O\_APPEND} i dati vengono sempre scritti
+alla fine del file.  Lo standard POSIX richiede che i dati scritti siano
+immediatamente disponibili ad una \func{read} chiamata dopo che la
+\func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching
+non è detto che tutti i filesystem supportino questa capacità.
 
 Se \param{count} è zero la funzione restituisce zero senza fare nient'altro.
 Per i file ordinari il numero di byte scritti è sempre uguale a quello
@@ -781,10 +784,11 @@ stesso file, in particolare occorre tenere presente che:
   scrittura eccede la dimensione corrente del file questo verrà esteso
   automaticamente con l'aggiornamento del campo \var{i\_size}
   nell'inode\index{inode}.
-\item se un file è in modalità \const{O\_APPEND} tutte le volte che viene
-  effettuata una scrittura la posizione corrente viene prima impostata alla
-  dimensione corrente del file letta dall'inode\index{inode}. Dopo la
-  scrittura il file viene automaticamente esteso.
+\item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
+  le volte che viene effettuata una scrittura la posizione corrente viene
+  prima impostata alla dimensione corrente del file letta
+  dall'inode\index{inode}. Dopo la scrittura il file viene automaticamente
+  esteso.
 \item l'effetto di \func{lseek} è solo quello di cambiare il campo
   \var{f\_pos} nella struttura \struct{file} della \textit{file table}, non
   c'è nessuna operazione sul file su disco. Quando la si usa per porsi alla
@@ -855,11 +859,12 @@ ma il nostro primo processo avr
 
 Il problema è che usare due system call in successione non è un'operazione
 atomica; il problema è stato risolto introducendo la modalità
-\const{O\_APPEND}. In questo caso infatti, come abbiamo descritto in
-precedenza, è il kernel che aggiorna automaticamente la posizione alla fine
-del file prima di effettuare la scrittura, e poi estende il file. Tutto questo
-avviene all'interno di una singola system call (la \func{write}) che non
-essendo interrompibile da un altro processo costituisce un'operazione atomica.
+\itindex{append~mode} \const{O\_APPEND}. In questo caso infatti, come abbiamo
+descritto in precedenza, è il kernel che aggiorna automaticamente la posizione
+alla fine del file prima di effettuare la scrittura, e poi estende il file.
+Tutto questo avviene all'interno di una singola system call (la \func{write})
+che non essendo interrompibile da un altro processo costituisce un'operazione
+atomica.
 
 Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole
 creare un \textsl{file di lock}\index{file!di lock}, bloccandosi se il file