Prima parte delle correzioni mandate da Fabio Rossi: etc. -> ecc. ed il
authorSimone Piccardi <piccardi@gnulinux.it>
Wed, 23 Mar 2005 00:02:07 +0000 (00:02 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Wed, 23 Mar 2005 00:02:07 +0000 (00:02 +0000)
capitolo sui segnali.

ChangeLog
filedir.tex
filestd.tex
intro.tex
macro.tex
netlayer.tex
network.tex
preambolo.tex
process.tex
prochand.tex
signal.tex

index db8860b73c64030e1e0d909bd079abe6f331a057..72ef1d6710b07a87c9edb0ce4ceed2f4a01efad8 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2005-03-23  Simone Piccardi  <piccardi@gont.earthsea.ea>
+
+       * signal.tex: Altra serie di correzioni da Fabio Rossi.
+
 2005-3-14  Simone Piccardi,,,  <piccardi@gont.earthsea.ea>
 
        * correzioni multiple da Fabio Rossi.
index 88a4112d3b8e1117d6d8f7f7ab5c9599249e550c..ff2d330c979d92432ec27f8853a9ad2374e98181 100644 (file)
@@ -1948,7 +1948,7 @@ di accesso sono i seguenti:
   \begin{itemize*}
   \item se il relativo\footnote{per relativo si intende il bit di user-read se
       il processo vuole accedere in scrittura, quello di user-write per
-      l'accesso in scrittura, etc.} bit dei permessi d'accesso dell'utente è
+      l'accesso in scrittura, ecc.} bit dei permessi d'accesso dell'utente è
     impostato, l'accesso è consentito
   \item altrimenti l'accesso è negato
   \end{itemize*}
index aeeb9a02770ec4792f5ff805d0f4746ed3b9e3df..4526eb060e876555a25d3b878ad9470d86636332 100644 (file)
@@ -1192,7 +1192,7 @@ questo argomento 
 sono varie differenze.  Le funzioni di input infatti sono più orientate verso
 la lettura di testo libero che verso un input formattato in campi fissi. Uno
 spazio in \param{format} corrisponde con un numero qualunque di caratteri di
-separazione (che possono essere spazi, tabulatori, virgole etc.), mentre
+separazione (che possono essere spazi, tabulatori, virgole ecc.), mentre
 caratteri diversi richiedono una corrispondenza esatta. Le direttive di
 conversione sono analoghe a quelle di \func{printf} e si trovano descritte in
 dettaglio nelle pagine di manuale e nel manuale delle \acr{glibc}.
index 9e473ed5b65aa7868a21b2a80a0f6ce5f69d5083..18e7282f5848d16c6ddf98f37d8a512b3059458d 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -250,7 +250,7 @@ Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto
 \textit{default group}), ma può essere associato ad altri gruppi (i
 \textit{supplementary group}), questo permette di gestire i permessi di
 accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
-definendo gruppi di lavoro, di accesso a determinate risorse, etc.
+definendo gruppi di lavoro, di accesso a determinate risorse, ecc.
 
 L'utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad
 un nome espresso in caratteri è inserita nei due file \file{/etc/passwd} e
index 8ad1d49d8a8cc37620043b715fd712db27033346..c8f3296eac6235bad2c585c890222772d8a2d889 100644 (file)
--- a/macro.tex
+++ b/macro.tex
 \index{#1@{{\tt {#1}} (struttura dati)}!definizione di}\texttt{#1}%
 }                                     % struttura dati
 \newcommand{\param}[1]{\texttt{#1}}   % function parameter
-\newcommand{\acr}[1]{\textsl{#1}}     % acrostic (for pid, suid, etc.)
+\newcommand{\acr}[1]{\textsl{#1}}     % acrostic (for pid, suid, ecc.)
 
 
 % Aggiunte di Mirko per la gestione delle tabelle complicate come immagini
index db190ee01c17290fbfebebcee0b37c915ea4bf44..3f002637a43be64daadc9787b21e38b7230c3e25 100644 (file)
@@ -36,7 +36,7 @@ dall'\href{http://www.ietf.org/rfc/rfc719.txt}{RFC~719}; esso nasce per
 disaccoppiare le applicazioni della struttura hardware delle reti di
 trasmissione, e creare una interfaccia di trasmissione dei dati indipendente
 dal sottostante substrato di rete, che può essere realizzato con le tecnologie
-più disparate (Ethernet, Token Ring, FDDI, etc.).
+più disparate (Ethernet, Token Ring, FDDI, ecc.).
 
 
 \subsection{Introduzione}
@@ -216,7 +216,7 @@ dall'\href{http://www.ietf.org/rfc/rfc719.txt}{RFC~719}; esso nasce per
 disaccoppiare le applicazioni della struttura hardware delle reti di
 trasmissione, e creare una interfaccia di trasmissione dei dati indipendente
 dal sottostante substrato di rete, che può essere realizzato con le tecnologie
-più disparate (Ethernet, Token Ring, FDDI, etc.).
+più disparate (Ethernet, Token Ring, FDDI, ecc.).
 
 
 \subsection{I motivi della transizione}
index 86bdeabeb426f664a019a42a14b93f1c65b93449..273c8da05ed91af248bfb73fd16ec8d8507d57e1 100644 (file)
@@ -255,7 +255,7 @@ sez.~\ref{sec:intro_unix_struct}.\footnote{in realt
     \hline
     \hline
     Livello 4&\textit{Application} &\textsl{Applicazione}& 
-    Telnet, FTP, etc. \\ 
+    Telnet, FTP, ecc. \\ 
     Livello 3&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\ 
     Livello 2&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP)  \\ 
     Livello 1&\textit{Link} &\textsl{Collegamento}& 
@@ -442,7 +442,7 @@ seguenti:
   orientato alla connessione che provvede un trasporto affidabile per un
   flusso di dati bidirezionale fra due stazioni remote. Il protocollo ha cura
   di tutti gli aspetti del trasporto, come l'acknoweledgment, i timeout, la
-  ritrasmissione, etc. È usato dalla maggior parte delle applicazioni.
+  ritrasmissione, ecc. È usato dalla maggior parte delle applicazioni.
 \item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
   connessione, per l'invio di dati a pacchetti. Contrariamente al TCP il
   protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
@@ -522,7 +522,7 @@ dall'\href{http://www.ietf.org/rfc/rfc0719.txt}{RFC~719}.
 Internet Protocol nasce per disaccoppiare le applicazioni della struttura
 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
 dei dati indipendente dal sottostante substrato di rete, che può essere
-realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
+realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, ecc.).
 Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
 all'altro della rete; le caratteristiche essenziali con cui questo viene
 realizzato in IPv4 sono due:
index 8d448b276ceca73cbad38a7808bc85ea1577295b..51bb284a4ea51152aac3736f3489ea197c911d67 100644 (file)
@@ -39,7 +39,7 @@ condivisione della conoscenza che sono la ricchezza maggiore che ho ricevuto.
 E, come per il software libero, anche in questo caso è importante la
 possibilità di accedere ai sorgenti (e non solo al risultato finale, sia
 questo una stampa o un file formattato) e la libertà di modificarli per
-apportarvi migliorie, aggiornamenti, etc.
+apportarvi migliorie, aggiornamenti, ecc.
 
 Per questo motivo la Free Software Foundation ha creato una apposita licenza
 che potesse giocare lo stesso ruolo fondamentale che la GPL ha avuto per il
index 831183141ca0030505cff2a299815b0830fc6562..e67ae82e4e1acc25228e2846493e383b3a0d7610 100644 (file)
@@ -1071,7 +1071,7 @@ delle relative chiamate (si veda sez.~\ref{sec:proc_exec}).
 
 La shell ad esempio ne usa molte per il suo funzionamento (come \texttt{PATH}
 per la ricerca dei comandi, o \texttt{IFS} per la scansione degli argomenti),
-e alcune di esse (come \texttt{HOME}, \texttt{USER}, etc.) sono definite al
+e alcune di esse (come \texttt{HOME}, \texttt{USER}, ecc.) sono definite al
 login (per i dettagli si veda sez.~\ref{sec:sess_login}). In genere è cura
 dell'amministratore definire le opportune variabili di ambiente in uno script
 di avvio. Alcune servono poi come riferimento generico per molti programmi
index ab71e822402b19a282731d6c70665f92848660b8..b2a491084300f1312382f5fa0e54c8e17f3e50c8 100644 (file)
@@ -116,7 +116,7 @@ Dato che tutti i processi attivi nel sistema sono comunque generati da
 \cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
   vero, in Linux ci sono alcuni processi speciali che pur comparendo come
   figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
-  direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.).} si
+  direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, ecc.).} si
 possono classificare i processi con la relazione padre/figlio in
 un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
 organizzati in un albero di directory (si veda
index 60514f5ef5d9be1fe6e64b848eca71e04df0fb02..1288d6c95b6168cee4c0da69afe6d85120b97454 100644 (file)
@@ -17,7 +17,7 @@ nessuna informazione che non sia il loro tipo; si tratta in sostanza di
 un'interruzione software portata ad un processo.
 
 In genere essi vengono usati dal kernel per riportare ai processi situazioni
-eccezionali (come errori di accesso, eccezioni aritmetiche, etc.) ma possono
+eccezionali (come errori di accesso, eccezioni aritmetiche, ecc.) ma possono
 anche essere usati come forma elementare di comunicazione fra processi (ad
 esempio vengono usati per il controllo di sessione), per notificare eventi
 (come la terminazione di un processo figlio), ecc.
@@ -25,7 +25,7 @@ esempio vengono usati per il controllo di sessione), per notificare eventi
 In questo capitolo esamineremo i vari aspetti della gestione dei segnali,
 partendo da una introduzione relativa ai concetti base con cui essi vengono
 realizzati, per poi affrontarne la classificazione a secondo di uso e modalità
-di generazione fino ad esaminare in dettaglio funzioni e le metodologie di
+di generazione fino ad esaminare in dettaglio le funzioni e le metodologie di
 gestione avanzate e le estensioni fatte all'interfaccia classica nelle nuovi
 versioni dello standard POSIX.
 
@@ -49,15 +49,15 @@ il seguente:
 
 \begin{itemize*}
 \item un errore del programma, come una divisione per zero o un tentativo di
-  accesso alla memoria fuori dai limiti validi.
-\item la terminazione di un processo figlio.
-\item la scadenza di un timer o di un allarme.
+  accesso alla memoria fuori dai limiti validi;
+\item la terminazione di un processo figlio;
+\item la scadenza di un timer o di un allarme;
 \item il tentativo di effettuare un'operazione di input/output che non può
-  essere eseguita.
+  essere eseguita;
 \item una richiesta dell'utente di terminare o fermare il programma. In genere
   si realizza attraverso un segnale mandato dalla shell in corrispondenza
   della pressione di tasti del terminale come \code{C-c} o
-  \code{C-z}.\footnote{indichiamo con \code{C-x} la pressione simultanea al
+  \code{C-z};\footnote{indichiamo con \code{C-x} la pressione simultanea al
     tasto \code{x} del tasto control (ctrl in molte tastiere).}
 \item l'esecuzione di una \func{kill} o di una \func{raise} da parte del
   processo stesso o di un'altro (solo nel caso della \func{kill}).
@@ -65,12 +65,12 @@ il seguente:
 
 Ciascuno di questi eventi (compresi gli ultimi due che pure sono controllati
 dall'utente o da un altro processo) comporta l'intervento diretto da parte del
-kernel che causa la generazione un particolare tipo di segnale.
+kernel che causa la generazione di un particolare tipo di segnale.
 
 Quando un processo riceve un segnale, invece del normale corso del programma,
 viene eseguita una azione predefinita o una apposita routine di gestione
 (quello che da qui in avanti chiameremo il \textsl{gestore} del segnale,
-dall'inglese\textit{signal handler}) che può essere stata specificata
+dall'inglese \textit{signal handler}) che può essere stata specificata
 dall'utente (nel qual caso si dice che si \textsl{intercetta} il segnale).
 
 
@@ -119,7 +119,7 @@ segnale e la reinstallazione del suo gestore non sono operazioni atomiche, e
 sono sempre possibili delle race condition\index{\textit{race~condition}}
 (sull'argomento vedi quanto detto in sez.~\ref{sec:proc_multi_prog}).
 
-Un'altro problema è che in questa semantica non esiste un modo per bloccare i
+Un altro problema è che in questa semantica non esiste un modo per bloccare i
 segnali quando non si vuole che arrivino; i processi possono ignorare il
 segnale, ma non è possibile istruire il sistema a non fare nulla in occasione
 di un segnale, pur mantenendo memoria del fatto che è avvenuto.
@@ -161,10 +161,11 @@ categorie principali: errori, eventi esterni e richieste esplicite.
 
 Un errore significa che un programma ha fatto qualcosa di sbagliato e non può
 continuare ad essere eseguito. Non tutti gli errori causano dei segnali, in
-genere la condizione di errore più comune comporta la restituzione di un
-codice di errore da parte di una funzione di libreria, sono gli errori che
-possono avvenire ovunque in un programma che causano l'emissione di un
-segnale, come le divisioni per zero o l'uso di indirizzi di memoria non validi.
+genere le condizioni di errore più comuni comportano la restituzione di un
+codice di errore da parte di una funzione di libreria; sono gli errori che
+possono avvenire nella esecuzione delle istruzioni di un programma che causano
+l'emissione di un segnale, come le divisioni per zero o l'uso di indirizzi di
+memoria non validi.
 
 Un evento esterno ha in genere a che fare con l'I/O o con altri processi;
 esempi di segnali di questo tipo sono quelli legati all'arrivo di dati di
@@ -221,7 +222,7 @@ una sola volta.
 Si ricordi però che se l'azione specificata per un segnale è quella di essere
 ignorato questo sarà scartato immediatamente al momento della sua generazione,
 e questo anche se in quel momento il segnale è bloccato (perché bloccare su un
-segnale significa bloccarne è la notifica). Per questo motivo un segnale,
+segnale significa bloccarne la notifica). Per questo motivo un segnale,
 fintanto che viene ignorato, non sarà mai notificato, anche se prima è stato
 bloccato ed in seguito si è specificata una azione diversa (nel qual caso solo
 i segnali successivi alla nuova specificazione saranno notificati).
@@ -233,8 +234,8 @@ segnale. Per alcuni segnali (\const{SIGKILL} e \const{SIGSTOP}) questa azione
 una  delle tre possibilità seguenti:
 
 \begin{itemize*}
-\item ignorare il segnale.
-\item catturare il segnale, ed utilizzare il gestore specificato.
+\item ignorare il segnale;
+\item catturare il segnale, ed utilizzare il gestore specificato;
 \item accettare l'azione predefinita per quel segnale.
 \end{itemize*}
 
@@ -252,7 +253,7 @@ segnale; nella maggior parte dei casi essa porta alla terminazione del
 processo, ma alcuni segnali che rappresentano eventi innocui vengono ignorati.
 
 Quando un segnale termina un processo, il padre può determinare la causa della
-terminazione esaminando il codice di stato riportato delle funzioni
+terminazione esaminando il codice di stato riportato dalle funzioni
 \func{wait} e \func{waitpid} (vedi sez.~\ref{sec:proc_wait}); questo è il modo
 in cui la shell determina i motivi della terminazione di un programma e scrive
 un eventuale messaggio di errore.
@@ -262,7 +263,7 @@ violazioni di accesso) hanno anche la caratteristica di scrivere un file di
 \textit{core dump} che registra lo stato del processo (ed in particolare della
 memoria e dello stack) prima della terminazione.  Questo può essere esaminato
 in seguito con un debugger per investigare sulla causa dell'errore.  Lo stesso
-avviene se i suddetti segnale vengono generati con una \func{kill}.
+avviene se i suddetti segnali vengono generati con una \func{kill}.
 
 
 \section{La classificazione dei segnali}
@@ -407,7 +408,7 @@ stato dello stack e delle variabili al momento della ricezione del segnale.
 \end{table}
 
 La descrizione dettagliata del significato dei vari segnali, raggruppati per
-tipologia, verrà affrontate nei paragrafi successivi.
+tipologia, verrà affrontata nei paragrafi successivi.
 
 
 \subsection{Segnali di errore di programma}
@@ -465,7 +466,7 @@ al momento della terminazione.  Questi segnali sono:
   ritorna il comportamento del processo è indefinito.
 
   È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
-  inizializzato leggendo al di la della fine di un vettore. 
+  inizializzato leggendo al di là della fine di un vettore. 
 \item[\const{SIGBUS}] Il nome deriva da \textit{bus error}. Come
   \const{SIGSEGV} questo è un segnale che viene generato di solito quando si
   dereferenzia un puntatore non inizializzato, la differenza è che
@@ -478,7 +479,7 @@ al momento della terminazione.  Questi segnali sono:
   funzione \func{abort} che genera questo segnale.
 \item[\const{SIGTRAP}] È il segnale generato da un'istruzione di breakpoint o
   dall'attivazione del tracciamento per il processo. È usato dai programmi per
-  il debugging e se un programma normale non dovrebbe ricevere questo segnale.
+  il debugging e un programma normale non dovrebbe ricevere questo segnale.
 \item[\const{SIGSYS}] Sta ad indicare che si è eseguita una istruzione che
   richiede l'esecuzione di una system call, ma si è fornito un codice
   sbagliato per quest'ultima.
@@ -595,8 +596,8 @@ segnali sono:
 \label{sec:sig_job_control}
 
 Questi sono i segnali usati dal controllo delle sessioni e dei processi, il
-loro uso è specifico e viene trattato in maniera specifica nelle sezioni in
-cui si trattano gli argomenti relativi.  Questi segnali sono:
+loro uso è specializzato e viene trattato in maniera specifica nelle sezioni
+in cui si trattano gli argomenti relativi.  Questi segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{SIGCHLD}] Questo è il segnale mandato al processo padre quando un
   figlio termina o viene fermato. L'azione predefinita è di ignorare il
@@ -658,11 +659,11 @@ processo, questi segnali sono:
   segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che
   lo ha causato fallisce, restituendo l'errore \errcode{EPIPE}.
 \item[\const{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
-  segnale che generato quando si ha un advisory lock su un file su NFS che
-  viene perso perché il server NFS è stato riavviato. Il progetto GNU lo
-  utilizza per indicare ad un client il crollo inaspettato di un server. In
-  Linux è definito come sinonimo di \const{SIGIO}.\footnote{ed è segnalato
-    come BUG nella pagina di manuale.}
+  segnale che viene generato quando si perde un advisory lock su un file su
+  NFS perché il server NFS è stato riavviato. Il progetto GNU lo utilizza per
+  indicare ad un client il crollo inaspettato di un server. In Linux è
+  definito come sinonimo di \const{SIGIO}.\footnote{ed è segnalato come BUG
+    nella pagina di manuale.}
 \item[\const{SIGXCPU}] Sta per \textit{CPU time limit exceeded}. Questo
   segnale è generato quando un processo eccede il limite impostato per il
   tempo di CPU disponibile, vedi sez.~\ref{sec:sys_resource_limit}. 
@@ -676,7 +677,7 @@ processo, questi segnali sono:
 \subsection{Ulteriori segnali}
 \label{sec:sig_misc_sig}
 
-Raccogliamo qui infine usa serie di segnali che hanno scopi differenti non
+Raccogliamo qui infine una serie di segnali che hanno scopi differenti non
 classificabili in maniera omogenea. Questi segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\const{SIGUSR1}] Insieme a \const{SIGUSR2} è un segnale a disposizione
@@ -727,11 +728,12 @@ La seconda funzione, \funcd{psignal}, deriva da BSD ed 
 \end{prototype}
 
 Una modalità alternativa per utilizzare le descrizioni restituite da
-\func{strsignal} e \func{psignal} è quello di fare usare la variabile
+\func{strsignal} e \func{psignal} è quello di usare la variabile
 \var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta
 con la dichiarazione:
 \includecodesnip{listati/siglist.c}
-l'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
+
+L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione,
 indicizzate per numero di segnale, per cui una chiamata del tipo di \code{char
   *decr = strsignal(SIGINT)} può essere sostituita dall'equivalente \code{char
   *decr = sys\_siglist[SIGINT]}.
@@ -747,13 +749,13 @@ programma. Per questa loro caratteristica la loro gestione non pu
 effettuata all'interno del normale flusso di esecuzione dello stesso, ma è
 delegata appunto agli eventuali gestori che si sono installati.
 
-In questa sezione vedremo come si effettua gestione dei segnali, a partire
+In questa sezione vedremo come si effettua la gestione dei segnali, a partire
 dalla loro interazione con le system call, passando per le varie funzioni che
-permettono di installare i gestori e controllare le reazioni di un
-processo alla loro occorrenza.
+permettono di installare i gestori e controllare le reazioni di un processo
+alla loro occorrenza.
 
 
-\subsection{Il comportamento generale del sistema.}
+\subsection{Il comportamento generale del sistema}
 \label{sec:sig_gen_beha}
 
 Abbiamo già trattato in sez.~\ref{sec:sig_intro} le modalità con cui il sistema
@@ -800,18 +802,18 @@ presenta questa situazione 
 \begin{itemize*}
 \item la lettura da file che possono bloccarsi in attesa di dati non ancora
   presenti (come per certi file di dispositivo\index{file!di~dispositivo}, i
-  socket\index{socket} o le pipe).
+  socket\index{socket} o le pipe);
 \item la scrittura sugli stessi file, nel caso in cui dati non possano essere
-  accettati immediatamente (di nuovo comune per i socket).
+  accettati immediatamente (di nuovo comune per i socket);
 \item l'apertura di un file di dispositivo che richiede operazioni non
   immediate per una risposta (ad esempio l'apertura di un nastro che deve
-  essere riavvolto).
+  essere riavvolto);
 \item le operazioni eseguite con \func{ioctl} che non è detto possano essere
-  eseguite immediatamente.
+  eseguite immediatamente;
 \item le funzioni di intercomunicazione che si bloccano in attesa di risposte
-  da altri processi.
+  da altri processi;
 \item la funzione \func{pause} (usata appunto per attendere l'arrivo di un
-  segnale).
+  segnale);
 \item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
 \end{itemize*}
 
