X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=4c063d3e984c95111afd1f27f411709f67c6f094;hp=8d6277219cf18fc53843330ba217156467d35854;hb=dcf2c2df897955ff3503a7c426025457ab456fd7;hpb=b3593007c4edd76ecbf7386967c1b25d27eed828 diff --git a/fileadv.tex b/fileadv.tex index 8d62772..4c063d3 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -244,14 +244,14 @@ possono avere due processi diversi che aprono lo stesso file. La richiesta di un \textit{file lock} prevede una scansione della lista per determinare se l'acquisizione è possibile, ed in caso positivo l'aggiunta di -un nuovo elemento.\footnote{cioè una nuova struttura \struct{file\_lock}.} +un nuovo elemento.\footnote{cioè una nuova struttura \kstruct{file\_lock}.} Nel caso dei blocchi creati con \func{flock} la semantica della funzione prevede che sia \func{dup} che \func{fork} non creino ulteriori istanze di un \textit{file lock} quanto piuttosto degli ulteriori riferimenti allo stesso. Questo viene realizzato dal kernel secondo lo schema di fig.~\ref{fig:file_flock_struct}, associando ad ogni nuovo \textit{file lock} un puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di - \struct{file\_lock}, e viene utilizzato solo per i \textit{file lock} creati + \kstruct{file\_lock}, e viene utilizzato solo per i \textit{file lock} creati con la semantica BSD.} alla voce nella \itindex{file~table} \textit{file table} da cui si è richiesto il blocco, che così ne identifica il titolare. @@ -460,7 +460,7 @@ sez.~\ref{sec:file_flock}) esaminiamo più in dettaglio come viene gestito dal kernel. Lo schema delle strutture utilizzate è riportato in fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si - sono evidenziati solo i campi di \struct{file\_lock} significativi per la + sono evidenziati solo i campi di \kstruct{file\_lock} significativi per la semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al \ids{PID} del processo in \var{fl\_pid}, la sezione di file che viene bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è @@ -481,7 +481,7 @@ voce nella \itindex{file~table} \textit{file table}, ma con il valore del Quando si richiede un \textit{file lock} il kernel effettua una scansione di tutti i blocchi presenti sul file\footnote{scandisce cioè la \itindex{linked~list} \textit{linked list} delle strutture - \struct{file\_lock}, scartando automaticamente quelle per cui + \kstruct{file\_lock}, scartando automaticamente quelle per cui \var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano ben separate.} per verificare se la regione richiesta non si sovrappone ad una già bloccata, in caso affermativo decide in base al tipo di blocco, in @@ -1935,7 +1935,7 @@ descriptor è \funcd{signalfd},\footnote{in realtà quella riportata è versioni diverse della \textit{system call}; una prima versione, \func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con le \acr{glibc} 2.8 che non supporta l'argomento \texttt{flags}, ed una seconda - versione, \func{signalfd4}, introdotta con il kernel 2.6.27 e che è quella + versione, \funcm{signalfd4}, introdotta con il kernel 2.6.27 e che è quella che viene sempre usata a partire dalle \acr{glibc} 2.9, che prende un argomento aggiuntivo \code{size\_t sizemask} che indica la dimensione della maschera dei segnali, il cui valore viene impostato automaticamente dalle @@ -4516,7 +4516,7 @@ maniera atomica a partire da un certa posizione sul file. Per questo motivo a partire dal kernel 2.6.30 sono state introdotte anche per l'\textsl{I/O vettorizzato} le analoghe delle funzioni \func{pread} e \func{pwrite} (vedi sez.~\ref{sec:file_read} e \ref{sec:file_write}); le due funzioni sono -\funcd{preadv} e \func{pwritev} ed i rispettivi prototipi sono:\footnote{le +\funcd{preadv} e \funcd{pwritev} ed i rispettivi prototipi sono:\footnote{le due funzioni sono analoghe alle omonime presenti in BSD; le \textit{system call} usate da Linux (introdotte a partire dalla versione 2.6.30) utilizzano degli argomenti diversi per problemi collegati al formato a 64 @@ -5028,7 +5028,7 @@ La funzione copia \param{len} byte del contenuto di una \textit{pipe} su di un'altra; \param{fd\_in} deve essere il capo in lettura della \textit{pipe} sorgente e \param{fd\_out} il capo in scrittura della \textit{pipe} destinazione; a differenza di quanto avviene con \func{read} i dati letti con -\func{tee} da \func{fd\_in} non vengono \textsl{consumati} e restano +\func{tee} da \param{fd\_in} non vengono \textsl{consumati} e restano disponibili sulla \textit{pipe} per una successiva lettura (di nuovo per il comportamento delle \textit{pipe} si veda sez.~\ref{sec:ipc_unix}). Al momento\footnote{quello della stesura di questo paragrafo, avvenuta il Gennaio