Correzioni a vari riferimenti.

[gapil.git] / session.tex

diff --git a/session.tex b/session.tex
index a7cd2e8faa59dc0d523185a7c68691389c03e650..92e532d847973d7be79692c3daaf934010c6ebd3 100644 (file)
--- a/session.tex
+++ b/session.tex
@@ -237,10 +237,10 @@ valore del suo \acr{pid}, creando cos
 \textit{process group} di cui esso diventa leader (come per i \textit{process
   group} un processo si dice leader di sessione\footnote{in Linux la proprietà
   è mantenuta in maniera indipendente con un apposito campo \var{leader} in
-  \var{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}).
-Infine la funzione distacca il processo da ogni terminale di controllo
-(torneremo sull'argomento in \secref{sec:sess_ctrl_term}) cui fosse in
-precedenza associato.
+  \var{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed unico
+componente.  Inoltre la funzione distacca il processo da ogni terminale di
+controllo (torneremo sull'argomento in \secref{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}
@@ -258,7 +258,7 @@ comandi eseguiti da un utente dalla sua shell.
 
 
 
-\subsection{Il terminale di controllo}
+\subsection{Il terminale di controllo e il controllo di sessione}
 \label{sec:sess_ctrl_term}
 
 Come accennato in \secref{sec:sess_job_control_overview}, nel sistema del
@@ -272,20 +272,19 @@ scrittura,\footnote{nel caso di login grafico la cosa pu
 dal quale ricevono gli eventuali segnali da tastiera.
 
 A tale scopo lo standard POSIX.1 prevede che ad ogni sessione possa essere
-associato un terminale di controllo (e non più di uno); in Linux questo viene
-realizzato mantenendo fra gli attributi di ciascun processo anche il terminale
+associato un terminale di controllo; in Linux questo viene realizzato
+mantenendo fra gli attributi di ciascun processo anche qual'è il suo terminale
 di controllo. \footnote{Lo standard POSIX.1 non specifica nulla riguardo
   l'implementazione; in Linux anch'esso viene mantenuto nella solita struttura
-  \var{task\_struct}, nel campo \var{tty}.}
-In generale ogni processo eredita dal padre, insieme al \acr{pgid} e al
-\acr{sid} anche il terminale di controllo. In questo modo tutti processi
-originati dallo stesso leader di sessione mantengono lo stesso terminale di
-controllo.
+  \var{task\_struct}, nel campo \var{tty}.}  In generale ogni processo eredita
+dal padre, insieme al \acr{pgid} e al \acr{sid} anche il terminale di
+controllo. In questo modo tutti processi originati dallo stesso leader di
+sessione mantengono lo stesso terminale di controllo.
 
 Alla creazione di una nuova sessione con \func{setsid} ogni associazione con
 il precedente terminale di controllo viene cancellata, ed il processo che è
 divenuto un nuovo leader di sessione dovrà riottenere (qualora sia necessario,
-cosa che come vedremo in \secref{sec:sess_daemon} non è sempre vera), un
+cosa che, come vedremo in \secref{sec:sess_daemon}, non è sempre vera), un
 terminale di controllo. In generale questo viene fatto automaticamente dal
 sistema quando il leader di sessione apre il suo primo terminale\footnote{a
   meno di non avere richiesto esplicitamente che questo non diventi un
@@ -293,9 +292,12 @@ sistema quando il leader di sessione apre il suo primo terminale\footnote{a
   \secref{sec:file_open}). In questo Linux segue la semantica di SVr4; BSD
   invece richiede che il terminale venga allocato esplicitamente con una
   \func{ioctl} con il comando \macro{TIOCSCTTY}.} che diventa automaticamente
-il terminale di controllo.
+il terminale di controllo. 
 
+Per ciascuna sessione di lavoro avremo allora un terminale di controllo, ed un
+processo di \textit{foreground}, che è quello 
 
+Il kernel identifica 
 
 \subsection{Dal login alla shell}
 \label{sec:sess_login}