From 565dcb356f097ee32f889ee9120ad165d431500e Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sun, 18 Nov 2018 23:57:29 +0100 Subject: [PATCH] Revisione fino a dup. --- fileio.tex | 49 +++++++++++++++++++++++++------------------------ 1 file changed, 25 insertions(+), 24 deletions(-) diff --git a/fileio.tex b/fileio.tex index 9ab3f03..053fd25 100644 --- a/fileio.tex +++ b/fileio.tex @@ -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 -- 2.30.2