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
 \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.
 
 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à
 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.
 
 
 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
 \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
 
 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
 
 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}.
 
 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
 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.
 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.
   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*}
   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
 \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)}
 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
 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.
 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
   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}
 
   \var{errno} a \macro{EINTR}.}
 \end{prototype}