Completate sessioni, aggiunti riferimenti a dove sta la roba nel kernel,
authorSimone Piccardi <piccardi@gnulinux.it>
Fri, 13 Sep 2002 13:54:59 +0000 (13:54 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Fri, 13 Sep 2002 13:54:59 +0000 (13:54 +0000)
verificato il comportamento di setpgid e setsid, iniziata la sezione sui
terminali di controllo

session.tex

index c5c1d24..a7cd2e8 100644 (file)
@@ -18,9 +18,10 @@ il cui scopo 
 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 virtuali 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. 
+  accedere a molti terminali in contemporanea da una singola postazione di
+  lavoro, 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}
@@ -35,20 +36,20 @@ 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 control} 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.
+In un sistema che supporta il \textit{job control}, una volta completato il
+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 (esamineremo tutto il processo in dettaglio in
+\secref{sec:sess_login}).
 
 Siccome la shell è collegata ad un solo terminale (che viene usualmente
-chiamato \textsl{terminale di controllo}) un solo 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} (aggiungendo una \cmd{\&} alla fine del
-comando), nel qual caso essi saranno eseguiti senza essere collegati al
-terminale.
+chiamato \textsl{terminale di controllo}, vedi \secref{sec:sess_ctrl_term}) un
+solo 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} (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
@@ -99,12 +100,14 @@ e quali sono terminati.
 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}. I
-valori di questi identificatori possono essere visualizzati dal comando
-\cmd{ps} usando l'opzione \cmd{-j}.
+visti in \secref{sec:proc_pid}) che il kernel associa a ciascun
+processo:\footnote{in Linux questi identificatori sono mantenuti nei campi
+  \var{pgrp} e \var{session} della struttura \var{task\_struct} definita in
+  \file{sched.h}.}  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}. I valori di questi identificatori possono essere visualizzati
+dal comando \cmd{ps} usando l'opzione \cmd{-j}.
 
 Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
 stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
@@ -190,6 +193,7 @@ da un gruppo ad un altro con la funzione \func{setpgid}, il cui prototipo 
     \begin{errlist}
     \item[\macro{ESRCH}] Il processo selezionato non esiste.
     \item[\macro{EPERM}] Il cambiamento non è consentito.
+    \item[\macro{EACCESS}] Il processo ha già eseguito una \func{exec}.
     \item[\macro{EINVAL}] Il valore di \param{pgid} è negativo.
     \end{errlist}
  }
@@ -231,31 +235,66 @@ sessione ad un processo 
 La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
 valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo
 \textit{process group} di cui esso diventa leader (come per i \textit{process
-  group} un processo si dice leader di sessione se il suo \acr{sid} è uguale
-al suo \acr{pid}).  Inoltre il processo non avrà più un terminale di
-controllo.
-
-La funzione ha successo soltanto se il processo non è già leader per un
+  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.
+
+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.  Questa funzione viene usata di solito nel
-processo di login (per i dettagli vedi \secref{sec:sess_login}) per
-raggruppare in una sessione tutti i comandi eseguiti da un utente dalla sua
-shell.
+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 \secref{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
+  sistema.} Questa funzione viene usata di solito nel processo di login (per i
+dettagli vedi \secref{sec:sess_login}) per raggruppare in una sessione tutti i
+comandi eseguiti da un utente dalla sua shell.
 
 
 
 \subsection{Il terminale di controllo}
 \label{sec:sess_ctrl_term}
 
-Come accennato in \secref{sec:sess_job_control_overview} ad ogni sessione di
-lavoro di norma viene associato un terminale di controllo. Alla creazione
-della sessione con \func{setsid} infatti ogni associazione con un precedente
-terminale di controllo viene spezzata, ed il processo dovrà riottenere (se
-necessario, vedi \secref{sec:sess_daemon}), un terminale di controllo.
+Come accennato in \secref{sec:sess_job_control_overview}, nel sistema del
+\textit{job control} i processi all'interno di una sessione fanno riferimento
+ad un terminale di controllo (ad esempio quello su cui si è effettuato il
+login), sul quale effettuano le operazioni di lettura e
+scrittura,\footnote{nel caso di login grafico la cosa può essere più
+  complessa, e di norma l'I/O è effettuato tramite il server X, ma ad esempio
+  per i programmi, anche grafici, lanciati da un qualunque emulatore di
+  terminale, sarà quest'ultimo a fare da terminale (virtuale) di controllo.} e
+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
+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.
+
+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
+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
+  terminale di controllo con il flag \macro{O\_NOCTTY} (vedi
+  \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.
 
-Le modalità con cui 
 
 
 \subsection{Dal login alla shell}