+
+\section{Il \textit{job control}}
+\label{sec:sess_job_control}
+
+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_proc_group}) 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 eventuale (possono
+non esserci comandi in \textit{foreground}) \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
+rispettivamente in lettura o scrittura, bloccando (secondo il comportamenento
+di default esposto in \secref{sec:sig_job_control}) i processi.
+
+Un comportamento analogo sia ha anche per i segnali generati dai comandi di
+tastiera inviati dal terminale con \cmd{C-z}, \cmd{C-c}, \cmd{C-y} e
+\verb|C-\|; questi generano rispettivamente i segnali \macro{SIGTSTP},
+\macro{SIGINT}, \macro{SIGQUIT} e \macro{SIGTERM}, che vengono inviati a tutti
+i processi del raggruppamento in \textit{foreground}. In particolare il primo
+di essi, \macro{SIGTSTP}, interrompe l'esecuzione del comando, che può poi
+essere mandato in \textit{background} con il comando \cmd{bg}. Il comando
+\cmd{fg} consente invece di mettere in \textit{foreground} un comando
+precedentemente lanciato in \textit{background}.
+
+Di norma la shell si cura anche di notificare all'utente (di solito prima
+della stampa a video del prompt) lo stato dei vari processi, essa infatti usa
+le caratteristiche della funzione \func{waitpid} (si riveda quanto detto in
+\secref{sec:proc_wait}) per verificare quali gruppi di processi sono bloccati
+e quali sono terminati.
+
+
+\subsection{I \textit{process group} e le \textsl{sessioni}}
+\label{sec:sess_proc_group}
+
+Come accennato in \secref{sec:sess_job_control_overview} nel job control i
+processi vengono raggruppati in \textit{process group} e \textit{sessioni};
+per far questo vengono utilizzati due ulteriori identificatori (oltre quelli
+visti in \secref{sec:proc_pid}) che il kernel associa a ciascun processo:
+l'identificatore del \textit{process group} e l'identificatore della
+\textsl{sessione}, che vengono indicati rispettivamente con le sigle
+\acr{pgid} e \acr{sid}, e sono mantenuti in variabili di tipo \type{pid\_t}.
+
+Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
+stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
+le funzioni \func{getpgid} e \func{getpgrp},\footnote{\func{getpgrp} è
+ definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
+i cui prototipi sono:
+\begin{functions}
+ \headdecl{unistd.h}
+
+ \funcdecl{pid\_t getpgid(pid\_t pid)}
+ Legge il \acr{pgid} del processo \param{pid}.
+
+ \funcdecl{pid\_t getpgrp(void)}
+ Legge il \acr{pgid} del processo corrente.
+
+ \bodydesc{Le funzioni restituiscono il \acr{pgid} del processo,
+ \func{getpgrp} ha sempre successo, mentre \func{getpgid} restitusce -1
+ ponendo \var{errno} a \macro{ESRCH} se il processo selezionato non esiste.}
+\end{functions}
+
+La funzione \func{getpgid} permette di specificare il \acr{pid} del processo
+di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid}
+restiruisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
+equivalente a \code{getpgid(0)}.
+
+In maniera analoga l'identificatore della sessione può essere letto dalla
+funzione \func{getsid}, che però nelle \acr{glibc}\footnote{la system call è
+ stata introdotta in Linux a partire dalla versione 1.3.44, il supporto nelle
+ librerie del C è iniziato dalla versione 5.2.19.} è accessibile solo
+definendo \macro{\_XOPEN\_SOURCE} e \macro{\_XOPEN\_SOURCE\_EXTENDED}; il suo
+prototipo è:
+\begin{prototype}{unistd.h}{pid\_t getsid(pid\_t pid)}
+ Legge l'identificatore di sessione del processo \param{pid}.
+
+ \bodydesc{La funzione restituisce l'identificatore (un numero positivo) in
+ caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
+ i valori:
+ \begin{errlist}
+ \item[\macro{ESRCH}] Il processo selezionato non esiste.
+ \item[\macro{EPERM}] Il processo selezionato non fa parte della stessa
+ sessione del processo corrente.
+ \end{errlist}
+ }
+\end{prototype}
+
+Entrambi gli identificatori vengono inizializzati alla creazione di ciascun
+processo con lo stesso valore che hanno nel processo padre, per cui un
+processo appena creato appartiene sempre allo stesso raggruppamento e alla
+stessa sessione del padre.
+
+Ciascun gruppo di processi ha sempre un processo principale, il
+\textit{process leader}, che è quello che è identificato dall'avere il suo
+\acr{pgid} uguale al \acr{pid}, per
+
+La differenza fra i due identificatori è che un processo
+può cambiare \acr{pgid} soltanto ad un valore che corrisponda al
+\textit{process group} di un altro processo della stessa sessione, oppure al
+suo stesso \acr{pid} (creando così un nuovo \textit{process group}). Se invece
+si modifica il \acr{sid} il processo viene automaticamente messo anche in un
+nuovo \textit{process group}, corrispondente al suo \acr{pid}.
+
+
+
+
+
+\subsection{Il terminale di controllo}
+\label{sec:sess_ctrl_term}
+
+Come accennato in \secref{sec:sess_job_control_overview} ad ogni sessione di
+lavoro è associato un terminale di controllo.
+
+
+
+\subsection{La procedura di login}
projects / gapil.git / blobdiff