-\textit{process group} \param{pidgrp} ed è è sostanzialmente equivalente
-all'esecuzione di \code{kill(-pidgrp, signal)}.
-
-Oltre a queste funzioni di base vedremo più avanti che esistono altre funzioni
-per inviare segnali, 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}.
-
-Ma indipendentemente dalla funzione usata solo l'amministratore può inviare un
-segnale ad un processo qualunque, in tutti gli altri casi l'\ids{UID} reale o
-l'\ids{UID} effettivo del processo chiamante devono corrispondere
-all'\ids{UID} reale o all'\ids{UID} salvato della destinazione. Fa eccezione
-il caso in cui il segnale inviato sia \signal{SIGCONT}, nel quale occorre che
-entrambi i processi appartengano alla stessa sessione. Inoltre, dato il ruolo
-fondamentale che riveste nel sistema (si ricordi quanto visto in
-sez.~\ref{sec:sig_termination}), 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.
-
-
-\subsection{Le funzioni di allarme ed interruzione ed i \textit{timer}}
+\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}.
+
+
+
+
+\subsection{Le funzioni di allarme ed i \textit{timer}}