Revisione fino a dup.
authorSimone Piccardi <piccardi@gnulinux.it>
Sun, 18 Nov 2018 22:57:29 +0000 (23:57 +0100)
committerSimone Piccardi <piccardi@gnulinux.it>
Sun, 18 Nov 2018 22:57:29 +0000 (23:57 +0100)
fileio.tex

index 9ab3f032b55c9ecaf9629c1e7187b09da3a558d0..053fd25308cef6833942ac4596d5e25beec7e85a 100644 (file)
@@ -1092,7 +1092,7 @@ il cui prototipo è:
 
 La funzione tenta di leggere \param{count} byte dal file \param{fd} a partire
 dalla posizione corrente, scrivendoli nel buffer \param{buf}.\footnote{fino ad
-  un massimo di \const{0x7ffff000} bytes, indipendentemente che l'architettura
+  un massimo di \const{0x7ffff000} byte, indipendentemente che l'architettura
   sia a 32 o 64 bit.} Dopo la lettura la posizione sul file è spostata
 automaticamente in avanti del numero di byte letti. Se \param{count} è zero la
 funzione restituisce zero senza nessun altro risultato. Inoltre che non è
@@ -1169,7 +1169,7 @@ funzione di sistema, \funcd{pread}, il cui prototipo è:
 La funzione prende esattamente gli stessi argomenti di \func{read} con lo
 stesso significato, a cui si aggiunge l'argomento \param{offset} che indica
 una posizione sul file a partire dalla quale verranno i \param{count}
-bytes. Identico è il comportamento ed il valore di ritorno, ma la posizione
+byte. Identico è il comportamento ed il valore di ritorno, ma la posizione
 corrente sul file resterà invariata.  Il valore di \param{offset} fa sempre
 riferimento all'inizio del file.
 
@@ -1189,7 +1189,7 @@ accessibile solo attivando il supporto delle estensioni previste dalle
 \textit{Single Unix Specification} con un valore della macro
 \macro{\_XOPEN\_SOURCE} maggiore o uguale a 500 o a partire dalla \acr{glibc}
 2.12 con un valore dalla macro \macro{\_POSIX\_C\_SOURCE} maggiore o uguale al
-varore \val{200809L}.  Si ricordi di definire queste macro prima
+valore \val{200809L}.  Si ricordi di definire queste macro prima
 dell'inclusione del file di dichiarazione \headfile{unistd.h}.
 
 
@@ -1302,8 +1302,8 @@ diversi.
   \label{fig:file_mult_acc}
 \end{figure}
 
-Il primo caso è quello in cui due processi diversi aprono lo stesso file su
-disco; sulla base di quanto visto in sez.~\ref{sec:file_fd} avremo una
+Il primo caso è quello in cui due processi indipendenti aprono lo stesso file
+su disco; sulla base di quanto visto in sez.~\ref{sec:file_fd} avremo una
 situazione come quella illustrata in fig.~\ref{fig:file_mult_acc}: ciascun
 processo avrà una sua voce nella \textit{file table} referenziata da un
 diverso file descriptor nella sua \kstruct{file\_struct}. Entrambe le voci
@@ -1342,7 +1342,7 @@ stesso file, in particolare occorre tenere presente che:
 \end{figure}
 
 Il secondo caso è quello in cui due file descriptor di due processi diversi
-puntino alla stessa voce nella \textit{file table}.  Questo è ad esempio il
+puntano alla stessa voce nella \textit{file table}.  Questo è ad esempio il
 caso dei file aperti che vengono ereditati dal processo figlio all'esecuzione
 di una \func{fork} (si ricordi quanto detto in sez.~\ref{sec:proc_fork}). La
 situazione è illustrata in fig.~\ref{fig:file_acc_child}; dato che il processo
@@ -1376,11 +1376,11 @@ caso di condivisione della stessa voce della \textit{file table}.
 Si tenga presente dunque che in un sistema unix-like è sempre possibile per
 più processi accedere in contemporanea allo stesso file e che non esistono, a
 differenza di altri sistemi operativi, dei meccanismi di blocco o di
-restrizione dell'accesso impliciti se più processi vogliono accedere allo
+restrizione dell'accesso impliciti quando più processi vogliono accedere allo
 stesso file. Questo significa che le operazioni di lettura e scrittura vengono
