Aggiunte alla shared memory

[gapil.git] / signal.tex

diff --git a/signal.tex b/signal.tex
index 39d70ef981f267689d3804813963725a1f5091b8..3b11014a81f591a6a8aa10241da17911ca8ba83a 100644 (file)
--- a/signal.tex
+++ b/signal.tex
@@ -1,3 +1,13 @@
+%% signal.tex
+%%
+%% Copyright (C) 2000-2002 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 "Prefazione",
+%% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
+%% license is included in the section entitled "GNU Free Documentation
+%% License".
+%%

 \chapter{I segnali}
 \label{cha:signals}
 
 \chapter{I segnali}
 \label{cha:signals}
 


@@ -140,9 +150,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
 \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 scheduler quando, riprendendo l'esecuzione
-del processo in questione, verifica la presenza del segnale nella
-\var{task\_struct} e mette in esecuzione il gestore.
+procedura viene effettuata dallo scheduler\index{scheduler} quando,
+riprendendo l'esecuzione del processo in questione, verifica la presenza del
+segnale nella \var{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
 
 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


@@ -211,11 +221,12 @@ verr
 ignorarlo).
 
 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
 ignorarlo).
 
 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed

-avviene non appena questo viene rimesso in esecuzione dallo 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 il
-segnale \textsl{pendente} sarà subito notificato.
+avviene non appena questo viene rimesso in esecuzione dallo
+scheduler\index{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 il segnale \textsl{pendente} sarà subito
+notificato.

 
 Si ricordi però che se l'azione specificata per un segnale è quella di essere
 ignorato questo sarà scartato immediatamente al momento della sua generazione,
 
 Si ricordi però che se l'azione specificata per un segnale è quella di essere
 ignorato questo sarà scartato immediatamente al momento della sua generazione,


@@ -1009,7 +1020,7 @@ Una seconda funzione che pu
     errore, gli errori sono gli stessi di \func{kill}.}
 \end{prototype}
 e che permette di inviare un segnale a tutto un \textit{process group} (vedi
     errore, gli errori sono gli stessi di \func{kill}.}
 \end{prototype}
 e che permette di inviare un segnale a tutto un \textit{process group} (vedi

-\secref{sec:sess_xxx}).
+\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
 
 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


@@ -1347,11 +1358,11 @@ Chiaramente, anche se il tempo pu
 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
 specificato, ma prima che il processo possa tornare ad essere eseguito
 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
 specificato, ma prima che il processo possa tornare ad essere eseguito

-occorrerà almeno attendere il successivo giro di scheduler e cioè un tempo che
-a seconda dei casi può arrivare fino a 1/\macro{HZ}, (sempre che il sistema
-sia scarico ed il processa venga immediatamente rimesso in esecuzione); per
-questo motivo il valore restituito in \param{rem} è sempre arrotondato al
-multiplo successivo di 1/\macro{HZ}.
+occorrerà almeno attendere il successivo giro di scheduler\index{scheduler} e
+cioè un tempo che a seconda dei casi può arrivare fino a 1/\macro{HZ}, (sempre
+che il sistema sia scarico ed il processa venga immediatamente rimesso in
+esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
+arrotondato al multiplo successivo di 1/\macro{HZ}.

 
 In realtà è possibile ottenere anche pause più precise del centesimo di
 secondo usando politiche di scheduling real time come \macro{SCHED\_FIFO} o
 
 In realtà è possibile ottenere anche pause più precise del centesimo di
 secondo usando politiche di scheduling real time come \macro{SCHED\_FIFO} o


@@ -1383,8 +1394,8 @@ zombie.
 
 In \figref{fig:sig_sigchld_handl} è mostrato il codice contenente una
 implementazione generica di una routine di gestione per \macro{SIGCHLD}, (che
 
 In \figref{fig:sig_sigchld_handl} è mostrato il codice contenente una
 implementazione generica di una routine di gestione per \macro{SIGCHLD}, (che

-si trova nei sorgenti allegati nel file \file{HandSIGCHLD.c}); se ripetiamo i
-test di \secref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
+si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i test
+di \secref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione

 \cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
 gestore di \macro{SIGCHLD}) potremo verificare che non si ha più la creazione
 di zombie.
 \cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
 gestore di \macro{SIGCHLD}) potremo verificare che non si ha più la creazione
 di zombie.


