Correzioni

diff --git a/signal.tex b/signal.tex
index 3bc1af18268fc02f28356d0a52e9988d0fd3d5f5..ebcdbef2cebd2cc6c8c514c2a6403cb968a43575 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -2,7 +2,7 @@
 \label{cha:signals}
 
 I segnali sono il primo e più semplice meccanismo di comunicazione nei
-confronti dei processi. Non portano con se nessuna informazione che non sia il
+confronti dei processi. Non portano con sé nessuna informazione che non sia il
 loro tipo; si tratta in sostanza di un'interruzione software portata ad un
 processo.
 
@@ -15,7 +15,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 generazionem fino ad esaminare in dettaglio funzioni e le metodologie di
+di generazione fino ad esaminare in dettaglio funzioni e le metodologie di
 gestione.
 
 
@@ -243,7 +243,7 @@ non 
 \var{task\_struct} del processo; si dice così che il segnale diventa
 \textsl{pendente} (o \textit{pending}), e rimane tale fino al momento in cui
 verrà notificato al processo (o verrà specificata come azione di default
-quella di ingorarlo).
+quella di ignorarlo).
 
 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
 avviene non appena questo viene rimesso in esecuzione dallo scheduler che
@@ -372,7 +372,7 @@ anche a seconda dell'architettura hardware.
 
 Per questo motivo ad ogni segnale viene associato un nome, definendo con una
 macro di preprocessore una costante uguale al suddetto numero. Sono questi
-nomi, che sono standardizzati e sostanzialemnte uniformi rispetto alle varie
+nomi, che sono standardizzati e sostanzialmente uniformi rispetto alle varie
 implementazioni, che si devono usare nei programmi. Tutti i nomi e le funzioni
 che concernono i segnali sono definiti nell'header di sistema \file{signal.h}.
 
@@ -819,20 +819,20 @@ eseguire un manipolatore non comporta nessun inconveniente.
 Esistono però dei casi in cui questo non è possibile perché renderebbe
 impossibile una risposta pronta al segnale. In generale questo avviene tutte
 le volte che si ha a che fare con system call che possono bloccarsi
-indenfinitamente, che per questo vengono chiamate \textsl{lente}. Un elenco
+indefinitamente, che per questo vengono chiamate \textsl{lente}. Un elenco
 dei casi in cui si presenta questa situazione è il seguente:
 \begin{itemize*}
 \item lettura da file che possono bloccarsi in attesa di dati non ancora
   presenti (come per certi file di dispositivo, la rete o le pipe).
 \item scrittura sugli stessi file, nel caso in cui dati non possano essere
   accettati immediatamente.
-\item apertura di un file di dipositivo che richiede operazioni non immediate
+\item apertura di un file di dispositivo che richiede operazioni non immediate
   per una una risposta. 
 \item operazioni eseguite con \func{ioctl} che non è detto possano essere
   eseguite immediatamente.
 \item le funzioni di intercomunicazione che si bloccano in attesa di risposte
   da altri processi.
-\item la funzione \func{pause} (usata appunto per attendere l'arrivo di un
+\item la funzione \func{pause} (usata appunto per attendere l'-arrivo di un
   segnale).
 \item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
 \end{itemize*}
@@ -945,7 +945,7 @@ un ciclo infinito.
 \label{sec:sig_kill_raise}
 
 Come accennato in \secref{sec:sig_types}, un segnale può essere generato
-direttamente da un processo. L'invio di un sengale generico può essere
+direttamente da un processo. L'invio di un segnale generico può essere
 effettuato attraverso delle funzioni \func{kill} e \func{raise}. La prima
 serve per inviare un segnale al processo corrente, ed il suo prototipo è:
 \begin{prototype}{signal.h}{int raise(int sig)}
@@ -1180,7 +1180,7 @@ Si deve comunque tenere presente che la precisione di queste funzioni 
 limitata da quella del timer di sistema (in genere 10~ms). Il sistema assicura
 comunque che il segnale non sarà mai generato prima della scadenza programmata
 (l'arrotondamento cioè è sempre effettuato per eccesso). Una seconda causa di
-potenziali ritardi è che il segnale viene generato alla scandenza del timer,
+potenziali ritardi è che il segnale viene generato alla scadenza del timer,
 ma poi deve essere consegnato; se il processo è attivo (questo è sempre vero
 per \macro{ITIMER\_VIRT}) la consegna è immediata, altrimenti può esserci un
 ulteriore ritardo che può variare a seconda del carico del sistema.
@@ -1236,7 +1236,7 @@ segnale 
   Pone il processo in stato di sleep fino al ritorno di un manipolatore.
   
   \bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
-  il relativo manipilatore è ritornato, nel qual caso restituisce -1 e setta
+  il relativo manipolatore è ritornato, nel qual caso restituisce -1 e setta
   \var{errno} a \macro{EINTR}.}
 \end{prototype}