@@ -1006,8 +1008,8 @@ Una seconda funzione che pu
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore, gli errori sono gli stessi di \func{kill}.}
 \end{prototype}
-\noindent e che permette di inviare un segnale a tutto un \textit{process
-  group} (vedi sez.~\ref{sec:sess_proc_group}).
+\noindent e permette di inviare un segnale a tutto un \textit{process group}
+(vedi sez.~\ref{sec:sess_proc_group}).
 
 \begin{table}[htb]
   \footnotesize
@@ -1043,7 +1045,7 @@ un gestore installato.
 Infine, seguendo le specifiche POSIX 1003.1-2001, l'uso della chiamata
 \code{kill(-1, sig)} comporta che il segnale sia inviato (con la solita
 eccezione di \cmd{init}) a tutti i processi per i quali i permessi lo
-consentano. Lo standard permette comunque alle varie implementazione di
+consentano. Lo standard permette comunque alle varie implementazioni di
 escludere alcuni processi specifici: nel caso in questione Linux non invia il
 segnale al processo che ha effettuato la chiamata.
 
@@ -1086,10 +1088,10 @@ processo tre diversi timer:
 \begin{itemize}
 \item un \textit{real-time timer} che calcola il tempo reale trascorso (che
   corrisponde al \textit{clock time}). La scadenza di questo timer provoca
