all'occorrenza del segnale, può assumere anche i due valori costanti
\const{SIG\_IGN} con cui si dice ignorare il segnale e \const{SIG\_DFL} per
reinstallare l'azione predefinita.\footnote{si ricordi però che i due segnali
- \const{SIGKILL} e \const{SIGSTOP} non possono essere ignorati né
+ \const{SIGKILL} e \const{SIGSTOP} non possono essere né ignorati né
intercettati; l'uso di \const{SIG\_IGN} per questi segnali non ha alcun
effetto.}
questo può essere usato per cancellare una programmazione precedente.
La funzione inoltre ritorna il numero di secondi rimanenti all'invio
-dell'allarme precedentemente programmato, in modo che sia possibile
-controllare se non si cancella un precedente allarme ed eventualmente
-predisporre le opportune misure per gestire il caso di necessità di più
-interruzioni.
+dell'allarme programmato in precedenza. In questo modo è possibile controllare
+se non si è cancellato un precedente allarme ed predisporre eventuali misure
+che permettano di gestire il caso in cui servono più interruzioni.
In sez.~\ref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono
associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed
di 1/\const{HZ}.
In realtà è possibile ottenere anche pause più precise del centesimo di
-secondo usando politiche di scheduling real time come \const{SCHED\_FIFO} o
+secondo usando politiche di scheduling real-time come \const{SCHED\_FIFO} o
\const{SCHED\_RR}; in tal caso infatti il meccanismo di scheduling ordinario
viene evitato, e si raggiungono pause fino ai 2~ms con precisioni del $\mu$s.
gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione
di zombie\index{zombie}.
-% è pertanto
-% naturale usare un esempio che ci permette di concludere la trattazione della
-% terminazione dei processi.
-% In questo caso si è tratterà di illustrare un esempio relativo ad un
-% gestore per che è previsto ritornare,
-
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
\end{minipage}
\normalsize
\caption{Codice di una funzione generica di gestione per il segnale
- \texttt{SIGCHLD}.}
+ \texttt{SIGCHLD}.}
\label{fig:sig_sigchld_handl}
\end{figure}
\var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore
(\texttt{\small 16--17}). In questo modo si preserva il valore della variabile
visto dal corso di esecuzione principale del processo, che altrimenti sarebbe
-sovrascritto dal valore restituito nella successiva chiamata di \func{wait}.
+sovrascritto dal valore restituito nella successiva chiamata di \func{waitpid}.
Il compito principale del gestore è quello di ricevere lo stato di
terminazione del processo, cosa che viene eseguita nel ciclo in
che molti processi figli terminino in rapida successione. Esso inoltre si
presenta tutte le volte che un segnale viene bloccato: per quanti siano i
segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà
-rimosso sarà recapitato un solo segnale.
+rimosso verrà recapitato un solo segnale.
Allora, nel caso della terminazione dei processi figli, se si chiamasse
\func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
Questo codice però, a parte il non gestire il caso in cui si è avuta una
precedente chiamata a \func{alarm} (che si è tralasciato per brevità),
presenta una pericolosa race condition\index{\textit{race~condition}}.
-Infatti se il processo viene interrotto fra la chiamata di \func{alarm} e
-\func{pause} può capitare (ad esempio se il sistema è molto carico) che il
+Infatti, se il processo viene interrotto fra la chiamata di \func{alarm} e
+\func{pause}, può capitare (ad esempio se il sistema è molto carico) che il
tempo di attesa scada prima dell'esecuzione di quest'ultima, cosicché essa
sarebbe eseguita dopo l'arrivo di \const{SIGALRM}. In questo caso ci si
troverebbe di fronte ad un deadlock\index{\textit{deadlock}}, in quanto
Questo è il tipico esempio di caso, già citato in
sez.~\ref{sec:proc_race_cond}, in cui si genera una
-\index{\textit{race~condition}}race condition; se infatti il segnale arriva
-immediatamente dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima
-della cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà
-perduta.
+\index{\textit{race~condition}}race condition; infatti, in una situazione in
+cui un segnale è già arrivato (e \var{flag} è già ad 1) se un altro segnale
+segnale arriva immediatamente dopo l'esecuzione del controllo (\texttt{\small
+ 6}) ma prima della cancellazione del flag (\texttt{\small 7}), la sua
+occorrenza sarà perduta.
Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono
funzioni più sofisticate di quelle illustrate finora, che hanno origine dalla
\index{\textit{signal mask}|(}
Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like
-permettono si bloccare temporaneamente (o di eliminare completamente,
+permettono di bloccare temporaneamente (o di eliminare completamente,
impostando \const{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
In genere si installa uno stack alternativo per i segnali quando si teme di
avere problemi di esaurimento dello stack standard o di superamento di un
-limite imposto con chiamata de tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}.
+limite imposto con chiamate del tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}.
In tal caso infatti si avrebbe un segnale di \const{SIGSEGV}, che potrebbe
essere gestito soltanto avendo abilitato uno stack alternativo.
disponibile anche con i segnali ordinari) si applicano solo ai nuovi segnali
real-time; questi ultimi sono accessibili in un range di valori specificati
dalle due macro \const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di
- solito il primo valore è 32, ed il secondo \code{\_NSIG-1}, che di norma è
- 63, per un totale di 32 segnali disponibili, contro gli almeno 8 richiesti
- da POSIX.1b.} che specificano il numero minimo e massimo associato ad un
-segnale real-time.
+ solito (cioè sulla piattaforma i386) il primo valore è 33, ed il secondo
+ \code{\_NSIG-1}, che di norma è 64, per un totale di 32 segnali disponibili,
+ contro gli almeno 8 richiesti da POSIX.1b.} che specificano il numero minimo
+e massimo associato ad un segnale real-time.
I segnali con un numero più basso hanno una priorità maggiore e vengono
consegnati per primi, inoltre i segnali real-time non possono interrompere
forma estesa \var{sa\_sigaction} (vedi sez.~\ref{sec:sig_sigaction}). In
questo modo tutti i segnali real-time possono restituire al gestore una serie
di informazioni aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui
-definizione abbiamo già visto in fig.~\ref{fig:sig_siginfo_t}, nella
+definizione è stata già vista in fig.~\ref{fig:sig_siginfo_t}, nella
trattazione dei gestori in forma estesa.
In particolare i campi utilizzati dai segnali real-time sono \var{si\_pid} e
\end{figure}
A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad
-inviare segnali real-time, poichè non è in grado di fornire alcun valore
+inviare segnali real-time, poiché non è in grado di fornire alcun valore
per \struct{sigval\_t}; per questo motivo lo standard ha previsto una nuova
funzione, \funcd{sigqueue}, il cui prototipo è:
\begin{prototype}{signal.h}
projects / gapil.git / blobdiff