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
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
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:
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
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
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}{
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
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
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
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}
ed è utile per riconoscere la chiusura di una connessione dall'altro capo di
un socket quando si lavora in modalità \textit{edge triggered}.}
-Il secondo campo, \var{data}, è una \direct{union} che serve a identificare il
+Il secondo campo, \var{data}, è una \dirct{union} che serve a identificare il
file descriptor a cui si intende fare riferimento, ed in astratto può
contenere un valore qualsiasi (specificabile in diverse forme) che ne permetta
una indicazione univoca. Il modo più comune di usarlo però è quello in cui si
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:
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
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
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
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
\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}.}
Infine due campi \var{name} e \var{len} sono utilizzati soltanto quando
l'evento è relativo ad un file presente in una directory posta sotto
osservazione, in tal caso essi contengono rispettivamente il nome del file
-(come \itindsub{pathname}{relativo} \textit{pathname} relativo alla directory
-osservata) e la relativa dimensione in byte. Il campo \var{name} viene sempre
-restituito come stringa terminata da NUL, con uno o più zeri di terminazione,
-a seconda di eventuali necessità di allineamento del risultato, ed il valore
-di \var{len} corrisponde al totale della dimensione di \var{name}, zeri
-aggiuntivi compresi. La stringa con il nome del file viene restituita nella
-lettura subito dopo la struttura \struct{inotify\_event}; questo significa che
-le dimensioni di ciascun evento di \textit{inotify} saranno pari a
-\code{sizeof(\struct{inotify\_event}) + len}.
+(come \textit{pathname} relativo alla directory osservata) e la relativa
+dimensione in byte. Il campo \var{name} viene sempre restituito come stringa
+terminata da NUL, con uno o più zeri di terminazione, a seconda di eventuali
+necessità di allineamento del risultato, ed il valore di \var{len} corrisponde
+al totale della dimensione di \var{name}, zeri aggiuntivi compresi. La stringa
+con il nome del file viene restituita nella lettura subito dopo la struttura
+\struct{inotify\_event}; questo significa che le dimensioni di ciascun evento
+di \textit{inotify} saranno pari a \code{sizeof(\struct{inotify\_event}) +
+ len}.
Vediamo allora un esempio dell'uso dell'interfaccia di \textit{inotify} con un
semplice programma che permette di mettere sotto osservazione uno o più file e
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.
projects / gapil.git / blobdiff