X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=84c8ac5f00b1ad2ea340877691da1ec0f5db0082;hp=a3a2a47d87ce993e0c86f66d4658f95aeaaefe01;hb=6c2be511ebf59148d64ae0da7f44e21b2bd92e73;hpb=8fad76a42d4fdf71d9a90d425a70af66827fbf9e

diff --git a/signal.tex b/signal.tex
index a3a2a47..84c8ac5 100644
--- a/signal.tex
+++ b/signal.tex
@@ -1,6 +1,6 @@
 %% signal.tex
 %%
-%% Copyright (C) 2000-2014 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2015 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 "Un preambolo",
@@ -134,9 +134,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 \itindex{scheduler} scheduler quando,
-riprendendo l'esecuzione del processo in questione, verifica la presenza del
-segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
+procedura viene effettuata dallo \textit{scheduler} quando, riprendendo
+l'esecuzione del processo in questione, verifica la presenza del segnale nella
+\struct{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
@@ -217,11 +217,10 @@ verrà notificato al processo o verrà specificata come azione quella di
 ignorarlo.
 
 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
-avviene non appena questo viene rimesso in esecuzione dallo
-\itindex{scheduler} 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. 
+avviene non appena questo viene rimesso in esecuzione dallo \textit{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 un segnale \textsl{pendente} sarà subito notificato. Si
 tenga presente però che tradizionalmente i segnali \textsl{pendenti} non si
@@ -287,12 +286,12 @@ l'immagine della memoria del processo.
 
 Questo file costituisce il cosiddetto \textit{core dump}, e contenendo
 l'immagine della memoria del processo, consente di risalire allo stato dello
-\itindex{stack} \textit{stack} (vedi sez.~\ref{sec:proc_mem_layout}) prima
-della terminazione. Questo permette di esaminare il contenuto del file un
-secondo tempo con un apposito programma (un \textit{debugger} come \cmd{gdb})
-per investigare sulla causa dell'errore, ed in particolare, grazie appunto ai
-dati dello \itindex{stack} \textit{stack}, consente di identificare quale
-funzione ha causato l'errore.
+\textit{stack} (vedi sez.~\ref{sec:proc_mem_layout}) prima della
+terminazione. Questo permette di esaminare il contenuto del file un secondo
+tempo con un apposito programma (un \textit{debugger} come \cmd{gdb}) per
+investigare sulla causa dell'errore, ed in particolare, grazie appunto ai dati
+dello \textit{stack}, consente di identificare quale funzione ha causato
+l'errore.
 
 Si tenga presente che il \textit{core dump} viene creato non solo in caso di
 errore effettivo, ma anche se il segnale per cui la sua creazione è prevista
@@ -349,7 +348,7 @@ esse sono definite nell'header di sistema \headfile{signal.h}.
     \signal{SIGUSR1} &P & T & Segnale utente numero 1.\\
     \signal{SIGSEGV} &AP& C & Errore di accesso in memoria.\\
     \signal{SIGUSR2} &P & T & Segnale utente numero 2.\\
-    \signal{SIGPIPE} &P & T & Pipe spezzata.\\
+    \signal{SIGPIPE} &P & T & \textit{Pipe} spezzata.\\
     \signal{SIGALRM} &P & T & Segnale del timer da \func{alarm}.\\
     \signal{SIGTERM} &AP& T & Segnale di terminazione (\texttt{C-\bslash}).\\
     \signal{SIGCHLD} &P & I & Figlio terminato o fermato.\\
@@ -447,7 +446,7 @@ tab.~\ref{tab:sig_action_leg}).
     \hline
     T & L'azione predefinita è terminare il processo.\\
     C & L'azione predefinita è terminare il processo e scrivere un 
-        \itindex{core~dump} \textit{core dump}.\\
+        \textit{core dump}.\\
     I & L'azione predefinita è ignorare il segnale.\\
     S & L'azione predefinita è fermare il processo.\\
     \hline
@@ -495,9 +494,9 @@ gestore non ci fosse stato.
 
 L'azione predefinita per tutti questi segnali è causare la terminazione del
 processo che li ha causati. In genere oltre a questo il segnale provoca pure
-la registrazione su disco di un file di \itindex{core~dump} \textit{core
-  dump}, che un debugger può usare per ricostruire lo stato del programma al
-momento della terminazione.  Questi segnali sono:
+la registrazione su disco di un file di \textit{core dump}, che un debugger
+può usare per ricostruire lo stato del programma al momento della
+terminazione.  Questi segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\signal{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
   derivi da \textit{floating point exception} si applica a tutti gli errori
@@ -591,13 +590,12 @@ processo, questi segnali sono:
   controllato da un altro carattere di controllo, ``\textit{QUIT}'',
   corrispondente alla sequenza \texttt{C-\bslash} sulla tastiera. A differenza
   del precedente l'azione predefinita, oltre alla terminazione del processo,
-  comporta anche la creazione di un \itindex{core~dump} \textit{core dump}.
-  In genere lo si può pensare come corrispondente ad una condizione di errore
-  del programma rilevata dall'utente. Per questo motivo non è opportuno fare
-  eseguire al gestore di questo segnale le operazioni di pulizia normalmente
-  previste (tipo la cancellazione di file temporanei), dato che in certi casi
-  esse possono eliminare informazioni utili nell'esame dei \itindex{core~dump}
-  \textit{core dump}.
+  comporta anche la creazione di un \textit{core dump}.  In genere lo si può
+  pensare come corrispondente ad una condizione di errore del programma
+  rilevata dall'utente. Per questo motivo non è opportuno fare eseguire al
+  gestore di questo segnale le operazioni di pulizia normalmente previste
+  (tipo la cancellazione di file temporanei), dato che in certi casi esse
+  possono eliminare informazioni utili nell'esame dei \textit{core dump}.
 
 \item[\signal{SIGKILL}] Il nome è utilizzato per terminare in maniera immediata
   qualunque programma. Questo segnale non può essere né intercettato, né
@@ -744,28 +742,28 @@ che impediscono il completamento dell'esecuzione dovute all'interazione con il
 resto del sistema.  L'azione predefinita di questi segnali è normalmente
 quella di terminare il processo, questi segnali sono:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
-\item[\signal{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle pipe,
-  (o delle FIFO o dei socket) è necessario, prima che un processo inizi a
-  scrivere su una di esse, che un altro l'abbia aperta in lettura (si veda
-  sez.~\ref{sec:ipc_pipes}). Se il processo in lettura non è partito o è
-  terminato inavvertitamente alla scrittura sulla pipe il kernel genera questo
-  segnale. Se il segnale è bloccato, intercettato o ignorato la chiamata che
-  lo ha causato fallisce, restituendo l'errore \errcode{EPIPE}.
+\item[\signal{SIGPIPE}] Sta per \textit{Broken pipe}. Se si usano delle
+  \textit{pipe}, (o delle FIFO o dei socket) è necessario, prima che un
+  processo inizi a scrivere su una di esse, che un altro l'abbia aperta in
+  lettura (si veda sez.~\ref{sec:ipc_pipes}). Se il processo in lettura non è
+  partito o è terminato inavvertitamente alla scrittura sulla \textit{pipe} il
+  kernel genera questo segnale. Se il segnale è bloccato, intercettato o
+  ignorato la chiamata che lo ha causato fallisce, restituendo l'errore
+  \errcode{EPIPE}.
 
 \item[\signal{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}. Fino al
   kernel 2.2 terminava semplicemente il processo, a partire dal kernel 2.4,
   seguendo le indicazioni dello standard POSIX.1-2001 viene anche generato un
-  \itindex{core~dump} \textit{core dump}.
+  \textit{core dump}.
 
 \item[\signal{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo
   segnale è generato quando un processo tenta di estendere un file oltre le
   dimensioni specificate dal limite impostato per le dimensioni massime di un
   file, vedi sez.~\ref{sec:sys_resource_limit}.  Fino al kernel 2.2 terminava
   semplicemente il processo, a partire dal kernel 2.4, seguendo le indicazioni
-  dello standard POSIX.1-2001 viene anche generato un \itindex{core~dump}
-  \textit{core dump}.
+  dello standard POSIX.1-2001 viene anche generato un \textit{core dump}.
 
 \item[\signal{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
   segnale che viene generato quando si perde un advisory lock su un file su
@@ -939,7 +937,7 @@ presenta questa situazione è il seguente:
 \begin{itemize*}
 \item la lettura da file che possono bloccarsi in attesa di dati non ancora
   presenti (come per certi \index{file!di~dispositivo} file di dispositivo, i
-  socket o le pipe);
+  socket o le \textit{pipe});
 \item la scrittura sugli stessi file, nel caso in cui dati non possano essere
   accettati immediatamente (di nuovo comune per i socket);
 \item l'apertura di un file di dispositivo che richiede operazioni non
@@ -1655,15 +1653,16 @@ esecuzione). Per questo motivo il valore restituito in \param{rem} è sempre
 arrotondato al multiplo successivo di 1/\const{HZ}. 
 
 Con i kernel della serie 2.4 in realtà era possibile ottenere anche pause più
-precise del centesimo di secondo usando politiche di \itindex{scheduler}
-scheduling \textit{real-time} come \const{SCHED\_FIFO} o \const{SCHED\_RR}; in
-tal caso infatti il calcolo sul numero di interruzioni del timer veniva
-evitato utilizzando direttamente un ciclo di attesa con cui si raggiungevano
-pause fino ai 2~ms con precisioni del $\mu$s. Questa estensione è stata
-rimossa con i kernel della serie 2.6, che consentono una risoluzione più alta
-del timer di sistema; inoltre a partire dal kernel 2.6.21, \func{nanosleep}
-può avvalersi del supporto dei timer ad alta risoluzione, ottenendo la massima
-precisione disponibile sull'hardware della propria macchina.
+precise del centesimo di secondo usando politiche di \textit{scheduling}
+\textit{real-time} come \const{SCHED\_FIFO} o \const{SCHED\_RR} (vedi
+sez.~\ref{sec:proc_real_time}); in tal caso infatti il calcolo sul numero di
+interruzioni del timer veniva evitato utilizzando direttamente un ciclo di
+attesa con cui si raggiungevano pause fino ai 2~ms con precisioni del
+$\mu$s. Questa estensione è stata rimossa con i kernel della serie 2.6, che
+consentono una risoluzione più alta del timer di sistema; inoltre a partire
+dal kernel 2.6.21, \func{nanosleep} può avvalersi del supporto dei timer ad
+alta risoluzione, ottenendo la massima precisione disponibile sull'hardware
+della propria macchina.
 
 
 \subsection{Un esempio elementare}
@@ -2212,7 +2211,7 @@ altre informazioni specifiche.
     \const{SI\_SIGIO}  & Segnale di \signal{SIGIO} da una coda (vedi
                          sez.~\ref{sec:file_asyncronous_operation}).\\ 
     \const{SI\_TKILL}  & Inviato da \func{tkill} o \func{tgkill} (vedi
-                         sez.~\ref{cha:threads_xxx}), introdotto con il kernel
+                         sez.~\ref{cha:thread_xxx}), introdotto con il kernel
                          2.4.19.\\ 
     \hline
   \end{tabular}