@@ -1406,7 +1417,7 @@ di zombie.
 #include <sys/wait.h>
 #include "macro.h"
 
 #include <sys/wait.h>
 #include "macro.h"
 

-void HandSIGCHLD(int sig)
+void HandSigCHLD(int sig)

 {
     int errno_save;
     int status;
 {
     int errno_save;
     int status;


@@ -1983,25 +1994,24 @@ inline SigFunc * Signal(int signo, SigFunc *func)
 Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
 che abbia le stesse caratteristiche di \func{signal}, a definire una funzione
 equivalente attraverso \func{sigaction}; la funzione è \code{Signal}, e si
 Per questo motivo si è provveduto, per mantenere un'interfaccia semplificata
 che abbia le stesse caratteristiche di \func{signal}, a definire una funzione
 equivalente attraverso \func{sigaction}; la funzione è \code{Signal}, e si

-trova definita come \code{inline} nel file \file{wrapper.h} (nei sorgenti
-allegati), riportata in \figref{fig:sig_Signal_code}. La riutilizzeremo spesso
-in seguito. 
+trova definita nel file \file{SigHand.c} (nei sorgenti allegati), e riportata
+in \figref{fig:sig_Signal_code}. La riutilizzeremo spesso in seguito.

 
 \subsection{La gestione della \textsl{maschera dei segnali} o 
   \textit{signal mask}}
 \label{sec:sig_sigmask}
 
 Come spiegato in \secref{sec:sig_semantics} tutti i moderni sistemi unix-like
 
 \subsection{La gestione della \textsl{maschera dei segnali} o 
   \textit{signal mask}}
 \label{sec:sig_sigmask}
 
 Come spiegato in \secref{sec:sig_semantics} tutti i moderni sistemi unix-like

-permettono si bloccare temporaneamente (o di eliminare completamente, impostando
-\macro{SIG\_IGN} come azione) la consegna dei segnali ad un processo. Questo è
-fatto specificando la cosiddetta \textsl{maschera dei segnali} (o
-\textit{signal mask}) del processo\footnote{nel caso di Linux essa è mantenuta
-  dal campo \var{blocked} della \var{task\_struct} del processo.} cioè
-l'insieme dei segnali la cui consegna è bloccata. Abbiamo accennato in
-\secref{sec:proc_fork} che la \textit{signal mask} viene ereditata dal padre
-alla creazione di un processo figlio, e abbiamo visto al paragrafo precedente
-che essa può essere modificata, durante l'esecuzione di un gestore,
-attraverso l'uso dal campo \var{sa\_mask} di \var{sigaction}.
+permettono si bloccare temporaneamente (o di eliminare completamente,
+impostando \macro{SIG\_IGN} come azione) la consegna dei segnali ad un
+processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei
+  segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux
+  essa è mantenuta dal campo \var{blocked} della \var{task\_struct} del
+  processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
+accennato in \secref{sec:proc_fork} che la \textit{signal mask} viene
+ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al
+paragrafo precedente che essa può essere modificata, durante l'esecuzione di
+un gestore, attraverso l'uso dal campo \var{sa\_mask} di \var{sigaction}.

 
 Uno dei problemi evidenziatisi con l'esempio di \secref{fig:sig_event_wrong} è
 che in molti casi è necessario proteggere delle sezioni di codice (nel caso in
 
 Uno dei problemi evidenziatisi con l'esempio di \secref{fig:sig_event_wrong} è
 che in molti casi è necessario proteggere delle sezioni di codice (nel caso in