X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=3b11014a81f591a6a8aa10241da17911ca8ba83a;hp=39d70ef981f267689d3804813963725a1f5091b8;hb=17e39705eccbaa9111592907195befd05dbbed2d;hpb=4d9f9d2efab74ce8580fddb05dbdbe754014cdea

diff --git a/signal.tex b/signal.tex
index 39d70ef..3b11014 100644
--- a/signal.tex
+++ b/signal.tex
@@ -1,3 +1,13 @@
+%% signal.tex
+%%
+%% Copyright (C) 2000-2002 Simone Piccardi.  Permission is granted to
+%% copy, distribute and/or modify this document under the terms of the GNU Free
+%% Documentation License, Version 1.1 or any later version published by the
+%% Free Software Foundation; with the Invariant Sections being "Prefazione",
+%% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
+%% license is included in the section entitled "GNU Free Documentation
+%% License".
+%%
 \chapter{I segnali}
 \label{cha:signals}
 
@@ -140,9 +150,9 @@ Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
 per tutto il tempo che passa fra la generazione del segnale e la sua consegna
 esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
-procedura viene effettuata dallo scheduler quando, riprendendo l'esecuzione
-del processo in questione, verifica la presenza del segnale nella
-\var{task\_struct} e mette in esecuzione il gestore.
+procedura viene effettuata dallo scheduler\index{scheduler} quando,
+riprendendo l'esecuzione del processo in questione, verifica la presenza del
+segnale nella \var{task\_struct} e mette in esecuzione il gestore.
 
 In questa semantica un processo ha la possibilità di bloccare la consegna dei
 segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
@@ -211,11 +221,12 @@ verr
 ignorarlo).
 
 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
-avviene non appena questo viene rimesso in esecuzione dallo scheduler che
-esegue l'azione specificata. Questo a meno che il segnale in questione non sia
-stato bloccato prima della notifica, nel qual caso l'invio non avviene ed il
-segnale resta \textsl{pendente} indefinitamente. Quando lo si sblocca il
-segnale \textsl{pendente} sarà subito notificato.
+avviene non appena questo viene rimesso in esecuzione dallo
+scheduler\index{scheduler} che esegue l'azione specificata. Questo a meno che
+il segnale in questione non sia stato bloccato prima della notifica, nel qual
+caso l'invio non avviene ed il segnale resta \textsl{pendente}
+indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
+notificato.
 
 Si ricordi però che se l'azione specificata per un segnale è quella di essere
 ignorato questo sarà scartato immediatamente al momento della sua generazione,
@@ -1009,7 +1020,7 @@ Una seconda funzione che pu
     errore, gli errori sono gli stessi di \func{kill}.}
 \end{prototype}
 e che permette di inviare un segnale a tutto un \textit{process group} (vedi
-\secref{sec:sess_xxx}).
+\secref{sec:sess_proc_group}).
 
 Solo l'amministratore può inviare un segnale ad un processo qualunque, in
 tutti gli altri casi l'userid reale o l'userid effettivo del processo
@@ -1347,11 +1358,11 @@ Chiaramente, anche se il tempo pu
 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
 specificato, ma prima che il processo possa tornare ad essere eseguito
-occorrerà almeno attendere il successivo giro di scheduler e cioè un tempo che
-a seconda dei casi può arrivare fino a 1/\macro{HZ}, (sempre che il sistema
-sia scarico ed il processa venga immediatamente rimesso in esecuzione); per
-questo motivo il valore restituito in \param{rem} è sempre arrotondato al
-multiplo successivo di 1/\macro{HZ}.
+occorrerà almeno attendere il successivo giro di scheduler\index{scheduler} e
+cioè un tempo che a seconda dei casi può arrivare fino a 1/\macro{HZ}, (sempre
+che il sistema sia scarico ed il processa venga immediatamente rimesso in
+esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
+arrotondato al multiplo successivo di 1/\macro{HZ}.
 
 In realtà è possibile ottenere anche pause più precise del centesimo di
 secondo usando politiche di scheduling real time come \macro{SCHED\_FIFO} o
@@ -1383,8 +1394,8 @@ zombie.
 
 In \figref{fig:sig_sigchld_handl} è mostrato il codice contenente una
 implementazione generica di una routine di gestione per \macro{SIGCHLD}, (che
-si trova nei sorgenti allegati nel file \file{HandSIGCHLD.c}); se ripetiamo i
-test di \secref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
+si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i test
+di \secref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
 \cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
 gestore di \macro{SIGCHLD}) potremo verificare che non si ha più la creazione
 di zombie.
@@ -1406,7 +1417,7 @@ di zombie.
 #include <sys/wait.h>
 #include "macro.h"
 
-void HandSIGCHLD(int sig)
+void HandSigCHLD(int sig)
 {
     int errno_save;
     int status;
@@ -1983,25 +1994,24 @@ inline SigFunc * Signal(int signo, SigFunc *func)
 Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
 che abbia le stesse caratteristiche di \func{signal}, a definire una funzione
 equivalente attraverso \func{sigaction}; la funzione è \code{Signal}, e si
-trova definita come \code{inline} nel file \file{wrapper.h} (nei sorgenti
-allegati), riportata in \figref{fig:sig_Signal_code}. La riutilizzeremo spesso
-in seguito. 
+trova definita nel file \file{SigHand.c} (nei sorgenti allegati), e riportata
+in \figref{fig:sig_Signal_code}. La riutilizzeremo spesso in seguito.
 
 \subsection{La gestione della \textsl{maschera dei segnali} o 
   \textit{signal mask}}
 \label{sec:sig_sigmask}
 
 Come spiegato in \secref{sec:sig_semantics} tutti i moderni sistemi unix-like
-permettono si bloccare temporaneamente (o di eliminare completamente, impostando
-\macro{SIG\_IGN} come azione) la consegna dei segnali ad un processo. Questo è
-fatto specificando la cosiddetta \textsl{maschera dei segnali} (o
-\textit{signal mask}) del processo\footnote{nel caso di Linux essa è mantenuta
-  dal campo \var{blocked} della \var{task\_struct} del processo.} cioè
-l'insieme dei segnali la cui consegna è bloccata. Abbiamo accennato in
-\secref{sec:proc_fork} che la \textit{signal mask} viene ereditata dal padre
-alla creazione di un processo figlio, e abbiamo visto al paragrafo precedente
-che essa può essere modificata, durante l'esecuzione di un gestore,
-attraverso l'uso dal campo \var{sa\_mask} di \var{sigaction}.
+permettono si bloccare temporaneamente (o di eliminare completamente,
+impostando \macro{SIG\_IGN} come azione) la consegna dei segnali ad un
+processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
+  segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux
+  essa è mantenuta dal campo \var{blocked} della \var{task\_struct} del
+  processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
+accennato in \secref{sec:proc_fork} che la \textit{signal mask} viene
+ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al
+paragrafo precedente che essa può essere modificata, durante l'esecuzione di
+un gestore, attraverso l'uso dal campo \var{sa\_mask} di \var{sigaction}.
 
 Uno dei problemi evidenziatisi con l'esempio di \secref{fig:sig_event_wrong} è
 che in molti casi è necessario proteggere delle sezioni di codice (nel caso in