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
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}
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}.}
projects / gapil.git / blobdiff