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
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,
-
+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à si 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 gruppo 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 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ò 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}.
+
+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
+\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}.
+
+
+
+
+
+
+ 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}
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
projects / gapil.git / commitdiff