From: Simone Piccardi <piccardi@gnulinux.it>
Date: Thu, 30 Dec 2010 11:06:36 +0000 (+0000)
Subject: Qualche nota sparsa e appunti sul da fare.
X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=6da397ead5f7048133f833a45b3799666ddb3f0a;p=gapil.git

Qualche nota sparsa e appunti sul da fare.
---

diff --git a/fileadv.tex b/fileadv.tex
index c350bbc..8ae83cf 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -1961,13 +1961,13 @@ impostazione successiva con \func{fcntl}.\footnote{questo 
   \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
@@ -2241,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
@@ -2338,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}
 
diff --git a/ipc.tex b/ipc.tex
index ee901ad..8cb04d0 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -3714,6 +3714,9 @@ si pu
 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
@@ -4307,7 +4310,7 @@ Qualora il semaforo debba essere condiviso dai \itindex{thread}
 \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
@@ -4325,9 +4328,8 @@ utilizzare nello stesso modo dei semafori normali con \func{sem\_wait} e
 \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}