\const{SIGPROF} &SL & A & Timer del profiling scaduto \\
\const{SIGSYS} &SL & C & Argomento sbagliato per una subroutine (SVID) \\
\const{SIGTRAP} &SL & C & Trappole per un Trace/breakpoint \\
- \const{SIGURG} &SLB& B & Ricezione di una urgent condition su un socket\\
+ \const{SIGURG} &SLB& B & Ricezione di una \textit{urgent condition} su
+ un socket\index{socket}\\
\const{SIGVTALRM}&SLB& A & Virtual alarm clock \\
\const{SIGXCPU} &SLB& C & Ecceduto il limite sul CPU time \\
\const{SIGXFSZ} &SLB& C & Ecceduto il limite sulla dimensione dei file \\
In genere si intercettano questi segnali per permettere al programma di
terminare in maniera pulita, ad esempio per ripristinare le impostazioni della
-console o eliminare i file di lock prima dell'uscita. In questo caso il
-gestore deve concludersi ripristinando l'azione predefinita e rialzando il
-segnale, in questo modo il programma si concluderà senza effetti spiacevoli,
-ma riportando lo stesso stato di uscita che avrebbe avuto se il gestore non ci
-fosse stato.
+console o eliminare i file di lock\index{file!di lock} prima dell'uscita. In
+questo caso il gestore deve concludersi ripristinando l'azione predefinita e
+rialzando il segnale, in questo modo il programma si concluderà senza effetti
+spiacevoli, ma riportando lo stesso stato di uscita che avrebbe avuto se il
+gestore non ci fosse stato.
L'azione predefinita per tutti questi segnali è causare la terminazione del
processo che li ha causati. In genere oltre a questo il segnale provoca pure
L'azione predefinita è di essere ignorati. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\const{SIGIO}] Questo segnale viene inviato quando un file descriptor è
- pronto per eseguire dell'input/output. In molti sistemi solo i socket e i
- terminali possono generare questo segnale, in Linux questo può essere usato
- anche per i file, posto che la \func{fcntl} abbia avuto successo.
+ pronto per eseguire dell'input/output. In molti sistemi solo i
+ socket\index{socket} e i terminali possono generare questo segnale, in Linux
+ questo può essere usato anche per i file, posto che la \func{fcntl} abbia
+ avuto successo.
\item[\const{SIGURG}] Questo segnale è inviato quando arrivano dei dati
- urgenti o \textit{out of band} su di un socket; per maggiori dettagli al
- proposito si veda \secref{sec:xxx_urgent_data}.
+ urgenti o \textit{out of band} su di un socket\index{socket}; per maggiori
+ dettagli al proposito si veda \secref{sec:xxx_urgent_data}.
\item[\const{SIGPOLL}] Questo segnale è equivalente a \const{SIGIO}, è
definito solo per compatibilità con i sistemi System V.
\end{basedescript}
presenta questa situazione è il seguente:
\begin{itemize}
\item la lettura da file che possono bloccarsi in attesa di dati non ancora
- presenti (come per certi file di dispositivo, i socket o le pipe).
+ presenti (come per certi file di dispositivo\index{file!di dispositivo}, i
+ socket\index{socket} o le pipe).
\item la scrittura sugli stessi file, nel caso in cui dati non possano essere
accettati immediatamente.
\item l'apertura di un file di dispositivo che richiede operazioni non
padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
segnale si chiama \const{SIGCLD} e viene trattato in maniera speciale; in
System V infatti se si imposta esplicitamente l'azione a \const{SIG\_IGN} il
- segnale non viene generato ed il sistema non genera zombie (lo stato di
- terminazione viene scartato senza dover chiamare una \func{wait}). L'azione
- predefinita è 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 \const{SIGCLD} come sinonimo di \const{SIGCHLD}.} In generale
-dunque, quando non interessa elaborare lo stato di uscita di un processo, si
-può completare la gestione della terminazione installando un gestore per
-\const{SIGCHLD} il cui unico compito sia quello chiamare \func{waitpid} per
-completare la procedura di terminazione in modo da evitare la formazione di
-zombie.
+ segnale non viene generato ed il sistema non genera zombie\index{zombie} (lo
+ stato di terminazione viene scartato senza dover chiamare una \func{wait}).
+ L'azione predefinita è 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 \const{SIGCLD} come sinonimo di \const{SIGCHLD}.} In
+generale dunque, quando non interessa elaborare lo stato di uscita di un
+processo, si può completare la gestione della terminazione installando un
+gestore per \const{SIGCHLD} il cui unico compito sia quello chiamare
+\func{waitpid} per completare la procedura di terminazione in modo da evitare
+la formazione di zombie\index{zombie}.
In \figref{fig:sig_sigchld_handl} è mostrato il codice contenente una
implementazione generica di una routine di gestione per \const{SIGCHLD}, (che
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 \const{SIGCHLD}) potremo verificare che non si ha più la creazione
-di zombie.
+di zombie\index{zombie}.
% è pertanto
% naturale usare un esempio che ci permette di concludere la trattazione della
Allora, nel caso della terminazione dei processi figli, se si chiamasse
\func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
solo processo, anche se i processi terminati sono più di uno, e gli altri
-resterebbero in stato di zombie per un tempo indefinito.
+resterebbero in stato di zombie\index{zombie} per un tempo indefinito.
Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
ritorni un valore nullo, segno che non resta nessun processo di cui si debba
capitare (ad esempio se il sistema è molto carico) che il tempo di attesa
scada prima dell'esecuzione quest'ultima, cosicché essa sarebbe eseguita dopo
l'arrivo di \const{SIGALRM}. In questo caso ci si troverebbe di fronte ad un
-deadlock, in quanto \func{pause} non verrebbe mai più interrotta (se non in
-caso di un altro segnale).
+deadlock\index{deadlock}, in quanto \func{pause} non verrebbe mai più
+interrotta (se non in caso di un altro segnale).
Questo problema può essere risolto (ed è la modalità con cui veniva fatto in
SVr2) usando la funzione \func{longjmp} (vedi \secref{sec:proc_longjmp}) per
\const{SIGSEGV} e \const{SIGBUS} avvalorano \var{si\_addr} con l'indirizzo cui
è avvenuto l'errore, \const{SIGIO} (vedi \secref{sec:file_asyncronous_io})
avvalora \var{si\_fd} con il numero del file descriptor e \var{si\_band} per i
-dati urgenti su un socket.
+dati urgenti su un socket\index{socket}.
Benché sia possibile usare nello stesso programma sia \func{sigaction} che
\func{signal} occorre molta attenzione, in quanto le due funzioni possono
\item Ripristinare la maschera dei segnali originaria.
\end{enumerate*}
Per quanto possa sembrare strano bloccare la ricezione di un segnale per poi
-riabilitarla immediatamente dopo, in questo modo si evita il deadlock dovuto
-all'arrivo del segnale prima dell'esecuzione di \func{sigsuspend}.
+riabilitarla immediatamente dopo, in questo modo si evita il
+deadlock\index{deadlock} dovuto all'arrivo del segnale prima dell'esecuzione
+di \func{sigsuspend}.
\subsection{Ulteriori funzioni di gestione}
projects / gapil.git / blobdiff