Per questo l'esecuzione di un comando può originare più di un processo; quindi
nella gestione del job control non si può far riferimento ai singoli processi.
Per questo il kernel prevede la possibilità di raggruppare più processi in un
-\textit{process group} (detto anche \textsl{raggruppamento}, vedi
+\textit{process group} (detto anche \textsl{raggruppamento di processi}, vedi
\secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
-originano da una riga di comando appartengano allo stesso \textit{process
- group}, in modo che le varie funzioni di controllo, ed i segnali inviati dal
-terminale, possano fare riferimento ad esso.
+originano da una riga di comando appartengano allo stesso raggruppamento, 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 eventuale (possono
-non esserci) \textit{process group} in \textit{foreground}, che riunisce i
+In generale allora all'interno di una sessione avremo un eventuale (può non
+esserci) \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}
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}. Il comando \cmd{fg} consente invece di mettere in
-\textit{foreground} un comando precedentemente lanciato 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.} 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.
+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 \macro{WUNTRACED}, secondo quanto illustrato in
+\secref{sec:proc_wait}).
\subsection{I \textit{process group} e le \textsl{sessioni}}
\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 gruppo di processi ha sempre un processo principale, il cosiddetto
-\textit{process group leader}, che è identificato dall'avere un \acr{pgid}
-uguale al suo \acr{pid}, in genere questo è il primo processo del gruppo, che
-si incarica di lanciare tutti gli altri. Un nuovo gruppo si crea con la
-funzione \func{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 è:
+Ciascun raggruppamento di processi ha sempre un processo principale, il
+cosiddetto \textit{process group leader}, che è identificato dall'avere un
+\acr{pgid} uguale al suo \acr{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 \func{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 \acr{pid} del processo corrente.
\end{prototype}
La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
-corrente, rende questo \textit{process leader} di un nuovo gruppo, tutti i
-successivi processi da esso creati apparterranno (a meno di non cambiare di
-nuovo il \acr{pgid}) al nuovo gruppo. È possibile invece spostare un processo
-da un gruppo ad un altro con la funzione \func{setpgid}, il cui prototipo è:
+corrente, rende questo \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 \func{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}.
\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}. 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 \acr{pid} del
-processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0,
- 0)}.
+ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata
+ dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in
+ \var{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 \acr{pid} del processo
+selezionato; pertanto \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 process group tutti i programmi lanciati su
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
+ 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
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 viene aperto il 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,
+divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò
+ è 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\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}.}
+quando viene aperto il primo terminale (cioè uno dei vari file di dispositivo
+\file{/dev/tty*}) che diventa automaticamente il terminale di controllo,
mentre il processo diventa il \textsl{processo di controllo} di quella
sessione.
In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
associato ai file standard (di input, output ed error) dei processi nella
-sessione, ma solo quelli che fanno parte del cosiddetto gruppo di
+sessione, ma solo quelli che fanno parte del cosiddetto ragruppamento di
\textit{foreground}, possono leggere e scrivere in certo istante. Per
-impostare il gruppo di \textit{foreground} di un terminale si usa la funzione
-\func{tcsetpgrp}, il cui prototipo è:
+impostare il raggruppamento di \textit{foreground} di un terminale si usa la
+funzione \func{tcsetpgrp}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}
un processo nella stessa sessione e con lo stesso terminale di controllo.
Come accennato in \secref{sec:sess_job_control_overview}, tutti i processi (e
-relativi gruppi) che non fanno parte del gruppo di \textit{foreground} sono
-detti in \textit{background}; se uno si essi cerca di accedere al terminale di
-controllo provocherà l'invio da parte del kernel di uno dei due segnali
-\macro{SIGTTIN} o \macro{SIGTTOU} (a seconda che l'accesso sia stato in
-lettura o scrittura) a tutto il suo \textit{process group}; dato che il
+relativi raggruppamenti) che non fanno parte del gruppo di \textit{foreground}
+sono detti in \textit{background}; se uno si essi cerca di accedere al
+terminale di controllo provocherà l'invio da parte del kernel di uno dei due
+segnali \macro{SIGTTIN} o \macro{SIGTTOU} (a seconda che l'accesso sia stato
+in lettura o scrittura) a tutto il suo \textit{process group}; dato che il
comportamento di default di questi segnali (si riveda quanto esposto in
-\secref{sec:sig_job_control}) è di bloccare il processo, di norma questo
-comporta che tutti verranno fermati, ma non si avranno condizioni di
-errore. Se però si bloccano o ignorano i due segnali citati, le funzioni di
-lettura e scrittura falliranno con un errore di \macro{EIO}.
+\secref{sec:sig_job_control}) è di fermare il processo, di norma questo
+comporta che tutti i membri del gruppo verranno fermati, ma non si avranno
+condizioni di errore.\footnote{la shell in genere notifica comunque un
+ avvertimento, avvertendo la presenza di processi bloccati grazie all'uso di
+ \func{waitpid}.} Se però si bloccano o ignorano i due segnali citati, le
+funzioni di lettura e scrittura falliranno con un errore di \macro{EIO}.
Un processo può contollare qual'è il gruppo di \textit{foreground} associato
ad un terminale con la funzione \func{tcgetpgrp}, il cui prototipo è:
processo di accedere direttamente al suo terminale di controllo attraverso il
file speciale \file{/dev/tty}, che per ogni processo è un sinonimo per il
proprio terminale di controllo. Questo consente anche a processi che possono
-aver rediretto l'output di accedere al terminale, pur non disponendo più del
-file descriptor originario; un caso tipico è il programma \cmd{crypt} che
-accetta la redirezione sullo standard input di un file da decrittare, ma deve
-poi leggere la password dal terminale.
-
-Un'altra caratteristica del gruppo di \textit{foreground} è che il kernel
-invia i segnali generati dai caratteri speciali del terminale (\cmd{C-z},
-\cmd{C-c}, \cmd{C-y} e \verb|C-\|, che generano rispettivamente
-\macro{SIGTSTP}, \macro{SIGINT}, \macro{SIGQUIT} e \macro{SIGTERM}), solo ai
-processi che ne fanno parte.
-
-In caso di \textit{hungup} del terminale (si chiama così una condizione di
-blocco del terminale, letteralmente sarebbe \textsl{impiccagione}), ad esempio
-se si interrompe la linea, o va giù la rete, il kernel provvederà ad inviare
-il segnale di \macro{SIGHUP} al processo di controllo. L'azione preimpostata
-in questo caso è la terminazione del processo, il problema è cosa accade agli
-altri processi nella sessione, che non han più un processo di controllo che
-possa gestire l'accesso al terminale, che potrebbe essere riutilizzato per
-qualche altra sessione.
-
-Lo standard POSIX.1 prevede che se il processo di controllo termina (che ciò
-avvenga per un \textit{hungup} del terminale o meno) venga inviato un segnale
-di \macro{SIGHUP} ai processi del gruppo di foreground. In questo modo essi
-potranno essere avvisati che non esiste più un processo in grado di gestire il
-terminale (di norma tutto ciò comporta la terminazione anche di questi
-ultimi).
-
-Restano però i processi in background, che, per quanto detto, potrebbero
-proseguire la loro esecuzione e, fintanto che non accedono al terminale non ci
-sarebbero problemi. In caso di accesso però potrebbero (in seguito al
-comportamento standard appena descritto) bloccarsi, e restare tali per sempre,
-dato che non c'è più il processo di controllo. Questa situazione è quella che
-in cui si ha un cosiddetto \textit{orphaned process group}, che POSIX.1
-definisce come un \textit{process group} i cui processi hanno come padri o
-altri processi nel gruppo, o processi fuori della sessione.
-
-Si ricordi che un processo è detto orfano quando il suo padre è terminato, nel
-qual caso viene adottato da \cmd{init}, che è al di fuori di qualunque
-sessione,
+aver rediretto l'output di accedere al terminale di controllo, pur non
+disponendo più del file descriptor originario; un caso tipico è il programma
+\cmd{crypt} che accetta la redirezione sullo standard input di un file da
+decrittare, ma deve poi leggere la password dal terminale.
+
+Un'altra caratteristica del terminale di controllo usata nel job control è che
+utilizzando su di esso le combinazioni di tasti speciali (\cmd{C-z},
+\cmd{C-c}, \cmd{C-y} e \verb|C-\|) si farà sì che il kernel invii i
+corrispondenti segnali (rispettivamente \macro{SIGTSTP}, \macro{SIGINT},
+\macro{SIGQUIT} e \macro{SIGTERM}, trattati in \secref{sec:sig_job_control}) a
+tutti i processi del raggruppamento di \textit{foreground}; in questo modo la
+shell può gestire il blocco e l'interruzione dei vari comandi.
+
+Per completare la trattazione delle caratteristiche del job control legate al
+terminale di controllo, occorre prendere in considerazione i vari casi legati
+alla terminazione anomala dei processi, che sono di norma gestite attraverso
+il segnale \macro{SIGHUP}. Il nome del segnale deriva da \textit{hungup},
+termine che viene usato per indicare la condizione in cui il terminale diventa
+inutilizzabile, (letteralmente sarebbe \textsl{impiccagione}).
+
+Quando si verifica questa condizione, ad esempio se si interrompe la linea, o
+va giù la rete o più semplicemente si chiude forzatamente la finestra di
+terminale su cui si stava lavorando, il kernel provvederà ad inviare il
+segnale di \macro{SIGHUP} al processo di controllo. L'azione preimpostata in
+questo caso è la terminazione del processo, il problema che si pone è cosa
+accade agli altri processi nella sessione, che non han più un processo di
+controllo che possa gestire l'accesso al terminale, che potrebbe essere
+riutilizzato per qualche altra sessione.
+
+Lo standard POSIX.1 prevede che quando il processo di controllo termina, che
+ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si
+potrebbe terminare direttamente la shell con \cmd{kill}) venga inviato un
+segnale di \macro{SIGHUP} ai processi del raggruppamento di foreground. In
+questo modo essi potranno essere avvisati che non esiste più un processo in
+grado di gestire il terminale (di norma tutto ciò comporta la terminazione
+anche di questi ultimi).
+
+Restano però gli eventuali processi in background, che non ricevono il
+segnale; in effetti se il terminale non dovesse più servire essi potrebbero
+proseguire fino al completamento della loro esecuzione; ma si pone il problema
+di come gestire quelli che sono bloccati, o che si bloccano nell'accesso al
+terminale, in assenza di un processo che sia in grado di effettuare il
+controllo dello stesso.
+
+Questa è la situazione in cui si ha quello che viene chiamato un
+\textit{orphaned process group}. Lo standard POSIX.1 lo definisce come un
+\textit{process group} i cui processi hanno come padri esclusivamente o altri
+processi nel raggruppamento, o processi fuori della sessione. Lo standard
+prevede inoltre che se la terminazione di un processo fa sì che un
+raggruppamento di processi diventi orfano e se i suoi membri sono bloccati, ad
+essi vengano inviati in sequenza i segnali di \macro{SIGHUP} e
+\macro{SIGCONT}.
+
+La definizione può sembrare complicata, e a prima vista non è chiaro cosa
+tutto ciò abbia a che fare con il problema della terminazione del processo di
+controllo. Consideriamo allora cosa avviene di norma nel \textit{job
+ control}: una sessione viene creata con \func{setsid} che crea anche un
+nuovo process group: per definizione quest'ultimo è sempre \textsl{orfano},
+dato che il padre del leader di sessione è fuori dalla stessa e il nuovo
+process group contiene solo il leader di sessione. Questo è un caso limite, e
+non viene emesso nessun segnale perché quanto previsto dallo standard riguarda
+solo i raggruppamenti che diventano orfani in seguito alla terminazione di un
+processo.\footnote{l'emissione dei segnali infatti avviene solo nella fase di
+ uscita del processo, come una delle operazioni legate all'esecuzione di
+ \func{\_exit}, secondo quanto illustrato in \secref{sec:proc_termination}.}
+
+Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
+punto non sono orfani in quanto esso resta padre per almeno uno dei processi
+del gruppo (gli altri possono derivare dal primo). Alla terminazione del
+leader di sessione però avremo che, come visto in
+\secref{sec:proc_termination}, tutti i suoi figli vengono adottati da
+\cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process
+group creati direttamente dal leader di sessione (a meno di non aver spostato
+con \func{setpgid} un processo da un gruppo ad un altro, cosa che di norma non
+viene fatta) i quali riceveranno, nel caso siano bloccati, i due segnali;
+\macro{SIGCONT} ne farà proseguire l'esecuzione, ed essendo stato nel
+frattempo inviato anche \macro{SIGHUP}, se non c'è un gestore per
+quest'ultimo, i processi bloccati verranno automaticamente terminati.
A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
-ad eseguire con un'altra \func{exec} la shell di login, che si troverà con un
-ambiente già pronto e con file standard di \secref{sec:file_std_descr}
-impostati sul terminale, pronta ad eseguire i comandi fino all'uscita. Dato
-che il processo genitore resta sempre \cmd{init} quest'ultimo provvederà,
-ricevendo un \macro{SIGCHLD} all'uscita della shell, a rilanciare \cmd{getty}
-per ripetere da capo tutto il procedimento.
-
-
-
-
-In generale quando con il contollo di sessione è la shell che assume il ruolo
-di processo di controllo, seleziona il gruppo di \textit{foregroud} e gestisce
-l'assegnazione dei process group ai programmi eseguiti sulla stessa riga di
-comando.
-
-Qualora un processo venga bloccato nella gestione della sessione, sia
-implicitamente, perché cerca di eseguire dell'I/O sul terminale mentre è in
-background, sia esplicitamente con l'uso di \cmd{C-z}, la shell è in grado di
-rilevare l'evento grazie all'uso di \func{waitpid} con l'opzione
-\macro{WUNTRACED}. In questo modo la shell può notificare (di solito prima
-della stampa del prompt, lo stato dei vari processi.
-
-
+ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente
+già pronto con i file standard di \secref{sec:file_std_descr} impostati sul
+terminale, e pronta, nel ruolo di leader di sessione e processo di controllo
+per il terminale, a gestire l'esecuzione dei comandi come illustrato in
+\secref{sec:sess_job_control_overview}. Dato che il processo padre resta
+sempre \cmd{init} quest'ultimo potrà provvedere, ricevendo un \macro{SIGCHLD}
+all'uscita della shell, a rilanciare \cmd{getty} sul terminale per ripetere da
+capo tutto il procedimento.
\section{L'I/O su terminale}
\label{sec:sess_terminal_io}
-Esamineremo in questa sezione le peculiarità dell'I/O su terminale, tenendo
-conto delle
+Esamineremo in questa sezione le peculiarità dell'I/O eseguito sui terminali,
+tenendo conto delle differenze che quest'ultimi presentano rispetto ai normali
+file su disco.
+
+
%%% Local Variables:
projects / gapil.git / blobdiff