-  l'emissione di \const{SIGALRM}.
+  l'emissione di \const{SIGALRM};
 \item un \textit{virtual timer} che calcola il tempo di processore usato dal
   processo in user space (che corrisponde all'\textit{user time}). La scadenza
-  di questo timer provoca l'emissione di \const{SIGVTALRM}.
+  di questo timer provoca l'emissione di \const{SIGVTALRM};
 \item un \textit{profiling timer} che calcola la somma dei tempi di processore
   utilizzati direttamente dal processo in user space, e dal kernel nelle
   system call ad esso relative (che corrisponde a quello che in
@@ -1216,7 +1218,7 @@ valore corrente di un timer senza modificarlo, 
 \func{setitimer}. 
 
 
-L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort};
+L'ultima funzione che permette l'invio diretto di un segnale è \funcd{abort},
 che, come accennato in sez.~\ref{sec:proc_termination}, permette di abortire
 l'esecuzione di un programma tramite l'invio di \const{SIGABRT}. Il suo
 prototipo è:
@@ -1384,7 +1386,7 @@ padre.\footnote{in realt
   ed usa il nome di \const{SIGCLD} come sinonimo di \const{SIGCHLD}.} In
 generale dunque, quando non interessa elaborare lo stato di uscita di un
 processo, si può completare la gestione della terminazione installando un
-gestore per \const{SIGCHLD} il cui unico compito sia quello chiamare
+gestore per \const{SIGCHLD} il cui unico compito sia quello di chiamare
 \func{waitpid} per completare la procedura di terminazione in modo da evitare
 la formazione di zombie\index{zombie}.
 
@@ -1415,16 +1417,15 @@ di zombie\index{zombie}.
 
 Il codice del gestore è di lettura immediata; come buona norma di
 programmazione (si ricordi quanto accennato sez.~\ref{sec:sys_errno}) si
-comincia (\texttt{\small 12-13}) con il salvare lo stato corrente di
+comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di
 \var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
-(\texttt{\small 22-23}). In questo modo si preserva il valore della variabile
-visto dal corso di esecuzione principale del processo, che sarebbe altrimenti
-sarebbe sovrascritto dal valore restituito nella successiva chiamata di
-\func{wait}.
+(\texttt{\small 16--17}). In questo modo si preserva il valore della variabile
+visto dal corso di esecuzione principale del processo, che altrimenti sarebbe
+sovrascritto dal valore restituito nella successiva chiamata di \func{wait}.
 
 Il compito principale del gestore è quello di ricevere lo stato di
 terminazione del processo, cosa che viene eseguita nel ciclo in
-(\texttt{\small 15-21}).  Il ciclo è necessario a causa di una caratteristica
+(\texttt{\small 9--15}).  Il ciclo è necessario a causa di una caratteristica
 fondamentale della gestione dei segnali: abbiamo già accennato come fra la
 generazione di un segnale e l'esecuzione del gestore possa passare un certo
 lasso di tempo e niente ci assicura che il gestore venga eseguito prima della
@@ -1455,7 +1456,7 @@ tutti gli stati di terminazione sono stati ricevuti.
 \section{Gestione avanzata}
 \label{sec:sig_control}
 
-Le funzioni esaminate finora fanno riferimento ad alle modalità più elementari
+Le funzioni esaminate finora fanno riferimento alle modalità più elementari
 della gestione dei segnali; non si sono pertanto ancora prese in
 considerazione le tematiche più complesse, collegate alle varie race
 condition\index{\textit{race~condition}} che i segnali possono generare e alla
@@ -1478,14 +1479,14 @@ versione di \func{sleep} potrebbe essere quella illustrata in
 fig.~\ref{fig:sig_sleep_wrong}.
 
 Dato che è nostra intenzione utilizzare \const{SIGALRM} il primo passo della
-nostra implementazione di sarà quello di installare il relativo gestore
-salvando il precedente (\texttt{\small 14-17}).  Si effettuerà poi una
-chiamata ad \func{alarm} per specificare il tempo d'attesa per l'invio del
-segnale a cui segue la chiamata a \func{pause} per fermare il programma
-(\texttt{\small 17-19}) fino alla sua ricezione.  Al ritorno di \func{pause},
-causato dal ritorno del gestore (\texttt{\small 1-9}), si ripristina il
-gestore originario (\texttt{\small 20-21}) restituendo l'eventuale tempo
-rimanente (\texttt{\small 22-23}) che potrà essere diverso da zero qualora
+nostra implementazione sarà quello di installare il relativo gestore salvando
+il precedente (\texttt{\small 14-17}).  Si effettuerà poi una chiamata ad
+\func{alarm} per specificare il tempo d'attesa per l'invio del segnale a cui
+segue la chiamata a \func{pause} per fermare il programma (\texttt{\small
+  18-20}) fino alla sua ricezione.  Al ritorno di \func{pause}, causato dal
+ritorno del gestore (\texttt{\small 1-9}), si ripristina il gestore originario
+(\texttt{\small 21-22}) restituendo l'eventuale tempo rimanente
+(\texttt{\small 23-24}) che potrà essere diverso da zero qualora
 l'interruzione di \func{pause} venisse causata da un altro segnale.
 
 \begin{figure}[!htb]