\label{tab:signalfd_flags}
\end{table}
-L'interfacci fornita da \func{signalfd} prevede che la ricezione dei segnali
+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
+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
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}
dell'uso della stessa struttura per l'invio dei segnali usati per l'I/O
asincrono.
+% TODO la notifica non è più limitata al solo uso dei segnali, adesso si
+% possono anche usare i thread, correggere!.
+
Attraverso questa struttura si possono impostare le modalità con cui viene
effettuata la notifica; in particolare il campo \var{sigev\_notify} deve
essere posto a \const{SIGEV\_SIGNAL}\footnote{il meccanismo di notifica basato
\textit{thread-shared semaphore}), occorrerà che \param{sem} sia l'indirizzo
di una variabile visibile da tutti i \itindex{thread} \textit{thread}, si
dovrà usare cioè una variabile globale o una variabile allocata dinamicamente
-nello \itindex{heap} heap.
+nello \itindex{heap} \textit{heap}.
Qualora il semaforo debba essere condiviso fra più processi (nel qual caso si
parla di \textit{process-shared semaphore}) la sola scelta possibile per
\func{sem\_post}. Si tenga presente però che inizializzare due volte lo stesso
semaforo può dar luogo ad un comportamento indefinito.
-
Una volta che non si intenda più utilizzare un semaforo anonimo questo può
-essere eliminato da sistema; per far questo di deve utilizzare una apposita
+essere eliminato dal sistema; per far questo di deve utilizzare una apposita
funzione, \funcd{sem\_destroy}, il cui prototipo è:
\begin{functions}
\headdecl{semaphore.h}