il cui scopo è quello di permettere ad un utente di poter sfruttare le
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 vituali tutto questo non è più vero, dato che si può
+ 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.
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 cotrol} una volta completato il
+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_sessions}) tutti i processi eseguiti all'interno dello stesso
-login.
+\secref{sec:sess_proc_group}) tutti i processi eseguiti all'interno dello
+stesso login.
Siccome la shell è collegata ad un solo terminale (il \textsl{terminale di
controllo}, vedi \secref{sec:sess_control_term}) solo un comando alla volta,
group}, 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 solo \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
+In generale allora all'interno di una sessione avremo un eventuale (possono
+non esserci comandi in \textit{foreground}) \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
questo invii a tutti i processi del raggruppamento un segnale di
-\macro{SIGTTIN} o di \macro{SIGTTOU} (a seconda che l'accesso sia in lettura o
-scrittura)
-
-
-
-
-
-
-
-
-
-
-
-
-\subsection{I \textit{process group}}
+\macro{SIGTTIN} o di \macro{SIGTTOU}, a seconda che l'accesso sia
+rispettivamente in lettura o scrittura, bloccando (secondo il comportamento
+di default esposto in \secref{sec:sig_job_control}) i processi.
+
+Un comportamento analogo sia ha anche per i segnali generati dai comandi di
+tastiera inviati dal terminale con \cmd{C-z}, \cmd{C-c}, \cmd{C-y} e
+\verb|C-\|; questi generano rispettivamente i segnali \macro{SIGTSTP},
+\macro{SIGINT}, \macro{SIGQUIT} e \macro{SIGTERM}, che vengono inviati a tutti
+i processi del raggruppamento in \textit{foreground}. In particolare il primo
+di essi, \macro{SIGTSTP}, interrompe l'esecuzione del comando, che può poi
+essere mandato in \textit{background} con il comando \cmd{bg}. Il comando
+\cmd{fg} consente invece di mettere in \textit{foreground} un comando
+precedentemente lanciato in \textit{background}.
+
+Di norma la shell si cura anche di notificare all'utente (di solito prima
+della stampa a video del prompt) lo stato dei vari processi, essa infatti usa
+le caratteristiche della funzione \func{waitpid} (si riveda quanto detto in
+\secref{sec:proc_wait}) per verificare quali gruppi di processi sono bloccati
+e quali sono terminati.
+
+
+\subsection{I \textit{process group} e le \textsl{sessioni}}
\label{sec:sess_proc_group}
-
-
-Per poter gestire il \textit{Job Control} il kernel associa a ciascun processo
-due ulteriori identificatori (oltre quelli visti in \secref{sec:proc_pid}):
-l'identificatore del cosiddetto \textit{process group} (o
-\textsl{ragguppamento di processi}), cui si fa di norma riferimento con la
-sigla \acr{pgid}, l'identificatore di sessione (il \textit{session id}) cui si
-fa riferimento con la sigla \acr{sid}). In questo modo, sulla base dei valori
-dei rispettivi indicatori, i processi vengono organizzati in \textsl{sessioni}
-e \textsl{raggruppamenti}.
-
-Entrambi gli identificatori vengono impostati alla creazione di ciascun
-processo allo stesso valore che hanno nel processo padre, un processo appena
-creato cioè appartiene sempre allo stesso raggruppamento e alla stessa
-sessione del padre. La differenza fra i due identificatori è che un processo
+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}.
+
+Un \textit{process group} è pertanto definito da tutti i processi che hanno lo
+stesso \acr{pgid}; è possibile leggere il valore di questo identificatore con
+le funzioni \func{getpgid} e \func{getpgrp},\footnote{\func{getpgrp} è
+ definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.}
+i cui prototipi sono:
+\begin{functions}
+ \headdecl{unistd.h}
+
+ \funcdecl{pid\_t getpgid(pid\_t pid)}
+ Legge il \acr{pgid} del processo \param{pid}.
+
+ \funcdecl{pid\_t getpgrp(void)}
+ Legge il \acr{pgid} del processo corrente.
+
+ \bodydesc{Le funzioni restituiscono il \acr{pgid} del processo,
+ \func{getpgrp} ha sempre successo, mentre \func{getpgid} restituisce -1
+ ponendo \var{errno} a \macro{ESRCH} se il processo selezionato non esiste.}
+\end{functions}
+
+La funzione \func{getpgid} permette di specificare il \acr{pid} del processo
+di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid}
+restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma
+equivalente a \code{getpgid(0)}.
+
+In maniera analoga l'identificatore della sessione può essere letto dalla
+funzione \func{getsid}, che però nelle \acr{glibc}\footnote{la system call è
+ stata introdotta in Linux a partire dalla versione 1.3.44, il supporto nelle
+ librerie del C è iniziato dalla versione 5.2.19.} è accessibile solo
+definendo \macro{\_XOPEN\_SOURCE} e \macro{\_XOPEN\_SOURCE\_EXTENDED}; il suo
+prototipo è:
+\begin{prototype}{unistd.h}{pid\_t getsid(pid\_t pid)}
+ Legge l'identificatore di sessione del processo \param{pid}.
+
+ \bodydesc{La funzione restituisce l'identificatore (un numero positivo) in
+ caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
+ i valori:
+ \begin{errlist}
+ \item[\macro{ESRCH}] Il processo selezionato non esiste.
+ \item[\macro{EPERM}] Il processo selezionato non fa parte della stessa
+ sessione del processo corrente.
+ \end{errlist}
+ }
+\end{prototype}
+
+Entrambi gli identificatori vengono inizializzati alla creazione di ciascun
+processo con lo stesso valore che hanno nel processo padre, per cui un
+processo appena creato appartiene sempre allo stesso raggruppamento e alla
+stessa sessione del padre.
+
+Ciascun gruppo di processi ha sempre un processo principale, il
+\textit{process leader}, che è quello che è identificato dall'avere il suo
+\acr{pgid} uguale al \acr{pid}, per
+
+La differenza fra i due identificatori è che un processo
può cambiare \acr{pgid} soltanto ad un valore che corrisponda al
\textit{process group} di un altro processo della stessa sessione, oppure al
suo stesso \acr{pid} (creando così un nuovo \textit{process group}). Se invece
-\subsection{Le sessioni}
-\label{sec:sess_sessions}
-
-
\subsection{Il terminale di controllo}
\label{sec:sess_ctrl_term}
+Come accennato in \secref{sec:sess_job_control_overview} ad ogni sessione di
+lavoro è associato un terminale di controllo.
+
\subsection{La procedura di login}
projects / gapil.git / blobdiff