-presente inoltre che alla chiusura del descrittore (e quindi anche all'uscita
-del processo) ogni eventuale registrazione di notifica presente viene
-cancellata.
-
-La notifica avviene all'arrivo di un messaggio in una coda vuota (e non se ci
-sono messaggi sulla coda), in tal caso il segnale specificato da
-\code{notification->sigev\_signo} viene inviato al processo che si era
-registrato, e la coda diventa disponibile per una ulteriore registrazione. Si
-tenga presente però che la presenza di un processo bloccato in una chiamata a
-\func{mq\_receive} ha la precedenza sulla notifica; in tal caso infatti un
-enventuale messaggio viene immediatamente inviato a quest'ultimo, e per il
-meccanismo di notifica funziona tutto come se la coda fosse restata vuota.
-
-L'invio del segnale avvalora i campi seguenti campi di \struct{siginfo\_t} (la
-cui definizione è in \figref{fig:sig_siginfo_t}): \var{si\_pid} con il
-\acr{pid} del processo che ha emesso il segnale, \var{si\_uid} con l'userid
-effettivo, \var{si\_code} con \const{SI\_MESGQ}, e \var{si\_errno} a 0. Questo
-ci dice che, se si effettua la ricezione usando esclusivamente il meccanismo
-di notifica, è possibile ottenere le informazioni sul processo che ha inserito
-un messaggio usando un gestore per il segnale in forma estesa (si ricordi
-quanto già detto al proposito in \secref{sec:sig_sigaction} e
-\secref{sec:sig_real_time}).
+presente inoltre che alla chiusura del descrittore associato alla coda (e
+quindi anche all'uscita del processo) ogni eventuale registrazione di notifica
+presente viene cancellata.
+
+La notifica del segnale avviene all'arrivo di un messaggio in una coda vuota
+(cioè solo se sulla coda non ci sono messaggi) e se non c'è nessun processo
+bloccato in una chiamata a \func{mq\_receive}, in questo caso infatti il
+processo bloccato ha la precedenza ed il messaggio gli viene immediatamente
+inviato, mentre per il meccanismo di notifica tutto funziona come se la coda
+fosse rimasta vuota.
+
+Quando un messaggio arriva su una coda vuota al processo che si era registrato
+viene inviato il segnale specificato da \code{notification->sigev\_signo}, e
+la coda diventa disponibile per una ulteriore registrazione. Questo comporta
+che se si vuole mantenere il meccanismo di notifica occorre ripetere la
+registrazione chiamando nuovamente \func{mq\_notify} all'interno del gestore
+del segnale di notifica. A differenza della situazione simile che si aveva con
+i segnali non affidabili,\footnote{l'argomento è stato affrontato in
+ \ref{sec:sig_semantics}.} questa caratteristica non configura una
+race-condition perché l'invio di un segnale avviene solo se la coda è vuota;
+pertanto se si vuole evitare di correre il rischio di perdere eventuali
+ulteriori segnali inviati nel lasso di tempo che occorre per ripetere la
+richiesta di notifica basta avere cura di eseguire questa operazione prima di
+estrarre i messaggi presenti dalla coda.
+
+L'invio del segnale di notifica avvalora alcuni campi di informazione
+restituiti al gestore attraverso la struttura \struct{siginfo\_t} (definita in
+\figref{fig:sig_siginfo_t}). In particolare \var{si\_pid} viene impostato al
+valore del \acr{pid} del processo che ha emesso il segnale, \var{si\_uid}
+all'userid effettivo, \var{si\_code} a \const{SI\_MESGQ}, e \var{si\_errno} a
+0. Questo ci dice che, se si effettua la ricezione dei messaggi usando
+esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni
+sul processo che ha inserito un messaggio usando un gestore per il segnale in
+forma estesa\footnote{di nuovo si faccia riferimento a quanto detto al
+ proposito in \secref{sec:sig_sigaction} e \secref{sec:sig_real_time}.}