X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=8ae83cf88f7cebab584f00818169b8ed69cc378a;hp=77e058e920ae77b2a6e90f00277af8ab6219cb30;hb=5d621249af8897e27fc0a842a33e7a7ef3b9c2ca;hpb=c23786b2033224de5b188ddcf1180e35ed9eb5af

diff --git a/fileadv.tex b/fileadv.tex
index 77e058e..8ae83cf 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -1884,9 +1884,14 @@ contemporanea sia l'arrivo del segnale che la disponibilit
 relativi a questi ultimi.
 
 La funzione che permette di abilitare la ricezione dei segnali tramite file
-descriptor è \funcd{signalfd},\footnote{in realtà questa è il nome della
-  funzione fornita dalle \acr{glibc},  esistono in realtà due
-  versioni, anche se } il cui prototipo è:
+descriptor è \funcd{signalfd},\footnote{in realtà quella riportata è la
+  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 è:
 \begin{prototype}{sys/signalfd.h} 
   {int signalfd(int fd, const sigset\_t *mask, int flags)}
 
@@ -1911,29 +1916,30 @@ descriptor 
 
 La funzione consente di creare o modificare le caratteristiche di un file
 descriptor speciale su cui ricevere le notifiche della ricezione di
-segnali. Per creare un nuovo file descriptor è necessario passare $-1$ come
-valore per l'argomento \param{fd}, ogni altro valore positivo verrà invece
-interpretato come il numero del file descriptor (che deve esser stato
+segnali. Per creare ex-novo uno di questi file descriptor è necessario passare
+$-1$ come valore per l'argomento \param{fd}, ogni altro valore positivo verrà
+invece interpretato come il numero del file descriptor (che deve esser stato
 precedentemente creato sempre con \func{signalfd}) di cui si vogliono
-modificare le caratteristiche. Nel primo caso la funzione ritornerà il nuovo
-file descriptor e nel secondo caso \param{fd}, in caso di errore verrà invece
-restituito $-1$.
+modificare le caratteristiche. Nel primo caso la funzione ritornerà il valore
+del nuovo file descriptor e nel secondo caso il valore indicato
+con \param{fd}, in caso di errore invece verrà restituito $-1$.
 
 L'elenco dei segnali che si vogliono gestire con \func{signalfd} deve essere
 specificato tramite l'argomento \param{mask}. Questo deve essere passato come
-puntatore ad una maschera di segnali creata con l'uso delle apposite macro
-illustrate in sez.~\ref{sec:sig_sigset} che indichi su quali segnali si
-intende operare con \func{signalfd}, l'elenco può essere modificato da una
-chiamata successiva. Dato che \const{SIGKILL} e \const{SIGSTOP} non possono
-essere intercettati (e non prevedono neanche la possibilità di un gestore) un
-loro inserimento nella maschera verrà semplicemente ignorato, senza generare
-errori.
-
-Infine 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 il
-  kernel 2.6.27, in precedenza il valore era nullo } 
+puntatore ad una maschera di segnali creata con l'uso delle apposite macro già
+illustrate in sez.~\ref{sec:sig_sigset}; la maschera deve indicare su quali
+segnali si intende operare con \func{signalfd}; l'elenco può essere modificato
+con una successiva chiamata a \func{signalfd}. Dato che \const{SIGKILL} e
+\const{SIGSTOP} non possono essere intercettati (e non prevedono neanche la
+possibilità di un gestore) un loro inserimento nella maschera verrà ignorato,
+senza generare errori.
+
+L'argomento \param{flags} consente di impostare direttamente in fase di
+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
@@ -1951,10 +1957,18 @@ impostare con \func{open}, evitando una impostazione successiva con
     \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/
@@ -2227,14 +2241,17 @@ rilasciato o declassato (che questo sia fatto dal \textit{lease holder} o dal
 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
@@ -2324,7 +2341,7 @@ numero di file).  Infine l'uso dei segnali come interfaccia di notifica
 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}