X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=97948406c5096d983169cc6ee0b67f6938ea4a4b;hp=027cbaa7d07c9ed74b879f02c22f80cd3ca66af2;hb=51ac65a077651bde52ce68d43aa61b158f5dbd3d;hpb=04a547df13e4c672d95e1060e1ada9ae2e1fcb2f

diff --git a/fileadv.tex b/fileadv.tex
index 027cbaa..9794840 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -237,7 +237,7 @@ diversi che aprono lo stesso file.
 
 In particolare, come accennato in fig.~\ref{fig:file_flock_struct}, i
 \textit{file lock} sono mantenuti in una \textit{linked list} di strutture
-\kstruct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
+\kstructd{file\_lock}. La lista è referenziata dall'indirizzo di partenza
 mantenuto dal campo \var{i\_flock} della struttura \kstruct{inode} (per le
 definizioni esatte si faccia riferimento al file \file{include/linux/fs.h} nei
 sorgenti del kernel).  Un bit del campo \var{fl\_flags} di specifica se si
@@ -481,7 +481,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}. In questo caso nella figura si sono
-evidenziati solo i campi di \kstruct{file\_lock} significativi per la
+evidenziati solo i campi di \kstructd{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 è comunque la
@@ -1041,7 +1041,7 @@ degli insiemi specificati (\param{readfds}, \param{writefds} e
 
 Per specificare quali file descriptor si intende selezionare la funzione usa
 un particolare oggetto, il \textit{file descriptor set}, identificato dal tipo
-\type{fd\_set}, che serve ad identificare un insieme di file descriptor, in
+\typed{fd\_set}, che serve ad identificare un insieme di file descriptor, in
 maniera analoga a come un \textit{signal set} (vedi sez.~\ref{sec:sig_sigset})
 identifica un insieme di segnali. Per la manipolazione di questi \textit{file
   descriptor set} si possono usare delle opportune macro di preprocessore:
@@ -1134,7 +1134,6 @@ riaperto. Lo standard non prevede niente al riguardo e non si deve dare per
 assunto nessuno dei due comportamenti se si vogliono scrivere programmi
 portabili.
 
-
 \itindend{file~descriptor~set}
 
 Una volta ritornata la funzione, si potrà controllare quali sono i file
@@ -1182,7 +1181,7 @@ Lo standard POSIX è rimasto a lungo senza primitive per l'\textit{I/O
   multiplexing}, introdotto solo con le ultime revisioni dello standard (POSIX
 1003.1g-2000 e POSIX 1003.1-2001). La scelta è stata quella di seguire
 l'interfaccia creata da BSD, ma prevede che tutte le funzioni ad esso relative
-vengano dichiarate nell'header \headfile{sys/select.h}, che sostituisce i
+vengano dichiarate nell'header \headfiled{sys/select.h}, che sostituisce i
 precedenti, ed inoltre aggiunge a \func{select} una nuova funzione
 \funcd{pselect},\footnote{il supporto per lo standard POSIX 1003.1-2001, ed
   l'header \headfile{sys/select.h}, compaiono in Linux a partire dalle
@@ -1285,7 +1284,7 @@ interfaccia completamente diversa, basata sulla funzione di sistema
   introdotta in Linux come \textit{system call} a partire dal kernel 2.1.23 ed
   inserita nelle \acr{libc} 5.4.28, originariamente l'argomento \param{nfds}
   era di tipo \ctyp{unsigned int}, la funzione è stata inserita nello standard
-  POSIX.1-2001 in cui è stato introdotto il tipo nativo \type{nfds\_t}.} il
+  POSIX.1-2001 in cui è stato introdotto il tipo nativo \typed{nfds\_t}.} il
 cui prototipo è:
 
 \begin{funcproto}{
@@ -1425,20 +1424,19 @@ solito tramite \var{errno}.
 L'uso di \func{poll} consente di superare alcuni dei problemi illustrati in
 precedenza per \func{select}; anzitutto, dato che in questo caso si usa un
 vettore di strutture \struct{pollfd} di dimensione arbitraria, non esiste il
-limite introdotto dalle dimensioni massime di un \itindex{file~descriptor~set}
-\textit{file descriptor set} e la dimensione dei dati passati al kernel
-dipende solo dal numero dei file descriptor che si vogliono controllare, non
-dal loro valore. Infatti, anche se usando dei bit un \textit{file descriptor
-  set} può essere più efficiente di un vettore di strutture \struct{pollfd},
-qualora si debba osservare un solo file descriptor con un valore molto alto ci
-si troverà ad utilizzare inutilmente un maggiore quantitativo di memoria.
-
-Inoltre con \func{select} lo stesso \itindex{file~descriptor~set} \textit{file
-  descriptor set} è usato sia in ingresso che in uscita, e questo significa
-che tutte le volte che si vuole ripetere l'operazione occorre reinizializzarlo
-da capo. Questa operazione, che può essere molto onerosa se i file descriptor
-da tenere sotto osservazione sono molti, non è invece necessaria con
-\func{poll}.
+limite introdotto dalle dimensioni massime di un \textit{file descriptor set}
+e la dimensione dei dati passati al kernel dipende solo dal numero dei file
+descriptor che si vogliono controllare, non dal loro valore. Infatti, anche se
+usando dei bit un \textit{file descriptor set} può essere più efficiente di un
+vettore di strutture \struct{pollfd}, qualora si debba osservare un solo file
+descriptor con un valore molto alto ci si troverà ad utilizzare inutilmente un
+maggiore quantitativo di memoria.
+
+Inoltre con \func{select} lo stesso \textit{file descriptor set} è usato sia
+in ingresso che in uscita, e questo significa che tutte le volte che si vuole
+ripetere l'operazione occorre reinizializzarlo da capo. Questa operazione, che
+può essere molto onerosa se i file descriptor da tenere sotto osservazione
+sono molti, non è invece necessaria con \func{poll}.
 
 Abbiamo visto in sez.~\ref{sec:file_select} come lo standard POSIX preveda una
 variante di \func{select} che consente di gestire correttamente la ricezione
@@ -1507,11 +1505,11 @@ Nonostante \func{poll} presenti alcuni vantaggi rispetto a \func{select},
 anche questa funzione non è molto efficiente quando deve essere utilizzata con
 un gran numero di file descriptor,\footnote{in casi del genere \func{select}
   viene scartata a priori, perché può avvenire che il numero di file
-  descriptor ecceda le dimensioni massime di un \itindex{file~descriptor~set}
-  \textit{file descriptor set}.} in particolare nel caso in cui solo pochi di
-questi diventano attivi. Il problema in questo caso è che il tempo impiegato
-da \func{poll} a trasferire i dati da e verso il kernel è proporzionale al
-numero di file descriptor osservati, non a quelli che presentano attività.
+  descriptor ecceda le dimensioni massime di un \textit{file descriptor set}.}
+in particolare nel caso in cui solo pochi di questi diventano attivi. Il
+problema in questo caso è che il tempo impiegato da \func{poll} a trasferire i
+dati da e verso il kernel è proporzionale al numero di file descriptor
+osservati, non a quelli che presentano attività.
 
 Quando ci sono decine di migliaia di file descriptor osservati e migliaia di
 eventi al secondo (il caso classico è quello di un server web di un sito con
@@ -1589,7 +1587,7 @@ i cui prototipi sono:
     positivo o non valido per \param{flags}.
   \item[\errcode{EMFILE}] si è raggiunto il limite sul numero massimo di
     istanze di \textit{epoll} per utente stabilito da
-    \sysctlfile{fs/epoll/max\_user\_instances}.
+    \sysctlfiled{fs/epoll/max\_user\_instances}.
   \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
     nel sistema.
   \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
@@ -1656,7 +1654,7 @@ dell'interfaccia, \funcd{epoll\_ctl}, il cui prototipo è:
     l'operazione richiesta.
   \item[\errcode{ENOSPC}] si è raggiunto il limite massimo di registrazioni
     per utente di file descriptor da osservare imposto da
-    \sysctlfile{fs/epoll/max\_user\_watches}.
+    \sysctlfiled{fs/epoll/max\_user\_watches}.
   \item[\errcode{EPERM}] il file associato a \param{fd} non supporta l'uso di
     \textit{epoll}.
   \end{errlist}
@@ -2594,7 +2592,7 @@ funzioni dell'I/O multiplexing viste in precedenza. Una volta che il file
 descriptor risulta pronto sarà possibile leggere il numero di volte che il
 timer è scaduto con una ordinaria \func{read}. 
 
-La funzione legge il valore in un dato di tipo \type{uint64\_t}, e necessita
+La funzione legge il valore in un dato di tipo \typed{uint64\_t}, e necessita
 pertanto che le si passi un buffer di almeno 8 byte, fallendo con
 \errval{EINVAL} in caso contrario, in sostanza la lettura deve essere
 effettuata con una istruzione del tipo:
@@ -2872,7 +2870,7 @@ operazione di lettura, declassando il \textit{lease} a lettura con
 
 Se il \textit{lease holder} non provvede a rilasciare il \textit{lease} entro
 il numero di secondi specificato dal parametro di sistema mantenuto in
-\sysctlfile{fs/lease-break-time} sarà il kernel stesso a rimuoverlo o
+\sysctlfiled{fs/lease-break-time} sarà il kernel stesso a rimuoverlo o
 declassarlo automaticamente (questa è una misura di sicurezza per evitare che
 un processo blocchi indefinitamente l'accesso ad un file acquisendo un
 \textit{lease}). Una volta che un \textit{lease} è stato rilasciato o
@@ -3022,7 +3020,7 @@ notificare gli eventi che sono stati posti in osservazione. Per evitare abusi
 delle risorse di sistema è previsto che un utente possa utilizzare un numero
 limitato di istanze di \textit{inotify}; il valore di default del limite è di
 128, ma questo valore può essere cambiato con \func{sysctl} o usando il file
-\sysctlfile{fs/inotify/max\_user\_instances}.
+\sysctlfiled{fs/inotify/max\_user\_instances}.
 
 Dato che questo file descriptor non è associato a nessun file o directory
 reale, l'inconveniente di non poter smontare un filesystem i cui file sono
@@ -3034,10 +3032,9 @@ stato smontato.
 Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà
 essere utilizzato come argomento per le funzioni \func{select} e \func{poll} e
 con l'interfaccia di \textit{epoll}, ed a partire dal kernel 2.6.25 è stato
-introdotto anche il supporto per il \itindex{signal~driven~I/O}
-\texttt{signal-driven I/O}.  Siccome gli eventi vengono notificati come dati
-disponibili in lettura, dette funzioni ritorneranno tutte le volte che si avrà
-un evento di notifica. 
+introdotto anche il supporto per il \texttt{signal-driven I/O}.  Siccome gli
+eventi vengono notificati come dati disponibili in lettura, dette funzioni
+ritorneranno tutte le volte che si avrà un evento di notifica.
 
 Così, invece di dover utilizzare i segnali, considerati una pessima scelta dal
 punto di vista dell'interfaccia utente, si potrà gestire l'osservazione degli
@@ -3085,7 +3082,7 @@ modalità della stessa.  L'operazione può essere ripetuta per tutti i file e le
 directory che si vogliono tenere sotto osservazione,\footnote{anche in questo
   caso c'è un limite massimo che di default è pari a 8192, ed anche questo
   valore può essere cambiato con \func{sysctl} o usando il file
-  \sysctlfile{fs/inotify/max\_user\_watches}.} e si utilizzerà sempre un solo
+  \sysctlfiled{fs/inotify/max\_user\_watches}.} e si utilizzerà sempre un solo
 file descriptor.
 
 Il tipo di evento che si vuole osservare deve essere specificato
@@ -3322,7 +3319,7 @@ registrazione dell'osservatore).
 
 \footnotetext{la coda di notifica ha una dimensione massima che viene
   controllata dal parametro di sistema
-  \sysctlfile{fs/inotify/max\_queued\_events}, che indica il numero massimo di
+  \sysctlfiled{fs/inotify/max\_queued\_events}, che indica il numero massimo di
   eventi che possono essere mantenuti sulla stessa; quando detto valore viene
   ecceduto gli ulteriori eventi vengono scartati, ma viene comunque generato
   un evento di tipo \const{IN\_Q\_OVERFLOW}.}
@@ -3517,7 +3514,7 @@ Lo standard POSIX prevede che tutte le operazioni di I/O asincrono siano
 controllate attraverso l'uso di una apposita struttura \struct{aiocb} (il cui
 nome sta per \textit{asyncronous I/O control block}), che viene passata come
 argomento a tutte le funzioni dell'interfaccia. La sua definizione, come
-effettuata in \headfile{aio.h}, è riportata in
+effettuata in \headfiled{aio.h}, è riportata in
 fig.~\ref{fig:file_aiocb}. Nello steso file è definita la macro
 \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la disponibilità
 dell'interfaccia per l'I/O asincrono.