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}
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
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
\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}
}
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}
projects / gapil.git / commitdiff