Lavoro fatto a casa senza ADSL, correzioni multiple agli indici, documentato
[gapil.git] / session.tex
index 68fa465799e809d75d20c459a7ca36ced6412f54..c8f25effcd2bea0f29b3a41fc3c895322efa968b 100644 (file)
@@ -75,19 +75,21 @@ questo potr
 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
@@ -110,8 +112,10 @@ sez.~\ref{sec:proc_wait}).
 \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
@@ -178,15 +182,15 @@ stessa sessione del padre. Vedremo poi come sia possibile creare pi
 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.
   
@@ -195,11 +199,11 @@ raggruppamento si crea con la funzione \funcd{setpgrp},\footnote{questa 
 \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}.
   
@@ -228,13 +232,13 @@ processo selezionato; pertanto \func{setpgrp} 
   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
@@ -260,21 +264,22 @@ unico componente.  Inoltre la funzione distacca il processo da ogni terminale
 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}
@@ -344,19 +349,20 @@ funzione \funcd{tcsetpgrp}, il cui prototipo 
 \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 è:
@@ -428,26 +434,28 @@ terminale, in assenza di un processo che sia in grado di effettuare il
 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
@@ -522,16 +530,17 @@ indicato dall'amministratore nel file di configurazione del programma,
 
 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
@@ -616,10 +625,10 @@ occorrer
 \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.
@@ -1969,14 +1978,16 @@ distinti:
 \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}