From: Simone Piccardi Date: Sun, 25 Nov 2001 16:40:32 +0000 (+0000) Subject: Completata prima parte della bufferizzazione X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=commitdiff_plain;h=c6c424a264a13da8680542f137b665ddf5e136a6;ds=sidebyside Completata prima parte della bufferizzazione --- diff --git a/filestd.tex b/filestd.tex index 43cc123..b761d99 100644 --- a/filestd.tex +++ b/filestd.tex @@ -12,46 +12,50 @@ dell'interfaccia nell'ultima sezione. \label{sec:file_stream_intro} Come visto in \capref{cap:file_unix_interface} le operazioni di I/O sui file -sono gestibili direttamente a basso livello con l'interfaccia standard unix -che ricorre direttamente alle system call messe a disposizione dal kernel. +sono gestibili a basso livello con l'interfaccia standard unix, che ricorre +direttamente alle system call messe a disposizione dal kernel. Questa interfaccia però non provvede le funzionalità previste dallo standard -ANSI C che invece sono realizzate attraverso opportune funzioni di libreria, -che vengono a costituire il nucleo essenziale\footnote{queste funzioni sono - state implementate la prima volta da Ritchie nel 1976 e da allora sono - rimaste sostanzialmente immutate.} delle \acr{glibc}. +ANSI C, che invece sono realizzate attraverso opportune funzioni di libreria, +queste, insieme alle altre funzioni definite dallo standard, vengono a +costituire il nucleo\footnote{queste funzioni sono state implementate la prima + volta da Ritchie nel 1976 e da allora sono rimaste sostanzialmente + immutate.} delle \acr{glibc}. \subsection{I \textit{file stream}} \label{sec:file_stream} Come più volte ribadito l'interfaccia dei file descriptor è una interfaccia di -basso livello, che non provvede nessuna forma di formattazione dei dati, e +basso livello, che non provvede nessuna forma di formattazione dei dati e nessuna forma di bufferizzazione per ottimizzare le operazioni di I/O. -In \textit{Advanced Programming in the Unix Environment} Stevens esegue un -raffronto dell'influenza delle dimensioni del blocco di dati (il parametro +In \textit{Advanced Programming in the Unix Environment} Stevens descrive una +serie di test sull'influenza delle dimensioni del blocco di dati (il parametro \param{buf} di \func{read} e \func{write}) nell'efficienza nelle operazioni di I/O con i file descriptor, evidenziando come le prestazioni ottimali si -ottengano quando il buffer dei dati ha la stessa dimensione dei blocchi del -filesystem (il valore dato dal campo \var{st\_blksize} di \var{fstat}). +ottengano a partire da dimensioni del buffer dei dati pari a quelle dei +blocchi del filesystem (il valore dato dal campo \var{st\_blksize} di +\var{fstat}). -In questo caso se il programmatore non si cura di effettuare le operazioni in -blocchi di dimensioni adeguate, le prestazioni possono deteriorarsi in maniera -evidente. L'interfaccia degli stream provvede da sola la gestione dei dettagli -della bufferizzazione e dell'esecuzione delle operazioni di lettura e -scrittura effettive in blocchi di dimensioni appropriate all'ottenimento della -massima efficienza. +Se il programmatore non si cura di effettuare le operazioni in blocchi di +dimensioni adeguate, le prestazioni sono inferiori. La caratteristica +principale dell'interfaccia degli stream è che essa provvede da sola alla +gestione dei dettagli della bufferizzazione e all'esecuzione delle operazioni +di lettura e scrittura in blocchi di dimensioni appropriate all'ottenimento +della massima efficienza. Per questo motivo l'interfaccia viene chiamata anche interfaccia dei -\textit{file stream}, dato che non è più necessario doversi preoccupare di -gestire i dettagli della comunicazione con il tipo di hardware sottostante, ed -esso può essere sempre considerato come composto da un flusso (da cui il nome -\textit{stream}) continuo di dati. - -Ma a parte le particolarità della gestione delle operazioni di lettura e -scrittura, i file stream restano del tutto equivalenti ai file descriptor sui -quali sono basati, ed in particolare vale quanto visto in +\textit{file stream}, dato che non è più necessario doversi preoccupare di dei +dettagli della comunicazione con il tipo di hardware sottostante (come nel +caso della dimensione dei blocchi del filesystem), ed un file può essere +sempre considerato come composto da un flusso continuo (da cui il nome +\textit{stream}) di dati. + +A parte i dettagli legati alla gestione delle operazioni di lettura e +scrittura (sia per quel che riguarda la bufferizzazione, che le +formattazioni), i file stream restano del tutto equivalenti ai file descriptor +(sui quali sono basati), ed in particolare continua a valere quanto visto in \secref{sec:file_sharing} a proposito dell'accesso condiviso ed in \secref{sec:file_access_control} per il controllo di accesso. @@ -59,7 +63,7 @@ quali sono basati, ed in particolare vale quanto visto in \subsection{Gli oggetti \type{FILE}} \label{sec:file_FILE} -Per ragioni storiche la struttura di dati che rappresenta un stream è stata +Per ragioni storiche la struttura di dati che rappresenta uno stream è stata chiamata \type{FILE}, questi oggetti sono creati dalle funzioni di libreria e contengono tutte le informazioni necessarie a gestire le operazioni sugli stream, come la posizione corrente, lo stato del buffer e degli indicatori di @@ -80,9 +84,10 @@ file \file{stdio.h}. \label{sec:file_std_stream} Ai tre file descriptor standard (vedi \secref{sec:file_std_descr}) aperti per -ogni processo, corrispondono altrettanti stream predefiniti per ogni processo, -che rappresentano i canali standard di input/output prestabiliti; anche questi -tre stream sono definiti nell'header \file{stdio.h} e sono: +ogni processo, corrispondono altrettanti stream, che rappresentano i canali +standard di input/output prestabiliti; anche questi tre stream sono +idetificabili attraverso dei nomi simbolici definiti nell'header +\file{stdio.h} che sono: \begin{itemize} \item \var{FILE * stdin} Lo \textit{standard input} cioè lo stream da cui @@ -97,14 +102,16 @@ tre stream sono definiti nell'header \file{stdio.h} e sono: \end{itemize} Nelle \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono effettivamente -tre variabili che possono essere usate come tutte le altre, ad esempio si può -effettuare una redirezione dell'output di un programma con il semplice codice: +tre variabili di tipo \type{FILE *} che possono essere usate come tutte le +altre, ad esempio si può effettuare una redirezione dell'output di un +programma con il semplice codice: \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{} fclose (stdout); stdout = fopen ("standard-output-file", "w"); \end{lstlisting} -ma in altri sistemi possono essere definite come macro, e deve essere pertanto -usata \func{freopen}. +ma in altri sistemi possono essere definite come macro, se si hanno problemi +di portabilità e si vuole essere sicuri, diventa opportuno usare la funzione +\func{freopen}. \subsection{Le modalità di bufferizzazione} @@ -114,56 +121,74 @@ La bufferizzazione degli stream; lo scopo è quello di ridurre al minimo il numero di system call (\func{read} o \func{write}) eseguite nelle operazioni di input/output. Questa funzionalità è assicurata automaticamente dalla libreria, ma costituisce anche -una degli aspetti più comunemente fraintesi. - -I caratteri che vengono scritti su uno stream normalmente vengono accumulati e -poi trasmessi in blocco in maniera asincrona (quello che viene chiamato il -\textit{flush} dei dati) quando il buffer è pieno, questo tipo di -comportamento vale anche per la lettura (cioè dal file viene letto un blocco -di dati, anche se se ne sono richiesti una quantità inferiore). - -Se si sta facendo dell'input/output interattivo però bisogna tenere presente -le caratteristiche con cui viene effettuata la bufferizzazione, pena il -rischio di non vedere apparire l'output o di ottenere degli effetti -indesiderati nella visualizzazione. - -Per questo motivo, la libreria definisce tre distinte modalità di -bufferizzazione, adatte a situazioni diverse, di cui occorre essere ben -consapevoli: +una degli aspetti più comunemente fraintesi, in particolare per quello che +riguarda l'aspetto della scrittura dei dati sul file. + +I caratteri che vengono scritti su uno stream normalmente vengono accumulati +in un buffer e poi trasmessi in blocco in maniera asincrona rispetto alla +scrittura (quello che viene chiamato il \textit{flush} dei dati) tutte le +volte che il buffer viene riempito. Un comportamento analogo avviene anche in +lettura (cioè dal file viene letto un blocco di dati, anche se se ne sono +richiesti una quantità inferiore), ma la cosa ovviamente ha rilevanza +inferiore, dato che i dati letti sono sempre gli stessi; in caso di scrittura +invece, quando si ha un accesso contemporaneo allo stesso file (ad esempio da +parte di un altro processo) si potranno vedere solo le parti effettivamente +scritte, e non quelle ancora presenti nel buffer. + +Allo stesso modo, se si sta facendo dell'input/output interattivo bisognerà +tenere presente le caratteristiche delle operazioni di \textit{flush} dei +dati, poiché non è detto che ad una scrittura sullo stream corrisponda una +immediata scrittura sul dispositivo. + +Per risondere ad esigenze diverse, lo standard definisce tre distinte modalità +in cui può essere eseguita la bufferizzazione, delle quali occorre essere ben +consapevoli, specie in caso di lettura e scrittura da dispositivi interattivi: \begin{itemize} -\item \textit{unbuffered}: in questa modalità i caratteri non sono - bufferizzati e vengono trasmessi individualmente al file non appena - possibile (effettuando immediatamente una \func{write}). -\item \textit{line buffered}: in questo caso i caratteri vengono trasmessi - al file in blocco ogni volta che viene incontrato un carattere di +\item \textit{unbuffered}: in questo caso non c'è bufferizzazione ed i + caratteri vengono trasmessi direttamente al file non appena possibile + (effettuando immediatamente una \func{write}). +\item \textit{line buffered}: in questo caso i caratteri vengono normalmente + trasmessi al file in blocco ogni volta che viene incontrato un carattere di \textit{newline} (il carattere ASCII \verb|\n|). \item \textit{fully buffered}: in questo caso i caratteri vengono trasmessi da e verso il file in blocchi di dimensione opportuna. \end{itemize} -Lo standard ANSI C specifica soltanto che lo standard output e lo standard +Lo standard ANSI C specifica inoltre che lo standard output e lo standard input siano aperti in modalità \textit{fully buffered} quando non fanno riferimento ad un dispositivo interattivo, e che lo standard error non sia mai aperto in modalità \textit{fully buffered}. -Linux, come BSD e SVr4, specifica il comportamento di default in maniera più -precisa, e cioè impone che lo standard error sia sempre \textit{unbuffered} -(in modo che i messaggi di errore siano mostrati il più rapidamente possibile) -e che standard input e standard output siano aperti in modalità \textit{line - buffered} quando sono associati ad un terminale (od altro dispositivo -interattivo) ed in modalità \textit{fully buffered} altrimenti. +Linux, come BSD e SVr4, specifica il comportamento di default in maniera +ancora più precisa, e cioè impone che lo standard error sia sempre +\textit{unbuffered} (in modo che i messaggi di errore siano mostrati il più +rapidamente possibile) e che standard input e standard output siano aperti in +modalità \textit{line buffered} quando sono associati ad un terminale (od +altro dispositivo interattivo) ed in modalità \textit{fully buffered} +altrimenti. Il comportamento specificato per standard input e standard output vale anche per tutti i nuovi stream aperti da un processo; la selezione comunque avviene automaticamente, e la libreria apre lo stream nella modalità più opportuna a -seconda file o al dispositivo scelto. +seconda del file o del dispositivo scelto. -La modalità \textit{line buffered} è quella passibile di maggiori -fraintendimenti, la descrizione che se ne è data infatti non è precisa, dato -che le dimensioni del buffer di I/O sono fisse e se le si eccedono può essere -effettuato un \textit{flush} dei dati anche prima che si sia inviato un -carattere di \textit{newline}. +La modalità \textit{line buffered} è quella che necessita di maggiori +chiarimenti e attenzioni per quel che concerne il suo funzionamento. Come già +accennato nella descrizione, \emph{di norma} i dati vengono inviati al kernel +alla ricezione di un carattere di a capo; questo non è vero in tutti i casi, +infatti, dato che le dimensioni del buffer usato dalle librerie sono fisse, se +le si eccedono si può avere un \textit{flush} dei dati anche prima che sia +stato inviato un carattere di \textit{newline}. +Un secondo punto da tenere presente, particolarmente quando si ha a che fare +con I/O interattivo, è che quando si effettua una lettura su uno stream che +comporta l'accesso al kernel\footnote{questo vuol dire sempre se lo stream da + cui si legge è in modalità \textit{unbuffered}} viene anche eseguito il +\textit{flush} di tutti i buffer degli stream in scrittura. + +In \secref{sec:file_buffering_ctrl} vedremo come la libreria definisca delle +opportune funzioni per controllare le modalità di bufferizzazione ed il +\textit{flush} dei dati. @@ -175,8 +200,7 @@ analoghe a quelle di \secref{sec:file_base_func} per i file descriptor. In particolare vedremo come aprire, leggere, scrivere e cambiare la posizione corrente in uno stream. - -\subsection{Apertura di uno stream} +\subsection{Apertura e chiusura di uno stream} \label{sec:file_fopen} @@ -209,7 +233,11 @@ corrente in uno stream. \subsection{Il controllo della bufferizzazione} -\label{sec:file_buffering-ctrl} +\label{sec:file_buffering_ctrl} + +Come accennato in \secref{sec:file_buffering} le librerie definiscono una +serie di funzioni che permettono di controllare il comportamento degli +stream; se non si è \subsection{Dettagli dell'implementazione}