From 139b022770db438fb1caf2c111e466dd72071592 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sun, 8 Jul 2012 20:51:08 +0000 Subject: [PATCH] Inizio revisione capitolo sessioni e terminali --- session.tex | 358 +++++++++++++++++++++++++++++----------------------- 1 file changed, 199 insertions(+), 159 deletions(-) diff --git a/session.tex b/session.tex index 6fd9027..8c06fd9 100644 --- a/session.tex +++ b/session.tex @@ -9,7 +9,7 @@ %% License". %% -\chapter{Interfaccia utente: terminali e sessioni di lavoro} +\chapter{Terminali e sessioni di lavoro} \label{cha:session} @@ -44,10 +44,10 @@ Originariamente si trattava di dispositivi specifici (i terminali seriali, se non addirittura le telescriventi). Oggi questa interfaccia viene in genere emulata o tramite programmi o con le cosiddette console virtuali associate a monitor e tastiera, ma esiste sempre la possibilità di associarla direttamente -ad alcuni dispositivi, come eventuali linee seriali.\footnote{ed in certi - casi, come buona parte dei dispositivi embedded su cui gira Linux (come - router, access point, ecc.) questa resta anche l'unica opzione per una - \textit{console} di sistema.} +ad alcuni dispositivi, come eventuali linee seriali, ed in certi casi, come +buona parte dei dispositivi embedded su cui gira Linux (come router, access +point, ecc.) questa resta anche l'unica opzione per una \textit{console} di +sistema. \subsection{Il \textit{job control}} @@ -56,50 +56,50 @@ ad alcuni dispositivi, come eventuali linee seriali.\footnote{ed in certi Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità 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 - le interfacce grafiche di \textit{X Window} e con i terminali virtuali via - rete tutto questo non è più vero, dato che si può 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. +processi, pur potendo accedere, di solito, ad un solo terminale, avendo cioè +un solo punto in cui si può avere accesso all'input ed all'output degli +stessi. Con le interfacce grafiche di \textit{X Window} e con i terminali +virtuali via rete oggi tutto questo non è più vero, dato che si può accedere a +molti terminali in contemporanea da una singola postazione di lavoro, ma il +sistema è nato prima dell'esistenza di tutto ciò. Il \textit{job control} è una caratteristica opzionale, introdotta in BSD -negli anni '80, e successivamente standardizzata da POSIX.1; la sua +negli anni '80, e successivamente standardizzata da POSIX.1. La sua disponibilità nel sistema è verificabile attraverso il controllo della macro \macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il supporto sia da parte della shell (quasi tutte ormai lo hanno), che da parte -del kernel; in particolare il kernel deve assicurare sia la presenza di un +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 sez.~\ref{sec:sig_job_control}. 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 sez.~\ref{sec:sess_proc_group}) tutti i processi eseguiti all'interno -dello stesso login (esamineremo tutto il processo in dettaglio in +potrà iniziare quella che viene chiamata una \textsl{sessione di lavoro}, che +riunisce (vedi sez.~\ref{sec:sess_proc_group}) tutti i processi eseguiti +all'interno dello stesso login (esamineremo tutto il processo in dettaglio in sez.~\ref{sec:sess_login}). Siccome la shell è collegata ad un solo terminale, che viene usualmente chiamato \textsl{terminale di controllo}, (vedi sez.~\ref{sec:sess_ctrl_term}) -un solo comando alla volta (quello che viene detto in \textit{foreground} o in -\textsl{primo piano}), potrà scrivere e leggere dal terminale. La shell però +un solo comando alla volta, quello che viene detto in \textit{foreground} o in +\textsl{primo piano}, potrà scrivere e leggere dal terminale. La shell però può eseguire, aggiungendo una ``\cmd{\&}'' alla fine del comando, più -programmi in contemporanea, mandandoli in \textit{background} (o \textsl{sullo - sfondo}), nel qual caso essi saranno eseguiti senza essere collegati al -terminale. +programmi in contemporanea, mandandoli come si dice, ``in +\textit{background}'' (letteralmente ``\textsl{sullo sfondo}''), 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 +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 -più programmi in una sola riga di comando con le pipe, ed in tal caso verranno -eseguiti più programmi. Inoltre, anche quando si invoca un singolo programma, -questo potrà sempre lanciare eventuali sotto-processi per eseguire dei compiti -specifici. - -Per questo l'esecuzione di un comando può originare più di un processo; quindi -nella gestione del \textit{job control} non si può far riferimento ai singoli -processi. Per questo il kernel prevede la possibilità di raggruppare più -processi in un cosiddetto \itindex{process~group} \textit{process group} -(detto anche \textsl{raggruppamento di processi}, vedi +più comandi in una sola riga con il \textit{pipelining}, ed in tal caso +verranno eseguiti più programmi. Inoltre, anche quando si invoca un singolo +programma, questo potrà sempre lanciare eventuali sotto-processi per eseguire +dei compiti specifici. + +Per questo l'esecuzione di una riga di comando può originare più di un +processo, quindi nella gestione del \textit{job control} non si può far +riferimento ai singoli processi. Per questo il kernel prevede la possibilità +di raggruppare più processi in un cosiddetto \itindex{process~group} +\textit{process group} (detto anche \textsl{raggruppamento di processi}, vedi sez.~\ref{sec:sess_proc_group}). Deve essere cura della shell far sì che tutti i processi che originano da una stessa riga di comando appartengano allo stesso raggruppamento di processi, in modo che le varie funzioni di controllo, @@ -118,19 +118,19 @@ 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 raggruppamento in \textit{foreground}. In particolare \cmd{C-z} interrompe l'esecuzione del comando, che può poi essere mandato in \textit{background} -con il comando \cmd{bg}.\footnote{si tenga presente che \cmd{bg} e \cmd{fg} - sono parole chiave che indicano comandi interni alla shell, e nel caso non - comportano l'esecuzione di un programma esterno ma operazioni di gestione - compiute direttamente dalla shell stessa.} Il comando \cmd{fg} consente -invece di mettere in \textit{foreground} un comando precedentemente lanciato -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}. Si tenga presente che \cmd{bg} e \cmd{fg} sono comandi +interni alla shell, che non comportano l'esecuzione di un programma esterno, +ma operazioni di gestione compiute direttamente dalla shell stessa. -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 sarà -in grado, grazie all'uso di \func{waitpid}, di rilevare sia i processi che -sono terminati, sia i raggruppamenti che sono bloccati (in questo caso usando -l'opzione \const{WUNTRACED}, secondo quanto illustrato in -sez.~\ref{sec:proc_wait}). +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 sarà +in grado, grazie all'uso della funzione di sistema \func{waitpid} (vedi +sez.~\ref{sec:proc_wait}), di rilevare sia i processi che sono terminati, sia +i raggruppamenti che sono bloccati, in quest'ultimo caso si dovrà usare la +specifica opzione \const{WUNTRACED}, secondo quanto già illustrato in +sez.~\ref{sec:proc_wait}. \subsection{I \textit{process group} e le \textsl{sessioni}} @@ -146,114 +146,147 @@ processo:\footnote{in Linux questi identificatori sono mantenuti nei campi \var{pgrp} e \var{session} della struttura \kstruct{task\_struct} definita in \file{include/linux/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 +rispettivamente con le sigle \ids{PGID} e \ids{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 -le funzioni \funcd{getpgid} e \funcd{getpgrp},\footnote{\func{getpgrp} è - definita nello standard POSIX.1, mentre \func{getpgid} è richiesta da SVr4.} -i cui prototipi sono: -\begin{functions} - \headdecl{unistd.h} +stesso \ids{PGID}; è possibile leggere il valore di questo identificatore con +le funzioni di sistema \funcd{getpgid} e \funcd{getpgrp}, i cui prototipi +sono: - \funcdecl{pid\_t getpgid(pid\_t pid)} - Legge il \acr{pgid} del processo \param{pid}. +\begin{funcproto}{ +\fhead{unistd.h} +\fdecl{pid\_t getpgid(pid\_t pid)} +\fdesc{Legge il \ids{PGID} di un processo.} +\fdecl{pid\_t getpgrp(void)} +\fdesc{Legge il \ids{PGID} del processo corrente.} +} - \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 \errval{ESRCH} se il processo selezionato non - esiste.} -\end{functions} +{Le funzioni ritornano il \ids{PGID} richiesto in caso di successo, + \func{getpgrp} ha sempre successo mentre \func{getpgid} restituisce $-1$ per + un errore, nel qual caso \var{errno} potrà assumere solo il valore + \errval{ESRCH} se il processo indicato non esiste. +} +\end{funcproto} + +Le due funzioni sono definite nello standard POSIX.1-2001, ma la prima deriva +da SVr4 e la seconda da BSD4.2 dove però è previsto possa prendere un +argomento per indicare il \ids{PID} di un altro processo. Si può riottenere +questo comportamento se di definisce la macro \macro{\_BSD\_SOURCE} e non sono +definite le altre macro che richiedono la conformità a POSIX, X/Open o SystemV +(vedi sez.~\ref{sec:intro_standard}). La funzione \func{getpgid} permette di specificare il \ids{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 \funcd{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. La funzione non è prevista - da POSIX.1, che parla solo di processi leader di sessione, e non di - identificatori di sessione.} è 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[\errcode{ESRCH}] il processo selezionato non esiste. - \item[\errcode{EPERM}] in alcune implementazioni viene restituito quando il - processo selezionato non fa parte della stessa sessione del processo - corrente. - \end{errlist} - } -\end{prototype} +di cui si vuole sapere il \ids{PGID}. Un valore nullo per \param{pid} +restituisce il \ids{PGID} del processo corrente, che è il comportamento +ordinario di \func{getpgrp}, che di norma equivalente a \code{getpgid(0)}. + +In maniera analoga l'identificatore della sessione di un processo (il +\ids{SID}) può essere letto dalla funzione di sistema \funcd{getsid}, il cui +prototipo è: + +\begin{funcproto}{ +\fhead{unistd.h} +\fdecl{pid\_t getsid(pid\_t pid)} +\fdesc{Legge il \ids{SID} di un processo.} +} -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. Vedremo poi come sia possibile creare più -\textit{process group} all'interno della stessa sessione, e spostare i -processi dall'uno all'altro, ma sempre all'interno di una stessa sessione. +{La funzione ritorna l'identificatore (un numero positivo) in caso di successo + e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\errcode{ESRCH}] il processo selezionato non esiste. + \item[\errcode{EPERM}] il processo selezionato non fa parte della stessa + sessione del processo corrente (solo in alcune implementazioni). + \end{errlist} +} +\end{funcproto} + +La funzione è stata introdotta in Linux a partire dal kernel 1.3.44, il +supporto nelle librerie del C è iniziato dalla versione 5.2.19. La funzione +non era prevista originariamente da POSIX.1, che parla solo di processi leader +di sessione, e non di identificatori di sessione, ma è prevista da SVr4 e fa +parte di POSIX.1-2001. Per poterla utilizzare occorre definire la macro +\macro{\_XOPEN\_SOURCE} ad un valore maggiore o uguale di 500. Su Linux +l'errore \errval{EPERM} non viene mai restituito. + +Entrambi gli identificatori, \ids{SID} e \ids{PGID}, vengono inizializzati +nella 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. Vedremo a breve come +sia possibile creare più \textit{process group} all'interno della stessa +sessione, e spostare i processi dall'uno all'altro, ma sempre all'interno di +una stessa sessione. Ciascun raggruppamento di processi ha sempre un processo principale, il -cosiddetto \itindex{process~group~leader} \textit{process group leader}, che è -identificato dall'avere un \acr{pgid} uguale al suo \ids{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 \ids{PID} del processo corrente. - - \bodydesc{La funzione restituisce il valore del nuovo \textit{process - group}.} -\end{prototype} +cosiddetto \itindex{process~group~leader} \textit{process group leader} o più +brevemente \textit{group leader}, che è identificato dall'avere un \ids{PGID} +uguale al suo \ids{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 di sistema \funcd{setpgrp}, il cui +prototipo è: -La funzione, assegnando al \acr{pgid} il valore del \ids{PID} processo -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}. - - \bodydesc{La funzione ritorna il valore del nuovo \textit{process group}, e - -1 in caso di errore, nel qual caso \var{errno} assumerà i valori: - \begin{errlist} +\begin{funcproto}{ +\fhead{unistd.h} +\fdecl{int setpgrp(void)} +\fdesc{Rende un processo \textit{group leader} di un nuovo gruppo.} +} + +{La funzione ritorna il valore del nuovo \textit{process group} e non sono + previsti errori.} +\end{funcproto} + +La funzione assegna al \ids{PGID} il valore del \ids{PID} del processo +corrente, rendendolo in tal modo \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 \ids{PGID}) al nuovo +raggruppamento. + +La versione illustrata è quella usata nella definizione di POSIX.1, in BSD +viene usata una funzione con questo nome, che però è identica a +\func{setpgid}, che vedremo a breve, negli argomenti e negli effetti. 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} ed evitando di definire le macro che richiedono +gli altri standard, come per \func{getpgrp}. + +È inoltre possibile spostare un processo da un raggruppamento di processi ad +un altro cambiandone il \ids{PGID} con la funzione di sistema \funcd{setpgid}, +il cui prototipo è: + +\begin{funcproto}{ +\fhead{unistd.h} +\fdecl{int setpgid(pid\_t pid, pid\_t pgid)} +\fdesc{Modifica il \ids{PGID} di un processo.} +} + +{La funzione ritorna il valore del nuovo \textit{process group} in caso di + successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei + valori: + \begin{errlist} \item[\errcode{ESRCH}] il processo selezionato non esiste. \item[\errcode{EPERM}] il cambiamento non è consentito. - \item[\errcode{EACCES}] il processo ha già eseguito una \func{exec}. + \item[\errcode{EACCES}] il processo di cui si vuole cambiare il \ids{PGID} + ha già eseguito una \func{exec}. \item[\errcode{EINVAL}] il valore di \param{pgid} è negativo. - \end{errlist} - } -\end{prototype} - -La funzione permette di cambiare il \acr{pgid} del processo \param{pid}, ma il -cambiamento può essere effettuato solo se \param{pgid} indica un -\textit{process group} che è nella stessa sessione del processo chiamante. -Inoltre la funzione può essere usata soltanto sul processo corrente o su uno -dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha -ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata - dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in - \struct{task\_struct}.} Specificando un valore nullo per \param{pid} si -indica il processo corrente, mentre specificando un valore nullo per -\param{pgid} si imposta il \textit{process group} al valore del \ids{PID} del -processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0, - 0)}. + \end{errlist} +} +\end{funcproto} + + +La funzione permette di cambiare il \ids{PGID} del processo indicato +dall'argomento \param{pid}, ma il cambiamento può essere effettuato solo se +l'argomento \param{pgid} indica un \textit{process group} che è nella stessa +sessione del processo chiamante. Inoltre la funzione può essere usata +soltanto sul processo corrente o su uno dei suoi figli, ed in quest'ultimo +caso ha successo soltanto se questo non ha ancora eseguito una +\func{exec}.\footnote{questa caratteristica è implementata dal kernel che + mantiene allo scopo un altro campo, \var{did\_exec}, nella struttura + \kstruct{task\_struct}.} Specificando un valore nullo per \param{pid} si +indica il processo corrente, mentre specificando un valore nullo +per \param{pgid} si imposta il \textit{process group} al valore del \ids{PID} +del processo selezionato, questo significa che \func{setpgrp} è equivalente a +\code{setpgid(0, 0)}. Di norma questa funzione viene usata dalla shell quando si usano delle pipeline, per mettere nello stesso \textit{process group} tutti i programmi @@ -267,38 +300,45 @@ occorre eseguirle comunque entrambe per evitare di esporsi ad una Si noti come nessuna delle funzioni esaminate finora permetta di spostare un processo da una sessione ad un altra; infatti l'unico modo di far cambiare -sessione ad un processo è quello di crearne una nuova con l'uso di -\funcd{setsid}; il suo prototipo è: -\begin{prototype}{unistd.h}{pid\_t setsid(void)} - Crea una nuova sessione sul processo corrente impostandone \acr{sid} e - \acr{pgid}. - - \bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di - errore, il solo errore possibile è \errval{EPERM}, che si ha quando il - \acr{pgid} e \ids{PID} del processo coincidono.} -\end{prototype} +sessione ad un processo è quello di crearne una nuova con l'uso della funzione +di sistema \funcd{setsid}, il cui prototipo è: + +\begin{funcproto}{ +\fhead{unistd.h} +\fdecl{pid\_t setsid(void)} +\fdesc{Crea una nuova sessione sul processo corrente.} +} + +{La funzione ritorna il valore del nuovo \ids{SID} in caso di successo e $-1$ + per un errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\errcode{EPERM}] il \ids{PGID} e \ids{PID} del processo coincidono. + \end{errlist} +} +\end{funcproto} + -La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al +La funzione imposta il \ids{PGID} ed il \ids{SID} del processo corrente al valore del suo \ids{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\footnote{in Linux la proprietà - è mantenuta in maniera indipendente con un apposito campo \var{leader} in - \struct{task\_struct}.} se il suo \acr{sid} è uguale al suo \ids{PID}) ed -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. + group} un processo si dice \textsl{leader di sessione} se il suo \ids{SID} è +uguale al suo \ids{PID}) ed unico componente.\footnote{in Linux la proprietà è + mantenuta in maniera indipendente con un apposito campo \var{leader} in + \kstruct{task\_struct}.} 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à \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 \ids{PID} diverso, non ci siano possibilità di +\ids{PGID} del padre ma un \ids{PID} diverso, non ci siano possibilità di errore.\footnote{potrebbe sorgere il dubbio che, per il riutilizzo dei valori dei \ids{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 \ids{PID} solo valori - che non corrispondono ad altri \ids{PID}, \acr{pgid} o \acr{sid} in uso nel + che non corrispondono ad altri \ids{PID}, \ids{PGID} o \ids{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. @@ -324,7 +364,7 @@ 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 \struct{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 +eredita dal padre, insieme al \ids{PGID} e al \ids{SID} anche il terminale di controllo (vedi sez.~\ref{sec:proc_fork}). In questo modo tutti processi originati dallo stesso leader di sessione mantengono lo stesso terminale di controllo. @@ -395,7 +435,7 @@ ad un terminale con la funzione \funcd{tcgetpgrp}, il cui prototipo è: \funcdecl{pid\_t tcgetpgrp(int fd)} Legge il \textit{process group} di \textit{foreground} del terminale associato al file descriptor \param{fd}. - \bodydesc{La funzione restituisce in caso di successo il \acr{pgid} del + \bodydesc{La funzione restituisce in caso di successo il \ids{PGID} del gruppo di \textit{foreground}, e -1 in caso di errore, nel qual caso \var{errno} assumerà i valori: \begin{errlist} @@ -660,7 +700,7 @@ occorrerà predisporlo in modo che esso compia le seguenti azioni: \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 \itindex{process~group~leader} \textit{process group - leader}, (avrà il \acr{pgid} del padre, ma un \ids{PID} diverso) e si può + leader}, (avrà il \ids{PGID} del padre, ma un \ids{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 -- 2.30.2