Ancora orphaned process group
authorSimone Piccardi <piccardi@gnulinux.it>
Tue, 24 Sep 2002 18:12:02 +0000 (18:12 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Tue, 24 Sep 2002 18:12:02 +0000 (18:12 +0000)
html/stampa.html
prochand.tex
session.tex

index ab1e267..a7afd82 100644 (file)
@@ -94,7 +94,7 @@
 
            <p> <b>GaPiL</b> è scritta in LaTeX, la versione aggiornata di
                tutti i file è disponibile in tempo reale sul CVS del <A
-               HREF="http://cvs.firenze.linux.it/"> FLUG</a>, a cui potete
+               HREF="http://firenze.linux.it/">FLUG</a>, a cui potete
                accedere direttamente. La versione online è pubblicata su
                questo sito, e viene periodicamente aggiornata. </P>
 
              </font>
            </b>
          </td>
-         <td bgcolor="lightblue"> 
-           É disponibile l'accesso ai sorgenti completi tramite cvs anonimo;
-           per scaricare la versione corrente (che conterrà probabilmente
-           errori e imprecisioni) si deve usare il comando:
+         <td bgcolor="lightblue"> É disponibile l'accesso ai sorgenti
+           completi tramite CVS anonimo; per scaricare la versione corrente
+           (che conterrà probabilmente errori e imprecisioni) la prima volta
+           si devono usare i comandi:
            <p>
-             cvs -d :pserver:anonymous@cvs.firenze.linux.it:/misc co gapil
+             <b>
+               cvs -d :pserver:anonymous@cvs.firenze.linux.it:/misc login
+               <br>
+               cvs -d :pserver:anonymous@cvs.firenze.linux.it:/misc co gapil
+             </b>
            </p>
+           la password per il login è <b>anonymous</b>. Il resto si può
+           ottenere alla maniera solita. Delle brevi istruzioni sull'uso di
+           CVS le trovate <A
+           HREF="http://firenze.linux.it/~piccardi/build/node4.html"> qui.
+           </a>
          </td>
        </tr>
        <tr>
index e30aff3..5186e41 100644 (file)
@@ -695,7 +695,7 @@ eseguite alla chiusura di un processo 
 \item se la conclusione di un processo rende orfano un \textit{process
     group} ciascun membro del gruppo viene bloccato, e poi gli vengono
   inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}
-  (vedi \secref{sec:sess_xxx}).
+  (vedi \secref{sec:sess_ctrl_term}).
 \end{itemize*}
 
 Oltre queste operazioni è però necessario poter disporre di un meccanismo
index bb207eb..2f73d61 100644 (file)
@@ -60,7 +60,7 @@ questo potr
 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
@@ -279,15 +279,16 @@ controllo.
 
 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.
 
@@ -328,9 +329,11 @@ controllo provocher
 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 è:
@@ -393,47 +396,48 @@ essi potranno essere avvisati che non esiste pi
 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}