interfacia alla funzione fornita dalle \acr{glibc}, esistono in realtà due
versioni diverse della \textit{system call}, la prima versione,
\func{signalfd}, introdotta nel kernel 2.6.22 e disponibile con le
- \acr{glibc} 2.8 che non supporta l'argomento, ed una seconda versione, \func{signalfd4}, che prende
- argomenti aggiuntivi, introdotta con il kernel 2.6.27 che è quella che viene
- sempre usata a partire dalle \acr{glibc} 2.9.} il cui prototipo è:
+ \acr{glibc} 2.8 che non supporta l'argomento, ed una seconda versione,
+ \func{signalfd4}, che prende argomenti aggiuntivi, introdotta con il kernel
+ 2.6.27 che è quella che viene sempre usata a partire dalle \acr{glibc} 2.9.}
+il cui prototipo è:
\begin{prototype}{sys/signalfd.h}
{int signalfd(int fd, const sigset\_t *mask, int flags)}
senza generare errori.
L'argomento \param{flags} consente di impostare direttamente in fase di
-creazione due flag per il file descriptor analoghe a quelle che si possono
-impostare con \func{open}, evitando una impostazione successiva con
-\func{fcntl}.\footnote{questo è un argomento aggiuntivo, introdotto con la
- versione fornita a partire dal kernel 2.6.27, per kernel precedenti il
- valore deve essere nullo.}
+creazione due flag per il file descriptor analoghi a quelli che si possono
+impostare con una creazione ordinaria con \func{open}, evitando una
+impostazione successiva con \func{fcntl}.\footnote{questo è un argomento
+ aggiuntivo, introdotto con la versione fornita a partire dal kernel 2.6.27,
+ per kernel precedenti il valore deve essere nullo.}
\begin{table}[htb]
\centering
\hline
\end{tabular}
\caption{Valori dell'argomento \param{flags} per la funzione \func{signalfd}
- che consentono di impostare fl.}
+ che consentono di impostare i flag del file descriptor.}
\label{tab:signalfd_flags}
\end{table}
+L'interfaccia fornita da \func{signalfd} prevede che la ricezione dei segnali
+sia eseguita leggendo dal file descriptor restituito dalla funzione. La
+lettura fornisce nel buffer indicato come secondo argomento alla funzione
+\func{read} una o più strutture \struct{signalfd\_siginfo} a seconda della
+dimensione dello stesso e del numero di segnali pendenti. Pertanto il buffer
+deve essere almeno di dimensione pari a \code{sizeof(signalfd\_siginfo)}; se
+di dimensione maggiore potranno essere letti in unica soluzione
+
% TODO trattare qui eventfd signalfd e timerfd introdotte con il 2.6.22
% timerfd è stata tolta nel 2.6.23 e rifatta per bene nel 2.6.25
% vedi: http://lwn.net/Articles/233462/
kernel è lo stesso) le chiamate a \func{open} o \func{truncate} eseguite dal
\textit{lease breaker} rimaste bloccate proseguono automaticamente.
-
-\itindbeg{dnotify}
-
Benché possa risultare utile per sincronizzare l'accesso ad uno stesso file da
parte di più processi, l'uso dei \textit{file lease} non consente comunque di
risolvere il problema di rilevare automaticamente quando un file o una
-directory vengono modificati, che è quanto necessario ad esempio ai programma
-di gestione dei file dei vari desktop grafici.
+directory vengono modificati,\footnote{questa funzionalità venne aggiunta
+ principalmente ad uso di Samba per poter facilitare l'emulazione del
+ comportamento di Windows sui file, ma ad oggi viene considerata una
+ interfaccia mal progettata ed il suo uso è fortemente sconsigliato a favore
+ di \textit{inotify}.} che è quanto necessario ad esempio ai programma di
+gestione dei file dei vari desktop grafici.
+
+\itindbeg{dnotify}
Per risolvere questo problema a partire dal kernel 2.4 è stata allora creata
un'altra interfaccia,\footnote{si ricordi che anche questa è una interfaccia
comporta tutti i problemi di gestione visti in sez.~\ref{sec:sig_management} e
sez.~\ref{sec:sig_adv_control}. Per tutta questa serie di motivi in generale
quella di \textit{dnotify} viene considerata una interfaccia di usabilità
-problematica.
+problematica ed il suo uso oggi è fortemente sconsigliato.
\itindend{dnotify}