-sempre fatte da ogni processo in maniera autonoma, utilizzando una posizione
-corrente nel file che normalmente (a meno di non trovarsi nella situazione di
-fig.~\ref{fig:file_acc_child}) è locale a ciascuno di essi.
+sempre fatte da ogni processo in maniera indipendente, utilizzando una
+posizione corrente nel file che normalmente, a meno di non trovarsi nella
+situazione di fig.~\ref{fig:file_acc_child}, è locale a ciascuno di essi.
 
 Dal punto di vista della lettura dei dati questo comporta la possibilità di
 poter leggere dati non coerenti in caso di scrittura contemporanea da parte di
@@ -1395,12 +1395,13 @@ esamineremo in sez.~\ref{sec:file_locking}.
 Un caso tipico di necessità di accesso condiviso in scrittura è quello in cui
 vari processi devono scrivere alla fine di un file (ad esempio un file di
 log). Come accennato in sez.~\ref{sec:file_lseek} impostare la posizione alla
-fine del file e poi scrivere può condurre ad una \textit{race condition};
-infatti può succedere che un secondo processo scriva alla fine del file fra la
-\func{lseek} e la \func{write}. In questo caso, come abbiamo appena visto, il
-file sarà esteso, ma il primo processo, avrà una posizione corrente che aveva
-impostato con la \func{lseek} che non corrisponde più alla fine del file, e la
-sua successiva \func{write} sovrascriverà i dati del secondo processo.
+fine del file con \func{lseek} e poi scrivere con \func{write} può condurre ad
+una \textit{race condition}; infatti può succedere che un secondo processo
+scriva alla fine del file fra la \func{lseek} e la \func{write}. In questo
+caso, come abbiamo appena visto, il file sarà esteso, ma il primo processo,
+avrà una posizione corrente che aveva impostato con \func{lseek} che non
+corrisponde più alla fine del file, e la sua successiva \func{write}
+sovrascriverà i dati del secondo processo.
 
 Il problema deriva dal fatto che usare due \textit{system call} in successione
 non è mai un'operazione atomica dato che il kernel può interrompere
@@ -1419,9 +1420,9 @@ realizza un'operazione atomica.
 
 Abbiamo già visto in sez.~\ref{sec:file_shared_access} come un processo figlio
 condivida gli stessi file descriptor del padre; è possibile però ottenere un
-comportamento analogo all'interno di uno stesso processo \textit{duplicando}
-un file descriptor. Per far questo si usa la funzione di sistema \funcd{dup},
-il cui prototipo è:
+comportamento analogo all'interno di uno stesso processo con la cosiddetta
+\textit{duplicazione} di un file descriptor. Per far questo si usa la funzione
+di sistema \funcd{dup}, il cui prototipo è:
 
 \begin{funcproto}{
 \fhead{unistd.h}
@@ -1434,7 +1435,7 @@ il cui prototipo è:
   \begin{errlist}
   \item[\errcode{EBADF}] \param{oldfd} non è un file aperto.
   \item[\errcode{EMFILE}] si è raggiunto il numero massimo consentito di file
-    descriptor aperti.
+    descriptor aperti (vedi sez.~\ref{sec:sys_resource_limit}).
   \end{errlist}
 }  
 \end{funcproto}
@@ -1482,8 +1483,8 @@ standard che si vuole redirigere e poi aprire direttamente con \func{open} il
 file vi si vuole far corrispondere, invece di duplicare un file descriptor che
 si è già aperto. La risposta sta nel fatto che il file che si vuole redirigere
 non è detto sia un file regolare, ma potrebbe essere, come accennato, anche
-una \textit{fifo} o un socket, oppure potrebbe essere un file associato ad un file
-descriptor che si è ereditato già aperto (ad esempio attraverso un'altra
+una \textit{fifo} o un socket, oppure potrebbe essere un file associato ad un
+file descriptor che si è ereditato già aperto (ad esempio attraverso una
 \func{exec}) da un processo antenato del padre, del quale non si conosce il
 nome. Operando direttamente con i file descriptor \func{dup} consente di
 ignorare le origini del file descriptor che si duplica e funziona in maniera
@@ -4496,7 +4497,7 @@ con uno dei valori \const{FSETLOCKING\_INTERNAL} o
 %%% TeX-master: "gapil"
 %%% End: 
 
-% LocalWords:  nell' du vm Documentation Urlich Drepper futimesat times
+% LocalWords:  nell' du vm Documentation Urlich Drepper futimesat times l'I
 %  LocalWords:  futimens fs Tread all'I ll TMPFILE EDQUOT extN Minix UDF XFS
 %  LocalWords:  shmem Btrfs ubifs tmpfile fchmod fchown fsetxattr fchdir PF
-%  LocalWords:  fstatfs sull'
+%  LocalWords:  fstatfs sull' SIGTTIN EDESTADDRREQ datagram connect