X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=fileadv.tex;h=d145833fe2e18b8713086b23dda398f76e2aa501;hb=493b79dd7a2cb2ca0627fac0aa39f65c656c7ade;hp=8d6277219cf18fc53843330ba217156467d35854;hpb=b3593007c4edd76ecbf7386967c1b25d27eed828;p=gapil.git diff --git a/fileadv.tex b/fileadv.tex index 8d62772..d145833 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 @@ -835,7 +835,7 @@ bloccare completamente un server NFS richiedendo una lettura su un file su cui è attivo un blocco. Per questo motivo l'abilitazione del \textit{mandatory locking} è di norma disabilitata, e deve essere attivata filesystem per filesystem in fase di montaggio (specificando l'apposita opzione di -\func{mount} riportata in sez.~\ref{sec:sys_file_config}), o con l'opzione +\func{mount} riportata in sez.~\ref{sec:filesystem_mounting}), o con l'opzione \code{-o mand} per il comando omonimo). Si tenga presente inoltre che il \textit{mandatory locking} funziona solo @@ -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 @@ -2207,7 +2207,7 @@ ritorno della funzione \func{read} è negativo, uscendo dal programma In presenza di dati invece il programma proseguirà l'esecuzione stampando (\texttt{\small 19--20}) il nome del segnale ottenuto all'interno della -struttura \const{signalfd\_siginfo} letta in \var{siginf}\footnote{per la +struttura \struct{signalfd\_siginfo} letta in \var{siginf}\footnote{per la stampa si è usato il vettore \var{sig\_names} a ciascun elemento del quale corrisponde il nome del segnale avente il numero corrispondente, la cui definizione si è omessa dal codice di fig.~\ref{fig:fiforeporter_code_init} @@ -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