X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=signal.tex;h=60514f5ef5d9be1fe6e64b848eca71e04df0fb02;hb=bf81ce9ec539254693a8c41641a99af1aa1d886f;hp=61d340f4fd6d51c204fbbd1cb3789e781e91b1c7;hpb=041fde8aba0e18bb746653a060619b32ea9240ce;p=gapil.git

diff --git a/signal.tex b/signal.tex
index 61d340f..60514f5 100644
--- a/signal.tex
+++ b/signal.tex
@@ -846,13 +846,13 @@ ritornano sempre indicando i byte trasferiti.
 \label{sec:sig_signal}
 
 L'interfaccia più semplice per la gestione dei segnali è costituita dalla
-funzione \funcd{signal} che è definita fin dallo standard ANSI C.  Quest'ultimo
-però non considera sistemi multitasking, per cui la definizione è tanto vaga
-da essere del tutto inutile in un sistema Unix; è questo il motivo per cui
-ogni implementazione successiva ne ha modificato e ridefinito il
+funzione \funcd{signal} che è definita fin dallo standard ANSI C.
+Quest'ultimo però non considera sistemi multitasking, per cui la definizione è
+tanto vaga da essere del tutto inutile in un sistema Unix; è questo il motivo
+per cui ogni implementazione successiva ne ha modificato e ridefinito il
 comportamento, pur mantenendone immutato il prototipo\footnote{in realtà in
   alcune vecchie implementazioni (SVr4 e 4.3+BSD in particolare) vengono usati
-  alcuni parametri aggiuntivi per definire il comportamento della funzione,
+  alcuni argomenti aggiuntivi per definire il comportamento della funzione,
   vedremo in sez.~\ref{sec:sig_sigaction} che questo è possibile usando la
   funzione \func{sigaction}.}  che è:
 \begin{prototype}{signal.h}
@@ -1212,7 +1212,7 @@ valore corrente di un timer senza modificarlo, 
   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
     errore e restituisce gli stessi errori di \func{getitimer}}
 \end{prototype}
-\noindent i cui parametri hanno lo stesso significato e formato di quelli di
+\noindent i cui argomenti hanno lo stesso significato e formato di quelli di
 \func{setitimer}. 
 
 
@@ -1339,7 +1339,7 @@ POSIX1.b, il cui prototipo 
 Lo standard richiede che la funzione sia implementata in maniera del tutto
 indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
   utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
-interferenze con l'uso di \const{SIGALRM}. La funzione prende come parametri
+interferenze con l'uso di \const{SIGALRM}. La funzione prende come argomenti
 delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
 fig.~\ref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
 una precisione (teorica) fino al nanosecondo.
@@ -1762,21 +1762,21 @@ in tab.~\ref{tab:sig_sa_flag}.
   \label{tab:sig_sa_flag}
 \end{table}
 
-Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction}
-permette\footnote{La possibilità è prevista dallo standard POSIX.1b, ed è
-  stata aggiunta nei kernel della serie 2.1.x con l'introduzione dei segnali
-  real-time (vedi sez.~\ref{sec:sig_real_time}). In precedenza era possibile
-  ottenere alcune informazioni addizionali usando \var{sa\_handler} con un
-  secondo parametro addizionale di tipo \var{sigcontext}, che adesso è
-  deprecato.}  di utilizzare due forme diverse di gestore, da specificare, a
-seconda dell'uso o meno del flag \const{SA\_SIGINFO}, rispettivamente
-attraverso i campi \var{sa\_sigaction} o \var{sa\_handler},\footnote{i due
-  tipi devono essere usati in maniera alternativa, in certe implementazioni
-  questi campi vengono addirittura definiti come \ctyp{union}.}  Quest'ultima
-è quella classica usata anche con \func{signal}, mentre la prima permette di
-usare un gestore più complesso, in grado di ricevere informazioni più
-dettagliate dal sistema, attraverso la struttura \struct{siginfo\_t},
-riportata in fig.~\ref{fig:sig_siginfo_t}.
+Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
+di utilizzare due forme diverse di gestore,\footnote{La possibilità è prevista
+  dallo standard POSIX.1b, ed è stata aggiunta nei kernel della serie 2.1.x
+  con l'introduzione dei segnali real-time (vedi
+  sez.~\ref{sec:sig_real_time}); in precedenza era possibile ottenere alcune
+  informazioni addizionali usando \var{sa\_handler} con un secondo parametro
+  addizionale di tipo \var{sigcontext}, che adesso è deprecato.}  da
+specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
+rispettivamente attraverso i campi \var{sa\_sigaction} o
+\var{sa\_handler},\footnote{i due tipi devono essere usati in maniera
+  alternativa, in certe implementazioni questi campi vengono addirittura
+  definiti come \ctyp{union}.}  Quest'ultima è quella classica usata anche con
+\func{signal}, mentre la prima permette di usare un gestore più complesso, in
+grado di ricevere informazioni più dettagliate dal sistema, attraverso la
+struttura \struct{siginfo\_t}, riportata in fig.~\ref{fig:sig_siginfo_t}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -2341,7 +2341,7 @@ installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
 (vale a dire che c'è posto\footnote{la profondità della coda è indicata dalla
   costante \const{SIGQUEUE\_MAX}, una della tante costanti di sistema definite
   dallo standard POSIX che non abbiamo riportato esplicitamente in
-  sez.~\ref{sec:sys_limits}. Il suo valore minimo secondo lo standard,
+  sez.~\ref{sec:sys_limits}; il suo valore minimo secondo lo standard,
   \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux questo è uno
   dei parametri del kernel impostabili sia con \func{sysctl}, che scrivendolo
   direttamente in \file{/proc/sys/kernel/rtsig-max}, il valore predefinito è