Messi gli esempi nel testo e usata daemon dove serve nei server
[gapil.git] / signal.tex
index 9b906691c82be6d3df242d76e1832993c94da96d..250653effe452aa10211384610f120972708f64e 100644 (file)
@@ -518,7 +518,8 @@ segnali sono:
 \item[\const{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale
   generico usato per causare la conclusione di un programma. Al contrario di
   \const{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo si
-  usa per chiedere in maniera ``educata'' ad un processo di concludersi.
+  usa per chiedere in maniera ``\textsl{educata}'' ad un processo di
+  concludersi.
 \item[\const{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di
   interruzione per il programma. È quello che viene generato di default dal
   comando \cmd{kill} o dall'invio sul terminale del carattere di controllo
@@ -804,7 +805,7 @@ gestore non comporta nessun inconveniente.
 
 In alcuni casi però alcune system call (che per questo motivo vengono chiamate
 \textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
-attendere la conclusione della sistem call, perché questo renderebbe
+attendere la conclusione della system call, perché questo renderebbe
 impossibile una risposta pronta al segnale, per cui il gestore viene
 eseguito prima che la system call sia ritornata.  Un elenco dei casi in cui si
 presenta questa situazione è il seguente:
@@ -940,7 +941,7 @@ un ciclo infinito.
 
 Come accennato in \secref{sec:sig_types}, un segnale può essere generato
 direttamente da un processo attraverso una opportuna system call. Le funzioni
-che si usano di solito per invare un segnale generico sono due, \func{raise} e
+che si usano di solito per inviare un segnale generico sono due, \func{raise} e
 \func{kill}.
 
 La prima funzione è \funcd{raise}, che è definita dallo standard ANSI C, e
@@ -1037,8 +1038,8 @@ e che permette di inviare un segnale a tutto un \textit{process group} (vedi
 \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
-chiamante devono corrispondere all'userid reale o all'userid salvato della
+tutti gli altri casi l'user-ID reale o l'user-ID effettivo del processo
+chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della
 destinazione. Fa eccezione il caso in cui il segnale inviato sia
 \const{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla
 stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema
@@ -1471,10 +1472,10 @@ Il compito principale del gestore 
 terminazione del processo, cosa che viene eseguita nel ciclo in
 (\texttt{\small 15-21}).  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 generazione di ulteriori segnali dello stesso tipo. In questo caso
-normalmente i segnali segnali successivi vengono ``fusi'' col primo ed al
+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
+generazione di ulteriori segnali dello stesso tipo. In questo caso normalmente
+i segnali segnali successivi vengono ``\textsl{fusi}'' col primo ed al
 processo ne viene recapitato soltanto uno.
 
 Questo può essere un caso comune proprio con \const{SIGCHLD}, qualora capiti
@@ -1942,7 +1943,7 @@ specifica: ad esempio i vari segnali di errore (\const{SIGFPE},
 maggiori dettagli riguardo l'errore (come il tipo di errore aritmetico, di
 istruzione illecita o di violazione di memoria) mentre alcuni segnali di
 controllo (\const{SIGCHLD}, \const{SIGTRAP} e \const{SIGPOLL}) forniscono
-altre informazioni speecifiche.  In tutti i casi il valore del campo è
+altre informazioni specifiche.  In tutti i casi il valore del campo è
 riportato attraverso delle costanti (le cui definizioni si trovano
 \file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella pagina di
 manuale di di \func{sigaction}.
@@ -2449,7 +2450,7 @@ tutti la stessa priorit
 real-time.
 
 Si tenga presente che questi nuovi segnali non sono associati a nessun evento
-sepcifico (a meno di non utilizzarli, come vedremo in
+specifico (a meno di non utilizzarli, come vedremo in
 \secref{sec:file_asyncronous_io}, per l'I/O asincrono) e devono essere inviati
 esplicitamente. Tutti i segnali real-time restituiscono al gestore, oltre ai
 campi \var{si\_pid} e \var{si\_uid} di \struct{siginfo\_t} una struttura
@@ -2487,7 +2488,7 @@ nuova funzione, \funcd{sigqueue}, il cui prototipo 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EAGAIN}] La coda è esarita, ci sono già \const{SIGQUEUE\_MAX}
+  \item[\errcode{EAGAIN}] La coda è esaurita, ci sono già \const{SIGQUEUE\_MAX}
     segnali in attesa si consegna.
   \item[\errcode{EPERM}] Non si hanno privilegi appropriati per inviare il
     segnale al processo specificato.
@@ -2576,7 +2577,7 @@ relativi prototipi sono:
     \func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}:
   \begin{errlist}
   \item[\errcode{EAGAIN}] Si è superato il timeout senza che un segnale atteso
-    fosse emmesso.
+    fosse emesso.
   \end{errlist}
 }
 \end{functions}
@@ -2591,7 +2592,7 @@ associato viene riportato in \var{si\_value}, che altrimenti 
 La seconda è identica alla prima ma in più permette di specificare un timeout,
 scaduto il quale ritornerà con un errore. Se si specifica un puntatore nullo
 il comportamento sarà identico a \func{sigwaitinfo}, se si specifica un tempo
-di timeout nullo, e non ci sono sengali pendenti la funzione ritornerà
+di timeout nullo, e non ci sono segnali pendenti la funzione ritornerà
 immediatamente; in questo modo si può eliminare un segnale dalla coda senza
 dover essere bloccati qualora esso non sia presente.