Ma anche questa implementazione comporta dei problemi; in questo caso infatti
non viene gestita correttamente l'interazione con gli altri segnali; se
-infatti il segnale di allarme interrompe un altro gestore, in questo caso
-l'esecuzione non riprenderà nel gestore in questione, ma nel ciclo
-principale, interrompendone inopportunamente l'esecuzione. Lo stesso tipo di
-problemi si presenterebbero se si volesse usare \func{alarm} per stabilire un
-timeout su una qualunque system call bloccante.
+infatti il segnale di allarme interrompe un altro gestore, l'esecuzione non
+riprenderà nel gestore in questione, ma nel ciclo principale, interrompendone
+inopportunamente l'esecuzione. Lo stesso tipo di problemi si presenterebbero
+se si volesse usare \func{alarm} per stabilire un timeout su una qualunque
+system call bloccante.
Un secondo esempio è quello in cui si usa il segnale per notificare una
qualche forma di evento; in genere quello che si fa in questo caso è impostare
nel gestore un opportuno flag da controllare nel corpo principale del
programma (con un codice del tipo di quello riportato in
-fig.~\ref{fig:sig_event_wrong}).
+fig.~\ref{fig:sig_event_wrong}). La logica è quella di far impostare al
+gestore (\texttt{\small 14-19}) una variabile globale preventivamente
+inizializzata nel programma principale, il quale potrà determinare,
+osservandone il contenuto, l'occorrenza o meno del segnale, e prendere le
+relative azioni conseguenti (\texttt{\small 6-11}).
\begin{figure}[!htb]
\footnotesize\centering
\label{fig:sig_event_wrong}
\end{figure}
-La logica è quella di far impostare al gestore (\texttt{\small 14-19}) una
-variabile globale preventivamente inizializzata nel programma principale, il
-quale potrà determinare, osservandone il contenuto, l'occorrenza o meno del
-segnale, e prendere le relative azioni conseguenti (\texttt{\small 6-11}).
-
Questo è il tipico esempio di caso, già citato in
sez.~\ref{sec:proc_race_cond}, in cui si genera una \itindex{race~condition}
\textit{race condition}; infatti, in una situazione in cui un segnale è già
L'uso di questo campo permette ad esempio di risolvere il problema residuo
dell'implementazione di \code{sleep} mostrata in
fig.~\ref{fig:sig_sleep_incomplete}. In quel caso infatti se il segnale di
-allarme avesse interrotto un altro gestore questo non sarebbe stato
-eseguito correttamente; la cosa poteva essere prevenuta installando gli altri
-gestori usando \var{sa\_mask} per bloccare \const{SIGALRM} durante la
-loro esecuzione. Il valore di \var{sa\_flag} permette di specificare vari
-aspetti del comportamento di \func{sigaction}, e della reazione del processo
-ai vari segnali; i valori possibili ed il relativo significato sono riportati
-in tab.~\ref{tab:sig_sa_flag}.
+allarme avesse interrotto un altro gestore questo non sarebbe stato eseguito
+correttamente; la cosa poteva essere prevenuta installando gli altri gestori
+usando \var{sa\_mask} per bloccare \const{SIGALRM} durante la loro esecuzione.
+Il valore di \var{sa\_flag} permette di specificare vari aspetti del
+comportamento di \func{sigaction}, e della reazione del processo ai vari
+segnali; i valori possibili ed il relativo significato sono riportati in
+tab.~\ref{tab:sig_sa_flag}.
\begin{table}[htb]
\footnotesize
fermato da uno dei segnali \const{SIGSTOP},
\const{SIGTSTP}, \const{SIGTTIN} o
\const{SIGTTOU}.\\
- \const{SA\_ONESHOT} & Ristabilisce l'azione per il segnale al valore
+ \const{SA\_RESETHAND}& Ristabilisce l'azione per il segnale al valore
predefinito una volta che il gestore è stato
lanciato, riproduce cioè il comportamento della
semantica inaffidabile.\\
- \const{SA\_RESETHAND}& Sinonimo di \const{SA\_ONESHOT}. \\
+ \const{SA\_ONESHOT} & Nome obsoleto, sinonimo non standard di
+ \const{SA\_RESETHAND}; da evitare. \\
+ \const{SA\_ONSTACK} & Stabilisce l'uso di uno \itindex{stack} stack
+ alternativo per l'esecuzione del gestore (vedi
+ sez.~\ref{sec:sig_specific_features}).\\
\const{SA\_RESTART} & Riavvia automaticamente le \textit{slow system
call} quando vengono interrotte dal suddetto
segnale; riproduce cioè il comportamento standard
di BSD.\index{system~call~lente}\\
- \const{SA\_NOMASK} & Evita che il segnale corrente sia bloccato durante
+ \const{SA\_NODEFER} & Evita che il segnale corrente sia bloccato durante
l'esecuzione del gestore.\\
- \const{SA\_NODEFER} & Sinonimo di \const{SA\_NOMASK}.\\
+ \const{SA\_NOMASK} & Nome obsoleto, sinonimo non standard di
+ \const{SA\_NODEFER}.\\
\const{SA\_SIGINFO} & Deve essere specificato quando si vuole usare un
gestore in forma estesa usando
- \var{sa\_sigaction} al posto di \var{sa\_handler}.\\
- \const{SA\_ONSTACK} & Stabilisce l'uso di uno \itindex{stack} stack
- alternativo per l'esecuzione del gestore (vedi
- sez.~\ref{sec:sig_specific_features}).\\
+ \var{sa\_sigaction} al posto di
+ \var{sa\_handler}.\\
+ \const{SA\_NOCLDWAIT}& Se il segnale è \const{SIGCHLD} allora o processi
+ figli non divenire \textit{zombie} quando
+ terminano.\footnotemark \\
\hline
\end{tabular}
\caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
\label{tab:sig_sa_flag}
\end{table}
+\footnotetext{questa funzionalità è stata introdotta nel kernel 2.6 e va a
+ modificare il comportamento di \func{waitpid}.}
+
% TODO con il 2.6 sono stati aggiunti SA_NOCLDWAIT e altro, documentare
Come si può notare in fig.~\ref{fig:sig_sigaction} \func{sigaction} permette
projects / gapil.git / blobdiff