+\signal{SIGCONT}, nel quale occorre anche che entrambi i processi appartengano
+alla stessa sessione.
+
+Si tenga presente che, per il ruolo fondamentale che riveste nel sistema, non
+è possibile inviare al processo 1 (cioè a \cmd{init}) segnali per i quali esso
+non abbia un gestore installato. Infine, seguendo le specifiche POSIX
+1003.1-2001, l'uso della chiamata \code{kill(-1, sig)} comporta che il segnale
+sia inviato (con la solita eccezione di \cmd{init}) a tutti i processi per i
+quali i permessi lo consentano. Lo standard permette comunque alle varie
+implementazioni di escludere alcuni processi specifici: nel caso in questione
+Linux non invia il segnale al processo che ha effettuato la chiamata.
+
+Si noti pertanto che la funzione \code{raise(sig)} può essere definita in
+termini di \func{kill}, ed è sostanzialmente equivalente ad una
+\code{kill(getpid(), sig)}. Siccome \func{raise}, che è definita nello
+standard ISO C, non esiste in alcune vecchie versioni di Unix, in generale
+l'uso di \func{kill} finisce per essere più portabile. Una seconda funzione
+che può essere definita in termini di \func{kill} è \funcd{killpg}, il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{signal.h}
+\fdecl{int killpg(pid\_t pidgrp, int signal)}
+\fdesc{Invia un segnale ad un \itindex{process~group} \textit{process group}.}
+}
+
+{ La funzione ritorna $0$ in caso di successo e $-1$ per un errore, e gli
+ errori sono gli stessi di \func{kill}.
+}
+\end{funcproto}
+
+
+La funzione invia il segnale \param{signal} al \itindex{process~group}
+\textit{process group} il cui \acr{PGID} (vedi sez.~\ref{sec:sess_proc_group})
+è indicato dall'argomento \param{pidgrp}, che deve essere un intero
+positivo. Il suo utilizzo è sostanzialmente equivalente all'esecuzione di
+\code{kill(-pidgrp, signal)}.
+
+Oltre alle precedenti funzioni di base, vedremo più avanti che esistono altre
+funzioni per inviare segnali generici, come \func{sigqueue} per i segnali
+\textit{real-time} (vedi sez.~\ref{sec:sig_real_time}) e le specifiche
+funzioni per i \textit{thread} che tratteremo in sez.~\ref{sec:thread_signal}.
+
+Esiste però un'ultima funzione che permette l'invio diretto di un segnale che
+vale la pena di trattare a parte per le sue peculiarità. La funzione in
+questione è \funcd{abort} che, come accennato in
+sez.~\ref{sec:proc_termination}, permette di abortire l'esecuzione di un
+programma tramite l'invio del segnale \signal{SIGABRT}. Il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{void abort(void)}
+\fdesc{Abortisce il processo corrente.}
+}
+
+{La funzione non ritorna, il processo viene terminato.}
+\end{funcproto}
+
+La differenza fra questa funzione e l'uso di \func{raise} o di un'altra
+funzione per l'invio di \signal{SIGABRT} è che anche se il segnale è bloccato
+o ignorato, la funzione ha effetto lo stesso. Il segnale può però essere
+intercettato per effettuare eventuali operazioni di chiusura prima della
+terminazione del processo.
+
+Lo standard ANSI C richiede inoltre che anche se il gestore ritorna, la
+funzione non ritorni comunque. Lo standard POSIX.1 va oltre e richiede che se
+il processo non viene terminato direttamente dal gestore sia la stessa
+\func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo
+standard POSIX, prima della terminazione tutti i file aperti e gli stream
+saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le
+eventuali funzioni registrate con \func{atexit} e \func{on\_exit}.
+