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
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.
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}.
+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 è:
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 serve più potrebbero proseguire fino al
-completamento della loro esecuzione). Il problema si pone per quelli che sono
-bloccati, o che si bloccano nell'accesso al terminale.
-
-In questa situazione si ha un cosiddetto \textit{orphaned process group};
-POSIX.1 lo definisce come un \textit{process group} i cui processi hanno come
-padri esclusivamente o altri processi nel gruppo, o processi fuori della
-sessione. Lo standard prevede che se la terminazione di un processo fa sì che
-un process group diventi orfano e se i suoi mebri sono bloccati, a tutti
-vengano inviati in sequenza i segnali di \macro{SIGHUP} e \macro{SIGCONT}.
+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 gruppo, 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 illustrato. 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 dallo stesso. Questo è un caso limite, e non viene emesso
-nessun segnale perché quanto previsto dallo standard riguarda solo i
-raggruppamenti che diventano orfani alla terminazione di un processo.
-
-Il leader di sessione provvederà a creare nuovi process group 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
+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 di processi 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 (a meno di non aver spostato con \func{setpgid} un processo da un gruppo
-ad un altro, cosa che di norma non viene fatta) crati direttamente dal leader
-di sessione i quali riceveranno, nel caso siano bloccati, i due segnali, in
-modo che essi vengano sbloccati da \macro{SIGCONT} e (se non vi è un gestore
-opportuno) terminati da \macro{SIGHUP}.
-
-
-
-
+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, e, essendo stato nel
+frattempo inviato anche \macro{SIGHUP}, se non c'è un gestore per
+quest'ultimo, essi saranno terminati.
- che possa accorgersi
-(si ricordi che per farlo occorre usare \func{waitpid}) se i processi del
-\textit{process group} sono bloccati.
\subsection{Dal login alla shell}
projects / gapil.git / commitdiff