X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=bfacf64b642354ca7d488b2dda271551c3683cc1;hp=ebcdbef2cebd2cc6c8c514c2a6403cb968a43575;hb=aa515f91c33e598ff4e139c070dc938bc5134801;hpb=44a112f13a7e1de880afe960be56cd34131e2cd8

diff --git a/signal.tex b/signal.tex
index ebcdbef..bfacf64 100644
--- a/signal.tex
+++ b/signal.tex
@@ -1240,12 +1240,66 @@ segnale 
   \var{errno} a \macro{EINTR}.}
 \end{prototype}
 
+La funzione segnala sempre una condizione di errore (il successo sarebbe
+quello di aspettare indefinitamente). In genere si usa questa funzione quando
+si vuole mettere un processo in attesa di un qualche evento specifico che non
+è sotto il suo diretto controllo (ad esempio la si può usare per far reagire
+il processo ad un segnale inviato da un altro processo).
 
 
+Se invece si vuole fare attendere un processo per un determinato intervallo di
+tempo lo standard POSIX.1 definisce la funzione \func{sleep}, il cui prototipo
+è:
+\begin{prototype}{unistd.h}{unsigned int sleep(unsigned int seconds)}
+  
+  Pone il processo in stato di sleep per \param{seconds} secondi.
+  
+  \bodydesc{La funzione restituisce zero se l'attesa viene completata, o il
+  numero di secondi restanti se viene interrotta da un segnale.}
+\end{prototype}
+
+La funzione attende per il tempo specificato, a meno di non essere interrotta
+da un segnale. In questo caso non è una buona idea ripetere la chiamata per il
+tempo rimanente, in quanto la riattivazione del processo può avvenire in un
+qualunque momento, ma il valore restituito sarà sempre arrotondato al secondo,
+con la conseguenza che, se la successione dei segnali è particolarmente
+sfortunata, si potranno avere ritardi anche di parecchi secondi. In genere la
+scelta più sicura è quella di stabilire un termine per l'attesa, e ricalcolare
+tutte le volte il numero di secondi da aspettare.
+
+In alcune implementazioni inoltre l'uso di \func{sleep} può avere conflitti
+con quello di \macro{SIGALRM}, dato che la funzione può essere realizzata
+attraverso \func{pause} e \func{alarm} (in maniera analoga all'esempio che
+vedremo fra poco). In tal caso mescolare chiamata di \func{alarm} e
+\func{sleep} o modificare l'azione di \macro{SIGALRM}, può causare risultati
+indefiniti. Nel caso delle \acr{glibc} è stata usata una implementazione
+completamente indipendente e questi problemi non ci sono.
+
+La granularità di \func{sleep} è 
+
+
+
+Come accennato è possibile implementare \func{sleep} a partire da dall'uso di
+\func{pause} e \func{alarm}; 
+
 
-\subsection{Le semantiche di \macro{SIGCHLD}}
+\subsection{La gestione di \macro{SIGCHLD}}
 \label{sec:sig_sigchld}
 
+Un semplice esempio per illustrare il funzionamento di un manipolatore di
+segnale è quello della gestione di \macro{SIGCHLD}.  Abbiamo visto in
+\secref{sec:proc_termination} che una delle azioni eseguite dal kernel alla
+conclusione di un processo è quella di inviare questo segnale al
+padre;\footnote{in realtà in SRV4 eredita la semantica di System V, in cui il
+  segnale si chiama \macro{SIGCLD} e viene trattato in maniera speciale; se si
+  setta esplicitamente l'azione a \macro{SIG_IGN} il segnale non viene
+  generato ed il sistema non genera zombie (lo stato di terminazione viene
+  scartato senza dover chiamare una wait), l'azione di default è sempre quella
+  di ignorare il segnale, ma non attiva questo comportamento. Linux, come BSD
+  e POSIX, non supporta questa semantica ed usa il nome di \macro{SIGCLD} come
+  sinonimo di \macro{SIGCHLD}.} è pertanto naturale completare qui la
+trattazione della terminazione dei processi illustrando le modalità per
+gestire questo segnale.