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 di processi}, vedi
-sez.~\ref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
-originano da una riga di comando appartengano allo stesso raggruppamento, in
-modo che le varie funzioni di controllo, ed i segnali inviati dal terminale,
-possano fare riferimento ad esso.
+\itindex{process~group} \textit{process group} (detto anche
+\textsl{raggruppamento di processi}, vedi sez.~\ref{sec:sess_proc_group}) e la
+shell farà sì che tutti i processi che originano da una riga di comando
+appartengano allo stesso raggruppamento, 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 (può non
-esserci) \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, venga inviato un segnale a tutti i processi
-del raggruppamento, in modo da bloccarli (vedi sez.~\ref{sec:sess_ctrl_term}).
+esserci) \itindex{process~group} \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,
+venga inviato un segnale a tutti i processi del raggruppamento, in modo da
+bloccarli (vedi sez.~\ref{sec:sess_ctrl_term}).
Un comportamento analogo si ha anche per i segnali generati dai comandi di
tastiera inviati dal terminale che vengono inviati a tutti i processi del
\subsection{I \textit{process group} e le \textsl{sessioni}}
\label{sec:sess_proc_group}
+\itindbeg{process~group}
+
Come accennato in sez.~\ref{sec:sess_job_control_overview} nel job control i
-processi vengono raggruppati in \textit{process group} e \textit{sessioni};
+processi vengono raggruppati in \textit{process group} e \textsl{sessioni};
per far questo vengono utilizzati due ulteriori identificatori (oltre quelli
visti in sez.~\ref{sec:proc_pid}) che il kernel associa a ciascun
processo:\footnote{in Linux questi identificatori sono mantenuti nei campi
processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
Ciascun raggruppamento di processi ha sempre un processo principale, il
-cosiddetto \textit{process group leader}, che è identificato dall'avere un
-\acr{pgid} uguale al suo \acr{pid}, in genere questo è il primo processo del
-raggruppamento, che si incarica di lanciare tutti gli altri. Un nuovo
-raggruppamento si crea con la funzione \funcd{setpgrp},\footnote{questa è la
- definizione di POSIX.1, BSD definisce una funzione con lo stesso nome, che
- però è identica a \func{setpgid}; nelle \acr{glibc} viene sempre usata
- sempre questa definizione, a meno di non richiedere esplicitamente la
- compatibilità all'indietro con BSD, definendo la macro
- \macro{\_BSD\_SOURCE}.} il cui prototipo è:
+cosiddetto \itindex{process~group~leader}\textit{process group leader}, che è
+identificato dall'avere un \acr{pgid} uguale al suo \acr{pid}, in genere
+questo è il primo processo del raggruppamento, che si incarica di lanciare
+tutti gli altri. Un nuovo raggruppamento si crea con la funzione
+\funcd{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD definisce
+ una funzione con lo stesso nome, che però è identica a \func{setpgid}; nelle
+ \acr{glibc} viene sempre usata sempre questa definizione, a meno di non
+ richiedere esplicitamente la compatibilità all'indietro con BSD, definendo
+ la macro \macro{\_BSD\_SOURCE}.} il cui prototipo è:
\begin{prototype}{unistd.h}{int setpgrp(void)}
Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
\end{prototype}
La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
-corrente, rende questo \textit{group leader} di un nuovo raggruppamento, tutti
-i successivi processi da esso creati apparterranno (a meno di non cambiare di
-nuovo il \acr{pgid}) al nuovo raggruppamento. È possibile invece spostare un
-processo da un raggruppamento ad un altro con la funzione \funcd{setpgid}, il
-cui prototipo è:
+corrente, rende questo \itindex{process~group~leader} \textit{group leader} di
+un nuovo raggruppamento, tutti i successivi processi da esso creati
+apparterranno (a meno di non cambiare di nuovo il \acr{pgid}) al nuovo
+raggruppamento. È possibile invece spostare un processo da un raggruppamento
+ad un altro con la funzione \funcd{setpgid}, il cui prototipo è:
\begin{prototype}{unistd.h}{int setpgid(pid\_t pid, pid\_t pgid)}
Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
0)}.
Di norma questa funzione viene usata dalla shell quando si usano delle
-pipeline, per mettere nello stesso process group tutti i programmi lanciati su
-ogni linea di comando; essa viene chiamata dopo una \func{fork} sia dal
-processo padre, per impostare il valore nel figlio, che da quest'ultimo, per
-sé stesso, in modo che il cambiamento di \textit{process group} sia immediato
-per entrambi; una delle due chiamate sarà ridondante, ma non potendo
-determinare quale dei due processi viene eseguito per primo, occorre eseguirle
-comunque entrambe per evitare di esporsi ad una \textit{race
+pipeline, per mettere nello stesso \textit{process group} tutti i programmi
+lanciati su ogni linea di comando; essa viene chiamata dopo una \func{fork}
+sia dal processo padre, per impostare il valore nel figlio, che da
+quest'ultimo, per sé stesso, in modo che il cambiamento di \textit{process
+ group} sia immediato per entrambi; una delle due chiamate sarà ridondante,
+ma non potendo determinare quale dei due processi viene eseguito per primo,
+occorre eseguirle comunque entrambe per evitare di esporsi ad una \textit{race
condition}\itindex{race~condition}.
Si noti come nessuna delle funzioni esaminate finora permetta di spostare un
di controllo (torneremo sull'argomento in sez.~\ref{sec:sess_ctrl_term}) cui
fosse in precedenza associato.
-La funzione ha successo soltanto se il processo non è già leader di un
-\textit{process group}, per cui per usarla di norma si esegue una \func{fork}
-e si esce, per poi chiamare \func{setsid} nel processo figlio, in modo che,
-avendo questo lo stesso \acr{pgid} del padre ma un \acr{pid} diverso, non ci
-siano possibilità di errore.\footnote{potrebbe sorgere il dubbio che, per il
- riutilizzo dei valori dei \acr{pid} fatto nella creazione dei nuovi processi
- (vedi sez.~\ref{sec:proc_pid}), il figlio venga ad assumere un valore
- corrispondente ad un process group esistente; questo viene evitato dal
- kernel che considera come disponibili per un nuovo \acr{pid} solo valori che
- non corrispondono ad altri \acr{pid}, \acr{pgid} o \acr{sid} in uso nel
+La funzione ha successo soltanto se il processo non è già
+\itindex{process~group~leader} leader di un \textit{process group}, per cui
+per usarla di norma si esegue una \func{fork} e si esce, per poi chiamare
+\func{setsid} nel processo figlio, in modo che, avendo questo lo stesso
+\acr{pgid} del padre ma un \acr{pid} diverso, non ci siano possibilità di
+errore.\footnote{potrebbe sorgere il dubbio che, per il riutilizzo dei valori
+ dei \acr{pid} fatto nella creazione dei nuovi processi (vedi
+ sez.~\ref{sec:proc_pid}), il figlio venga ad assumere un valore
+ corrispondente ad un \textit{process group} esistente; questo viene evitato
+ dal kernel che considera come disponibili per un nuovo \acr{pid} solo valori
+ che non corrispondono ad altri \acr{pid}, \acr{pgid} o \acr{sid} in uso nel
sistema.} Questa funzione viene usata di solito nel processo di login (per i
dettagli vedi sez.~\ref{sec:sess_login}) per raggruppare in una sessione tutti
i comandi eseguiti da un utente dalla sua shell.
-
+\itindend{process~group}
\subsection{Il terminale di controllo e il controllo di sessione}
\label{sec:sess_ctrl_term}
\noindent la funzione può essere eseguita con successo solo da
un processo nella stessa sessione e con lo stesso terminale di controllo.
-Come accennato in sez.~\ref{sec:sess_job_control_overview}, tutti i processi (e
-relativi raggruppamenti) che non fanno parte del gruppo di \textit{foreground}
-sono detti in \textit{background}; se uno si essi cerca di accedere al
-terminale di controllo provocherà l'invio da parte del kernel di uno dei due
-segnali \const{SIGTTIN} o \const{SIGTTOU} (a seconda che l'accesso sia stato
-in lettura o scrittura) a tutto il suo \textit{process group}; dato che il
-comportamento di default di questi segnali (si riveda quanto esposto in
-sez.~\ref{sec:sig_job_control}) è di fermare il processo, di norma questo
-comporta che tutti i membri del gruppo verranno fermati, ma non si avranno
-condizioni di errore.\footnote{la shell in genere notifica comunque un
- avvertimento, avvertendo la presenza di processi bloccati grazie all'uso di
- \func{waitpid}.} Se però si bloccano o ignorano i due segnali citati, le
-funzioni di lettura e scrittura falliranno con un errore di \errcode{EIO}.
+Come accennato in sez.~\ref{sec:sess_job_control_overview}, tutti i processi
+(e relativi raggruppamenti) che non fanno parte del gruppo di
+\textit{foreground} sono detti in \textit{background}; se uno si essi cerca di
+accedere al terminale di controllo provocherà l'invio da parte del kernel di
+uno dei due segnali \const{SIGTTIN} o \const{SIGTTOU} (a seconda che l'accesso
+sia stato in lettura o scrittura) a tutto il suo \itindex{process~group}
+\textit{process group}; dato che il comportamento di default di questi segnali
+(si riveda quanto esposto in sez.~\ref{sec:sig_job_control}) è di fermare il
+processo, di norma questo comporta che tutti i membri del gruppo verranno
+fermati, ma non si avranno condizioni di errore.\footnote{la shell in genere
+ notifica comunque un avvertimento, avvertendo la presenza di processi
+ bloccati grazie all'uso di \func{waitpid}.} Se però si bloccano o ignorano i
+due segnali citati, le funzioni di lettura e scrittura falliranno con un
+errore di \errcode{EIO}.
Un processo può controllare qual è il gruppo di \textit{foreground} associato
ad un terminale con la funzione \funcd{tcgetpgrp}, il cui prototipo è:
controllo dello stesso.
Questa è la situazione in cui si ha quello che viene chiamato un
-\textit{orphaned process group}. Lo standard POSIX.1 lo definisce come un
-\textit{process group} i cui processi hanno come padri esclusivamente o altri
-processi nel raggruppamento, o processi fuori della sessione. Lo standard
-prevede inoltre che se la terminazione di un processo fa sì che un
-raggruppamento di processi diventi orfano e se i suoi membri sono bloccati, ad
-essi vengano inviati in sequenza i segnali di \const{SIGHUP} e
-\const{SIGCONT}.
+\itindex{process~group~orphaned} \textit{orphaned process group}. Lo standard
+POSIX.1 lo definisce come un \itindex{process~group} \textit{process group} i
+cui processi hanno come padri esclusivamente o altri processi nel
+raggruppamento, o processi fuori della sessione. Lo standard prevede inoltre
+che se la terminazione di un processo fa sì che un raggruppamento di processi
+diventi orfano e se i suoi membri sono bloccati, ad essi vengano inviati in
+sequenza i segnali di \const{SIGHUP} e \const{SIGCONT}.
La definizione può sembrare complicata, e a prima vista non è chiaro cosa
tutto ciò abbia a che fare con il problema della terminazione del processo di
controllo. Consideriamo allora cosa avviene di norma nel \textit{job
control}: una sessione viene creata con \func{setsid} che crea anche un
-nuovo process group: per definizione quest'ultimo è sempre \textsl{orfano},
-dato che il padre del leader di sessione è fuori dalla stessa e il nuovo
-process group contiene solo il leader di sessione. Questo è un caso limite, e
-non viene emesso nessun segnale perché quanto previsto dallo standard riguarda
-solo i raggruppamenti che diventano orfani in seguito alla terminazione di un
-processo.\footnote{l'emissione dei segnali infatti avviene solo nella fase di
- uscita del processo, come una delle operazioni legate all'esecuzione di
- \func{\_exit}, secondo quanto illustrato in sez.~\ref{sec:proc_termination}.}
+nuovo \itindex{process~group} \textit{process group}: per definizione
+quest'ultimo è sempre \textsl{orfano}, dato che il padre del leader di
+sessione è fuori dalla stessa e il nuovo \textit{process group}
+\itindex{process~group} contiene solo il leader di sessione. Questo è un caso
+limite, e non viene emesso nessun segnale perché quanto previsto dallo
+standard riguarda solo i raggruppamenti che diventano orfani in seguito alla
+terminazione di un processo.\footnote{l'emissione dei segnali infatti avviene
+ solo nella fase di uscita del processo, come una delle operazioni legate
+ all'esecuzione di \func{\_exit}, secondo quanto illustrato in
+ sez.~\ref{sec:proc_termination}.}
Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
punto non sono orfani in quanto esso resta padre per almeno uno dei processi
Quando viene lanciato da \cmd{init} il programma parte con i privilegi di
amministratore e con un ambiente vuoto; \cmd{getty} si cura di chiamare
-\func{setsid} per creare una nuova sessione ed un nuovo process group, e di
-aprire il terminale (che così diventa il terminale di controllo della
-sessione) in lettura sullo standard input ed in scrittura sullo standard
-output e sullo standard error; inoltre effettuerà, qualora servano, ulteriori
-settaggi.\footnote{ad esempio, come qualcuno si sarà accorto scrivendo un nome
- di login in maiuscolo, può effettuare la conversione automatica dell'input
- in minuscolo, ponendosi in una modalità speciale che non distingue fra i due
- tipi di caratteri (a beneficio di alcuni vecchi terminali che non
- supportavano le minuscole).} Alla fine il programma stamperà un messaggio di
-benvenuto per poi porsi in attesa dell'immissione del nome di un utente.
+\func{setsid} per creare una nuova sessione ed un nuovo
+\itindex{process~group} \textit{process group}, e di aprire il terminale (che
+così diventa il terminale di controllo della sessione) in lettura sullo
+standard input ed in scrittura sullo standard output e sullo standard error;
+inoltre effettuerà, qualora servano, ulteriori settaggi.\footnote{ad esempio,
+ come qualcuno si sarà accorto scrivendo un nome di login in maiuscolo, può
+ effettuare la conversione automatica dell'input in minuscolo, ponendosi in
+ una modalità speciale che non distingue fra i due tipi di caratteri (a
+ beneficio di alcuni vecchi terminali che non supportavano le minuscole).}
+Alla fine il programma stamperà un messaggio di benvenuto per poi porsi in
+attesa dell'immissione del nome di un utente.
Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
il programma \cmd{login} con una \func{exevle}, passando come argomento la
\begin{enumerate}
\item Eseguire una \func{fork} e terminare immediatamente il processo padre
proseguendo l'esecuzione nel figlio. In questo modo si ha la certezza che
- il figlio non è un \textit{process group leader}, (avrà il \acr{pgid} del
- padre, ma un \acr{pid} diverso) e si può chiamare \func{setsid} con
- successo. Inoltre la shell considererà terminato il comando all'uscita del
- padre.
+ il figlio non è un \itindex{process~group~leader} \textit{process group
+ leader}, (avrà il \acr{pgid} del padre, ma un \acr{pid} diverso) e si può
+ chiamare \func{setsid} con successo. Inoltre la shell considererà terminato
+ il comando all'uscita del padre.
\item Eseguire \func{setsid} per creare una nuova sessione ed un nuovo
raggruppamento di cui il processo diventa automaticamente il leader, che
però non ha associato nessun terminale di controllo.
\bodydesc{La funzione restituisce il precedente valore.}
\end{prototype}
-Le routine di gestione mantengono per ogni processo una maschera che determina
+Le funzioni di gestione mantengono per ogni processo una maschera che determina
quale delle chiamate effettuate a \func{syslog} verrà effettivamente
registrata. La registrazione viene disabilitata per tutte quelle priorità che
non rientrano nella maschera; questa viene impostata usando la macro
\end{description}
-%
-% Qui c'è da mettere tutta la parte sui terminali virtuali, e la gestione
-% degli stessi
-%
\section{La gestione dei terminali virtuali}
\label{sec:sess_virtual_terminal}
+%
+% TODO terminali virtuali
+% Qui c'è da mettere tutta la parte sui terminali virtuali, e la gestione
+% degli stessi
+%
+
Da fare.
\subsection{I terminali virtuali}