Finito di aspettare ... quasi.
authorSimone Piccardi <piccardi@gnulinux.it>
Fri, 21 Sep 2001 17:10:51 +0000 (17:10 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Fri, 21 Sep 2001 17:10:51 +0000 (17:10 +0000)
gapil.tex
intro.tex
macro.tex
prochand.tex
signal.tex
sources/ForkTest.c

index 7fd9225..f3c1743 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -1,4 +1,4 @@
-%
+%
 %% GaPiL : Guida alla Programmazione in Linux
 %%
 %% S. Piccardi Feb. 2001
 \include{filedir}
 \include{fileunix}
 \include{filestd}
+\include{session}
 \include{signal}
 \include{ipc}
 \include{network}
index 634c3cb..5dfa21a 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -19,7 +19,7 @@ In questa prima sezione faremo una panoramica sulla struttura di un sistema
 \textit{unix-like} come GNU/Linux.  Chi avesse già una conoscenza di questa
 materia può tranquillamente saltare questa sezione.
 
-Il concetto base di un sistema unix-like é quello di un nucleo del sistema (il
+Il concetto base di un sistema unix-like è quello di un nucleo del sistema (il
 cosiddetto \textit{kernel}) a cui si demanda la gestione delle risorse
 essenziali (la CPU, la memoria, le periferiche) mentre tutto il resto, quindi
 anche la parte che prevede l'interazione con l'utente, deve venire realizzato
@@ -433,5 +433,6 @@ numerico alla costante simbolica. In particolare si 
 
   \end{lstlisting}
   \caption{Codice per la stampa del messaggio di errore standard.}
-  \label{fig:proc_fork_code}
+  \label{fig:intro_err_mess}
 \end{figure}
+
index 64b7656..5c69ae2 100644 (file)
--- a/macro.tex
+++ b/macro.tex
@@ -97,8 +97,8 @@ tab.~\thechapter.\theusercount}
 \newcommand{\funcdecl}[1]{\item\texttt{#1}\par}
 \newenvironment{functions}
 {% defining what is done by \begin
-  \center
   \footnotesize
+  \center
   \begin{minipage}[c]{14cm}
   \begin{description}{}{} 
 
index 23dd77c..3b79276 100644 (file)
@@ -27,42 +27,85 @@ generazione di nuovi processi 
 caratteristiche di unix (che esamineremo in dettaglio più avanti) è che
 qualunque processo può a sua volta generarne altri, detti processi figli
 (\textit{child process}). Ogni processo è identificato presso il sistema da un
-numero unico, il \acr{pid} (da \textit{process identifier}).
+numero unico, il cosiddetto \textit{process identifier} o, più brevemente, 
+\acr{pid}.
 
 Una seconda caratteristica è che la generazione di un processo è una
 operazione separata rispetto al lancio di un programma. In genere la sequenza
-è sempre quella di creare un nuovo processo, il quale si eseguirà, in un passo
+è sempre quella di creare un nuovo processo, il quale eseguirà, in un passo
 successivo, il programma voluto: questo è ad esempio quello che fa la shell
 quando mette in esecuzione il programma che gli indichiamo nella linea di
 comando.
 
 Una terza caratteristica è che ogni processo viene sempre generato da un altro
-che viene chiamato processo genitore (\textit{parent process}). Questo vale
-per tutti i processi, con una eccezione (dato che ci deve essere un punto di
-partenza), esiste sempre infatti un processo speciale, che normalmente è
-\cmd{/sbin/init}, che viene lanciato dal kernel quando questo ha finito la
-fase di avvio, esso essendo il primo processo lanciato ha sempre il \acr{pid}
-uguale a 1 e non è figlio di nessuno.
-
-Questo è ovviamente un processo speciale, che in genere si occupa di far
-partire tutti gli processi altri necessari al funzionamento del sistema,
+che viene chiamato processo padre (\textit{parent process}). Questo vale per
+tutti i processi, con una sola eccezione: dato che ci deve essere un punto di
+partenza esiste sempre un processo speciale (che normalmente è
+\cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
+di avvio, essendo questo il primo processo lanciato dal sistema ha sempre il
+\acr{pid} uguale a 1 e non è figlio di nessun altro processo.
+
+Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
+partire tutti gli altri processi necessari al funzionamento del sistema,
 inoltre \cmd{init} è essenziale per svolgere una serie di compiti
 amministrativi nelle operazioni ordinarie del sistema (torneremo si alcuni di
-essi in \secref{}) e non può mai essere terminato. La struttura del sistema
-comunque consente di lanciare al posto di \cmd{init} qualunque altro programma
-(e in casi di emergenza, ad esempio se il file di \cmd{init} si fosse
-corrotto, è possibile farlo ad esempio passando la riga \cmd{init=/bin/sh}
-all'avvio).
-
-Dato che tutti i processi successivi sono comunque generati da \cmd{init} o da
-suoi figli tutto ciò comporta che, i processi sono organizzati gerarchicamente
-dalla relazione fra genitori e figli, in maniera analoga a come i file sono
-organizzati in un albero di directory con alla base \file{/} (si veda
-\secref{sec:file_file_struct}); in questo caso alla base dell'albero c'è il
-processo \cmd{init} che è progenitore di ogni altro processo\footnote{in
-  realtà questo non è del tutto vero, in Linux ci sono alcuni processi che pur
-  comparendo come figli di init (ad esempio in \cmd{pstree}) sono generati
-  direttamente dal kernel, come \cmd{keventd}, \cmd{kswapd}, etc.}.
+essi in \secref{sec:proc_termination}) e non può mai essere terminato. La
+struttura del sistema comunque consente di lanciare al posto di \cmd{init}
+qualunque altro programma (e in casi di emergenza, ad esempio se il file di
+\cmd{init} si fosse corrotto, è ad esempio possibile lanciare una shell al suo
+posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio).
+
+\begin{figure}[!htb]
+  \footnotesize
+\begin{verbatim}
+[piccardi@selidor piccardi]$ pstree -n 
+init-+-keventd
+     |-kapm-idled
+     |-kreiserfsd
+     |-portmap
+     |-syslogd
+     |-klogd
+     |-named
+     |-rpc.statd
+     |-gpm
+     |-inetd
+     |-junkbuster
+     |-master-+-qmgr
+     |        `-pickup
+     |-sshd
+     |-xfs
+     |-cron
+     |-bash---startx---xinit-+-XFree86
+     |                       `-WindowMaker-+-ssh-agent
+     |                                     |-wmtime
+     |                                     |-wmmon
+     |                                     |-wmmount
+     |                                     |-wmppp
+     |                                     |-wmcube
+     |                                     |-wmmixer
+     |                                     |-wmgtemp
+     |                                     |-wterm---bash---pstree
+     |                                     `-wterm---bash-+-emacs
+     |                                                    `-man---pager
+     |-5*[getty]
+     |-snort
+     `-wwwoffled
+\end{verbatim} %$
+  \caption{L'albero dei processi, così come riportato dal comando
+    \cmd{pstree}.}
+  \label{fig:proc_tree}
+\end{figure}
+
+Dato che tutti i processi attivi nel sistema sono comunque generati da
+\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
+  vero, in Linux ci sono alcuni processi che pur comparendo come figli di
+  init, o con \acr{pid} successivi, sono in realtà generati direttamente dal
+  kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.)} si possono classificare i
+processi con la relazione padre/figlio in una organizzazione gerarchica ad
+albero, in maniera analoga a come i file sono organizzati in un albero di
+directory (si veda \secref{sec:file_file_struct}); in \nfig\ si è mostrato il
+risultato del comando \cmd{pstree} che permette di mostrare questa struttura,
+alla cui base c'è il \cmd{init} che è progenitore di tutti gli altri processi.
 
 
 \subsection{Una panoramica sulle funzioni di gestione}
@@ -85,7 +128,7 @@ del processo.
 
 Quando un processo ha concluso il suo compito o ha incontrato un errore non
 risolvibile esso può essere terminato con la funzione \func{exit} (si veda
-quanto discusso in \secref{sec:proc_termination}). La vita del processo però
+quanto discusso in \secref{sec:proc_conclusion}). La vita del processo però
 termina solo quando la notifica della sua conclusione viene ricevuta dal
 processo padre, a quel punto tutte le risorse allocate nel sistema ad esso
 associate vengono rilasciate.
@@ -138,9 +181,8 @@ Per questo motivo processo il processo di avvio (\cmd{init}) ha sempre il
 
 Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
 sono stati creati, questo viene chiamato in genere \acr{ppid} (da
-\textit{parent process id}) ed è normalmente utilizzato per il controllo di
-sessione.  Questi due identificativi possono essere ottenuti da programma
-usando le funzioni:
+\textit{parent process id}).  Questi due identificativi possono essere
+ottenuti da programma usando le funzioni:
 \begin{functions}
 \headdecl{sys/types.h}
 \headdecl{unistd.h}
@@ -160,11 +202,12 @@ generare un pathname univoco, che non potr
 processo che usi la stessa funzione. 
 
 Tutti i processi figli dello stesso processo padre sono detti
-\textit{sibling}, questa è un'altra delle relazioni usate nel controllo di
-sessione, in cui si raggruppano tutti i processi creati su uno stesso
-terminale una volta che si è effettuato il login. Torneremo su questo
-argomento in \secref{cap:terminal}, dove esamineremo tutti gli altri
-identificativi associati ad un processo relativi al controllo di sessione.
+\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
+  sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
+o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
+\secref{cap:session}, dove esamineremo i vari identificativi associati ad un
+processo e le varie relazioni fra processi utilizzate per definire una
+sessione.
 
 
 \subsection{La funzione \func{fork}}
@@ -327,7 +370,7 @@ Se eseguiamo il comando senza specificare attese (come si pu
 otterremo come output sul terminale:
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 3
-Test for forking 3 child
+Process 1963: forking 3 child
 Spawned 1 child, pid 1964 
 Child 1 successfully executing
 Child 1, parent 1963, exiting
@@ -382,7 +425,7 @@ che otterremo 
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest 3 > output
 [piccardi@selidor sources]$ cat output
-Test for forking 3 child
+Process 1967: forking 3 child
 Child 1 successfully executing
 Child 1, parent 1967, exiting
 Test for forking 3 child
@@ -604,12 +647,12 @@ termina il kernel controlla se 
 caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
 con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
 avrà sempre un padre (nel caso \textsl{adottivo}) cui riportare il suo stato
-di terminazione.  Come verifica di questo comportamento eseguiamo il comando
-\cmd{forktest -c2 3}, in questo modo ciascun figlio attenderà due secondi
-prima di uscire, il risultato è:
+di terminazione.  Come verifica di questo comportamento possiamo eseguire il
+comando \cmd{forktest} imponendo a ciascun processo figlio due
+secondi di attesa prima di uscire, il risultato è:
 \begin{verbatim}
 [piccardi@selidor sources]$ ./forktest -c2 3
-Test for forking 3 child
+Process 1972: forking 3 child
 Spawned 1 child, pid 1973 
 Child 1 successfully executing
 Go to next child 
@@ -630,27 +673,28 @@ terminano, e come si pu
 in precedenza, essi riportano 1 come \acr{ppid}.
 
 Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
-questo perché non è detto che il padre possa ricevere immediatamente lo stato
-di terminazione, quindi il kernel deve comunque conservare una certa quantità
-di informazioni riguardo ai processi che sta terminando.
+perché non è detto che il padre possa ricevere immediatamente lo stato di
+terminazione, quindi il kernel deve comunque conservare una certa quantità di
+informazioni riguardo ai processi che sta terminando.
 
 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
 dal processo (vedi \secref{sec:intro_unix_time}) e lo stato di terminazione
-(NdA verificare esattamente cosa c'è!), mentre la memoria in uso ed i file
-aperti vengono rilasciati immediatamente. I processi che sono terminati, ma il
-cui stato di terminazione non è stato ancora ricevuto dal padre sono chiamati
-\textit{zombie}, essi restano presenti nella tabella dei processi ed in genere
-possono essere identificati dall'output di \cmd{ps} per la presenza di una
-\cmd{Z} nella colonna che ne indica lo stato. Quando il padre effettuarà la
-lettura dello stato di uscita anche questa informazione, non più necessaria,
-verrà scartata e la terminazione potrà dirsi completamente conclusa.
+\footnote{NdA verificare esattamente cosa c'è!}, mentre la memoria in uso ed i
+file aperti vengono rilasciati immediatamente. I processi che sono terminati,
+ma il cui stato di terminazione non è stato ancora ricevuto dal padre sono
+chiamati \textit{zombie}, essi restano presenti nella tabella dei processi ed
+in genere possono essere identificati dall'output di \cmd{ps} per la presenza
+di una \cmd{Z} nella colonna che ne indica lo stato. Quando il padre
+effettuarà la lettura dello stato di uscita anche questa informazione, non più
+necessaria, verrà scartata e la terminazione potrà dirsi completamente
+conclusa.
 
 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
-condizione: lanciamo il comando \cmd{forktest -e10 3 \&} in background,
-indicando al processo padre di aspettare 10 secondi prima di uscire; in questo
-caso, usando \cmd{ps} sullo stesso terminale (prima dello scadere dei 10
-secondi) otterremo:
+condizione: lanciamo il comando \cmd{forktest} in background, indicando al
+processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
+\cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
+otterremo:
 \begin{verbatim}
 [piccardi@selidor sources]$ ps T
   PID TTY      STAT   TIME COMMAND
@@ -693,13 +737,15 @@ possa adottarli e provvedere a concludere la terminazione.
 \subsection{Le funzioni \texttt{wait} e  \texttt{waitpid}}
 \label{sec:proc_wait}
 
-Abbiamo già visto in precedenza come uno degli usi possibili delle capacità
-multitasking di un sistema unix-like consiste nella creazione di programmi di
-tipo server, in cui un processo principale attende le richieste che vengono
-poi soddisfatte creando una serie di processi figli. Si è gia sottolineato
-come in questo caso diventi necessario gestire esplicitamente la conclusione
-dei vari processi figli; le funzioni deputate a questo sono sostanzialmente
-due, \func{wait} e \func{waitpid}. La prima, il cui prototipo è:
+Abbiamo già accennato come uno degli usi possibili delle capacità multitasking
+di un sistema unix-like consista nella creazione di programmi di tipo server,
+in cui un processo principale attende le richieste che vengono poi soddisfatte
+creando una serie di processi figli. Si è già sottolineato al paragrafo
+precedente come in questo caso diventi necessario gestire esplicitamente la
+conclusione dei vari processi figli onde evitare di riempire di
+\textit{zombie} la tabella dei processi; le funzioni deputate a questo compito
+sono sostanzialmente due, \func{wait} e \func{waitpid}. La prima, il cui
+prototipo è:
 \begin{functions}
 \headdecl{sys/types.h}
 \headdecl{sys/wait.h}
@@ -719,40 +765,42 @@ caso di errore; \var{errno} pu
   \end{errlist}
 \end{functions}
 è presente fin dalle prime versioni di unix; la funzione ritorna alla
-conclusione del primo figlio (o immediatamente se un figlio è già uscito), nel
+conclusione del primo figlio (o immediatamente se un figlio è già uscito). Nel
 caso un processo abbia più figli il valore di ritorno permette di identificare
 qual'è quello che è uscito.
 
 Questa funzione però ha il difetto di essere poco flessibile, in quanto
-ritorna all'uscita di un figlio qualunque, per cui se si vuole attendere la
-conclusione di un processo specifico occorre predisporre un meccanismo che
-tenga conto dei processi già terminati, e ripeta la chiamata alla funzione nel
-caso il processo cercato sia ancora attivo.
-
-Per questo motivo lo standard Posix.1 ha introdotto \func{waitpid} che
-effettua lo stesso servizio, ma dispone di una serie di funzionalità più
-ampie; il suo prototipo è:
+ritorna all'uscita di un figlio qualunque. Nelle occasioni in cui è necessario
+attendere la conclusione di un processo specifico occorre predisporre un
+meccanismo che tenga conto dei processi già terminati, e ripeta la chiamata
+alla funzione nel caso il processo cercato sia ancora attivo.
+
+Per questo motivo lo standard POSIX.1 ha introdotto la funzione \func{waitpid}
+che effettua lo stesso servizio, ma dispone di una serie di funzionalità più
+ampie, legate anche al controllo di sessione.  Dato che è possibile ottenere
+lo stesso comportamento di \func{wait} si consiglia di utilizzare sempre
+questa funzione; il suo prototipo è:
 \begin{functions}
 \headdecl{sys/types.h}
 \headdecl{sys/wait.h}
 \funcdecl{pid\_t waitpid(pid\_t pid, int * status, int options)} 
 
-La funzione restituisce il \acr{pid} del figlio che è uscito, 0 se è stata
-specificata l'opzione \macro{WNOHANG} e il figlio non è uscito e -1 per un
+La funzione restituisce il \acr{pid} del processo che è uscito, 0 se è stata
+specificata l'opzione \macro{WNOHANG} e il processo non è uscito e -1 per un
 errore, nel qual caso \var{errno} assumerà i valori:
   \begin{errlist}
-  \item \macro{EINTR} non è stata specificata l'opzione \macro{WNOHANG} e la
-    funzione è stata interrotta da un segnale.
+  \item \macro{EINTR} se non è stata specificata l'opzione \macro{WNOHANG} e
+    la funzione è stata interrotta da un segnale.
   \item \macro{ECHILD} il processo specificato da \var{pid} non esiste o non è
     figlio del processo chiamante.
   \end{errlist}
 \end{functions}
 
 Le differenze principali fra le due funzioni sono che \func{wait} si blocca
-sempre fino a che un figlio non termina, mentre \func{waitpid} ha la
-possibilità si specificare un'opzione, \macro{WNOHANG} che ne previene il
-blocco, inoltre \func{waitpid} può specificare quale figlio attendere sulla
-base del valore soecificato tramite la variabile \var{pid} secondo lo
+sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la
+possibilità si specificare un'opzione \macro{WNOHANG} che ne previene il
+blocco; inoltre \func{waitpid} può specificare quale processo attendere sulla
+base del valore specificato tramite la variabile \var{pid}, secondo lo
 specchietto riportato in \ntab:
 \begin{table}[!htb]
   \centering
@@ -761,16 +809,82 @@ specchietto riportato in \ntab:
     \textbf{Valore} & \textbf{Significato}\\
     \hline
     \hline
-    -1  & attende per un figlio qualsiasi, equivalente a \func{wait}\\ 
-    > 0 & \\
-    0   & \\
-    < -1& \\
+    $<-1$& attende per un figlio il cui \textit{process group} è uguale al
+    valore assoluto di \var{pid}. \\
+    $-1$ & attende per un figlio qualsiasi, usata in questa maniera è
+    equivalente a \func{wait}.\\ 
+    $0$  & attende per un figlio il cui \textit{process group} è uguale a
+    quello del processo chiamante. \\
+    $>0$ & attende per un figlio il cui \acr{pid} è uguale al
+    valore di \var{pid}.\\
     \hline
   \end{tabular}
-  \caption{Significato del parametro \var{pid} della funzione \func{waitpid}.}
+  \caption{Significato dei valori del parametro \var{pid} della funzione
+    \func{waitpid}.}
   \label{tab:proc_waidpid_pid}
 \end{table}
 
+Il comportamento di \func{waitpid} può essere modificato passando delle
+opportune opzioni tramite la variabile \var{option}. I valori possibili sono
+il già citato \macro{WNOHANG}, che previene il blocco della funzione quando il
+processo figlio non è terminato, e \macro{WUNTRACED} (usata per il controllo
+di sessione) che fa ritornare la funzione anche per i processi figli che sono
+bloccati ed il cui stato non è stato ancora riportato al padre. Il valore
+dell'opzione deve essere specificato come l'OR binario di zero con le suddette
+costanti.
+
+Entrambe le funzioni restituiscono lo stato di terminazione del processo
+tramite il puntatore \var{status} (se non interessa memorizzare lo stato si
+può passare un puntatore nullo). Il valore restituito da entrambe le funzioni
+dipende dall'implementazione, e tradizionalmente alcuni bit sono riservati per
+memorizzare lo stato di uscita (in genere 8) altri per indicare il segnale che
+ha causato la terminazione (in caso di conclusione anomala), uno per indicare
+se è stato generato un core file, etc.\footnote{le definizioni esatte si
+  possono trovare in \file{<bits/waitstatus.h}, che non deve mai essere usato
+  direttamente ma incluso attraverso \file{<sys/wait.h>}}.  Lo standard
+POSIX.1 definisce una serie di macro di preprocessore da usare per analizzare
+lo stato di uscita; esse sono definite in \file{<sys/wait.h>} ed elencate in
+\ntab\ (si tenga presente che queste macro prendono come parametro la
+variabile di tipo \type{int} puntata da \var{status}).
+
+
+\begin{table}[!htb]
+  \centering
+  \begin{tabular}[c]{|c|p{10cm}|}
+    \hline
+    \textbf{Macro} & \textbf{Descrizione}\\
+    \hline
+    \hline
+    \macro{WIFEXITED(s)}   & Condizione vera (valore non nullo) per un processo
+    figlio che sia terminato normalmente. \\
+    \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
+    stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit}
+    o come valore di ritorno di \func{main}). Può essere valutata solo se
+    \macro{WIFEXITED} ha restitituito un valore non nullo.\\
+    \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
+    in maniera anomala a causa di un segnale che non è stato catturato (vedi
+    \secref{sec:sig_notification}).\\
+    \macro{WTERMSIG(s)}    & restituisce il numero del segnale che ha causato
+    la terminazione anomala del processo.  Può essere valutata solo se
+    \macro{WIFSIGNALED} ha restitituito un valore non nullo.\\
+    \macro{WCOREDUMP(s)}   & Vera se il processo terminato ha generato un
+    file si \textit{core dump}. Può essere valutata solo se
+    \macro{WIFSIGNALED} ha restitituito un valore non nullo\footnote{questa
+    macro non è definita dallo standard POSIX.1, ma è presente come estensione
+    sia in Linux che in altri unix}.\\
+    \macro{WIFSTOPPED(s)}  & Vera se il processo che ha causato il ritorno di
+    \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato
+    l'opzione \macro{WUNTRACED}. \\
+    \macro{WSTOPSIG(s)}    & restituisce il numero del segnale che ha bloccato
+    il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha
+    restitituito un valore non nullo. \\
+    \hline
+  \end{tabular}
+  \caption{Descrizione delle varie macro di preprocessore utilizzabili per 
+    verificare lo stato di terminazione \var{s} di un processo.}
+  \label{tab:proc_status_macro}
+\end{table}
 
 
 Come abbiamo appena visto una delle azioni prese dal kernel alla terminazione
index cc8e1af..82e1452 100644 (file)
@@ -225,8 +225,9 @@ segnale. Per alcuni segnali (\texttt{SIGKILL} e \texttt{SIGSTOP}) questa azione
 specificare una scelta fra le tre seguenti:
 
 \begin{itemize}
-\item ignorare il segnale
-\item utilizzare il manipolatore (\textit{signal handler}) specificato
+\item ignorare il segnale.
+\item catturare il segnale, ed utilizzare il manipolatore (\textit{signal
+    handler}) specificato.
 \item accettare l'azione di default per quel segnale.
 \end{itemize}
 
index 5401e31..03ddf75 100644 (file)
@@ -26,7 +26,7 @@
  *
  * Usage: forktest -h give all info's
  *
- * $Id: ForkTest.c,v 1.5 2001/09/19 17:10:49 piccardi Exp $
+ * $Id: ForkTest.c,v 1.6 2001/09/21 17:10:51 piccardi Exp $
  *
  ****************************************************************/
 /* 
@@ -94,7 +94,7 @@ int main(int argc, char *argv[])
        usage();
     }
     nchild = atoi(argv[optind]);
-    printf("Test for forking %d child\n", nchild);
+    printf("Process %d: forking %d child\n", getpid(), nchild);
     /* loop to fork children */
     for (i=0; i<nchild; i++) {
        if ( (pid = fork()) < 0) {