+Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità
+il cui scopo è quello di permettere ad un utente di poter sfruttare le
+capacità multitasking di un sistema Unix per eseguire in contemporanea più
+processi, pur potendo accedere, di solito, ad un solo terminale,\footnote{con
+ X e con i terminali vituali tutto questo non è più vero, dato che si può
+ accedere a molti terminali in contemporanea, ma il sistema è nato prima
+ dell'esistenza di tutto ciò.} avendo cioè un solo punto in cui si può avere
+accesso all'input ed all'output degli stessi.
+
+
+\subsection{Una panoramica introduttiva}
+\label{sec:sess_job_control_overview}
+
+Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
+negli anni '80, e successivamente standardizzata da POSIX.1; la sua
+disponibilità nel sistema è verificabile attraverso il controllo della macro
+\macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il
+supporto sia da parte della shell (quasi tutte ormai lo fanno), che da parte
+del kernel; in particolare il kernel deve assicurare sia la presenza di un
+driver per i terminali abilitato al \textit{job control} che quella dei
+relativi segnali illustrati in \secref{sec:sig_job_control}.
+
+In un sistema che supporta il \textit{job cotrol} una volta completato il
+login (che esamineremo in dettaglio in \secref{sec:sess_login}), l'utente avrà
+a disposizione una shell dalla quale eseguire i comandi e potrà iniziare
+quella che viene chiamata una \textsl{sessione}, che riunisce (vedi
+\secref{sec:sess_sessions}) tutti i processi eseguiti all'interno dello stesso
+login.
+
+Siccome la shell è collegata ad un solo terminale (il \textsl{terminale di
+ controllo}, vedi \secref{sec:sess_control_term}) solo un comando alla volta,
+quello che viene detto in \textit{foreground}, potrà scrivere e leggere dal
+terminale. La shell però può eseguire anche più comandi in contemporanea,
+mandandoli in \textit{background} (si fa aggiungendo una \cmd{\&} alla fine
+del comando), nel qual caso essi saranno eseguiti senza essere collegati al
+terminale.
+
+Si noti come si sia parlato di comandi e non di programmi o processi; fra le
+funzionalità della shell infatti c'è anche quella di consentire di concatenare
+più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
+eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
+questo potrà sempre lanciare altri processi per eseguire dei compiti
+specifici.
+
+Per questo l'esecuzione di un comando può originare più di un processo; quindi
+nella gestione del job control non si può far riferimento ai singoli processi,
+per questo il kernel prevede la possibilità di raggruppare più processi in un
+\textit{process group} (detto anche \textsl{raggruppamento}, vedi
+\secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
+originano da una riga di comando appartengano allo stesso \textit{process
+ group}, in modo che le varie funzioni di controllo, ed i segnali inviati dal
+terminale, possano fare riferimento ad esso.
+
+In generale allora all'interno di una sessione avremo un solo \textit{process
+ group} in \textit{foreground}, che riunisce i processi che possono accedere
+al terminale, e più \textit{process group} in \textit{background}, che non
+possono accedervi. Il job control prevede che quando un processo appartenente
+ad un raggruppamento in \textit{background} cerca di accedere al terminale
+questo invii a tutti i processi del raggruppamento un segnale di
+\macro{SIGTTIN} o di \macro{SIGTTOU} (a seconda che l'accesso sia in lettura o
+scrittura)
+
+
+
+
+
+
+
+
+
+
+
+
+\subsection{I \textit{process group}}
+\label{sec:sess_proc_group}