Correzioni di altre referenze, quasi finito coi terminali di controllo.
authorSimone Piccardi <piccardi@gnulinux.it>
Fri, 13 Sep 2002 21:49:24 +0000 (21:49 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Fri, 13 Sep 2002 21:49:24 +0000 (21:49 +0000)
fileadv.tex
fileintro.tex
prochand.tex
session.tex

index 05e75f67e5a0fd1825c9efe8b0c9a6aa0e339465..a7f5b0d7d787211d913d9411b70302fde5fd0380 100644 (file)
@@ -169,7 +169,8 @@ Come accennato l'interfaccia di \func{select} 
 System V ha introdotto una sua interfaccia per gestire l'\textit{I/O
   multiplexing}, basata sulla funzione \func{poll},\footnote{la funzione è
   prevista dallo standard XPG4, ed è stata introdotta in Linux come system
 System V ha introdotto una sua interfaccia per gestire l'\textit{I/O
   multiplexing}, basata sulla funzione \func{poll},\footnote{la funzione è
   prevista dallo standard XPG4, ed è stata introdotta in Linux come system
-  call a partire dal kernel 2.1.23 e dalle \acr{libc} 5.4.28.} il cui prototipo è:
+  call a partire dal kernel 2.1.23 e dalle \acr{libc} 5.4.28.} il cui
+prototipo è:
 \begin{prototype}{sys/poll.h}
   {int poll(struct pollfd *ufds, unsigned int nfds, int timeout)}
 
 \begin{prototype}{sys/poll.h}
   {int poll(struct pollfd *ufds, unsigned int nfds, int timeout)}
 
@@ -308,7 +309,7 @@ del test e riabilitandolo poi grazie all'uso di \param{sigmask}.
 
 
 
 
 
 
-\subsection{L'\textsl{I/O asincrono}}
+\subsection{L'I/O asincrono}
 \label{sec:file_asyncronous_io}
 
 Una modalità alternativa all'uso dell'\textit{I/O multiplexing} è quella di
 \label{sec:file_asyncronous_io}
 
 Una modalità alternativa all'uso dell'\textit{I/O multiplexing} è quella di
index a55e5ac9c313e546e36704882afdea65e496d04d..77dae72993695399d43891dbae771aecd96ab044 100644 (file)
@@ -515,7 +515,7 @@ lista degli inodes e lo spazio a disposizione per i dati e le directory.
 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering
-  \includegraphics[width=12cm]{img/disk_struct}
+  \includegraphics[width=14cm]{img/disk_struct}
   \caption{Organizzazione dello spazio su un disco in partizioni e
   filesystem.}
   \label{fig:file_disk_filesys}
   \caption{Organizzazione dello spazio su un disco in partizioni e
   filesystem.}
   \label{fig:file_disk_filesys}
@@ -529,7 +529,7 @@ esemplificare la situazione con uno schema come quello esposto in \nfig.
 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering
-  \includegraphics[width=12cm]{img/filesys_struct}
+  \includegraphics[width=14cm]{img/filesys_struct}
   \caption{Strutturazione dei dati all'interno di un filesystem.}
   \label{fig:file_filesys_detail}
 \end{figure}
   \caption{Strutturazione dei dati all'interno di un filesystem.}
   \label{fig:file_filesys_detail}
 \end{figure}
@@ -583,7 +583,7 @@ abbiamo aggiunto dei numeri di inode.
 
 \begin{figure}[htb]
   \centering 
 
 \begin{figure}[htb]
   \centering 
-  \includegraphics[width=12cm]{img/dir_links}
+  \includegraphics[width=14cm]{img/dir_links}
   \caption{Organizzazione dei link per le directory.}
   \label{fig:file_dirs_link}
 \end{figure}
   \caption{Organizzazione dei link per le directory.}
   \label{fig:file_dirs_link}
 \end{figure}
index 04b24efd31f50c0151c5b8e42ad9fe9f67ef5bdf..e30aff30321ecc136975882ea7e81467c8311f9a 100644 (file)
@@ -930,7 +930,9 @@ controllo di sessione, trattato in \secref{sec:sess_job_control}) che fa
 ritornare la funzione anche per i processi figli che sono bloccati ed il cui
 stato non è stato ancora riportato al padre. Il valore dell'opzione deve
 essere specificato come maschera binaria ottenuta con l'OR delle suddette
 ritornare la funzione anche per i processi figli che sono bloccati ed il cui
 stato non è stato ancora riportato al padre. Il valore dell'opzione deve
 essere specificato come maschera binaria ottenuta con l'OR delle suddette
-costanti con zero.
+costanti con zero. In Linux sono previste altre opzioni non standard relative
+al comportamento con i thread, che saranno trattate in
+\secref{sec:thread_xxx}.
 
 La terminazione di un processo figlio è chiaramente un evento asincrono
 rispetto all'esecuzione di un programma e può avvenire in un qualunque
 
 La terminazione di un processo figlio è chiaramente un evento asincrono
 rispetto all'esecuzione di un programma e può avvenire in un qualunque
index 92e532d847973d7be79692c3daaf934010c6ebd3..756984321132fe5d73b3a9666287e436218fd508 100644 (file)
@@ -43,13 +43,13 @@ potr
 dello stesso login (esamineremo tutto il processo in dettaglio in
 \secref{sec:sess_login}).
 
 dello stesso login (esamineremo tutto il processo in dettaglio in
 \secref{sec:sess_login}).
 
-Siccome la shell è collegata ad un solo terminale (che viene usualmente
-chiamato \textsl{terminale di controllo}, vedi \secref{sec:sess_ctrl_term}) un
-solo comando alla volta (quello che viene detto in \textit{foreground}), potrà
-scrivere e leggere dal terminale. La shell però può eseguire anche più comandi
-in contemporanea, mandandoli in \textit{background} (aggiungendo una \cmd{\&}
-alla fine del comando), nel qual caso essi saranno eseguiti senza essere
-collegati al terminale.
+Siccome la shell è collegata ad un solo terminaleche viene usualmente
+chiamato \textsl{terminale di controllo}, (vedi \secref{sec:sess_ctrl_term})
+un solo comando alla volta (quello che viene detto in \textit{foreground}),
+potrà scrivere e leggere dal terminale. La shell però può eseguire anche più
+comandi in contemporanea, mandandoli in \textit{background} (aggiungendo una
+\cmd{\&} alla fine del comando), 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
 funzionalità della shell infatti c'è anche quella di consentire di concatenare
 
 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
@@ -71,21 +71,16 @@ 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}
 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}
-cerca di accedere al terminale questo invii a tutti i processi del
-raggruppamento un segnale di \macro{SIGTTIN} o di \macro{SIGTTOU}, a seconda
-che l'accesso sia rispettivamente in lettura o scrittura, bloccando (secondo
-il comportamento di default esposto in \secref{sec:sig_job_control}) i
-processi.
+cerca di accedere al terminale, venga inviato un segnale a tutti i processi
+del raggruppamento, in modo da bloccarli (vedi \secref{sec:sess_ctrl_term}).
 
 Un comportamento analogo si ha anche per i segnali generati dai comandi di
 
 Un comportamento analogo si ha anche per i segnali generati dai comandi di
-tastiera inviati dal terminale con \cmd{C-z}, \cmd{C-c}, \cmd{C-y} e
-\verb|C-\|; questi generano rispettivamente i segnali \macro{SIGTSTP},
-\macro{SIGINT}, \macro{SIGQUIT} e \macro{SIGTERM}, che vengono inviati a tutti
-i processi del raggruppamento in \textit{foreground}. In particolare il primo
-di essi, \macro{SIGTSTP}, 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}.
+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}.
 
 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
 
 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
@@ -278,26 +273,130 @@ di controllo. \footnote{Lo standard POSIX.1 non specifica nulla riguardo
   l'implementazione; in Linux anch'esso viene mantenuto nella solita struttura
   \var{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
   l'implementazione; in Linux anch'esso viene mantenuto nella solita struttura
   \var{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
-controllo. In questo modo tutti processi originati dallo stesso leader di
-sessione mantengono lo stesso terminale di controllo.
+controllo (vedi \secref{sec:proc_fork}). In questo modo tutti processi
+originati dallo stesso leader di sessione mantengono lo stesso terminale di
+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
 
 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 il leader di sessione apre il suo 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. 
+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,
+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
+\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 è:
+\begin{functions}
+  \headdecl{unistd.h}
+  \headdecl{termios.h}
+  
+  \funcdecl{int tcsetpgrp(int fd, pid\_t pgrpid)} Imposta a \param{pgrpid} il
+  \textit{process group} di \textit{foreground} del terminale associato al
+  file descriptor \param{fd}.
+   
+  \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
+    errore, nel qual caso \var{errno} assumerà i valori:
+    \begin{errlist}
+    \item[\macro{ENOTTY}] Il file \param{fd} non corrisponde al terminale di
+      controllo del processo chiamante.
+    \item[\macro{ENOSYS}] Il sistema non supporta il job control.
+    \item[\macro{EPERM}] Il \textit{process group} specificato non è nella
+    stessa sessione del processo chiamante.
+    \end{errlist}
+    ed inoltre \macro{EBADF} ed \macro{EINVAL}. 
+  }
+\end{functions}
+\noindent la funzione può essere eseguita con successo solo da
+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
+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}.
+
+Un processo può contollare qual'è il gruppo di \textit{foreground} associato
+ad un terminale con la funzione \func{tcgetpgrp}, il cui prototipo è:
+\begin{functions}
+  \headdecl{unistd.h} \headdecl{termios.h}
+  
+  \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
+    gruppo di \textit{foreground}, e -1 in caso di errore, nel qual caso
+    \var{errno} assumerà i valori:
+    \begin{errlist}
+    \item[\macro{ENOTTY}] Non c'è un terminale di controllo o \param{fd} non
+      corrisponde al terminale di controllo del processo chiamante.
+    \end{errlist}
+    ed inoltre \macro{EBADF} ed \macro{ENOSYS}. 
+  }
+\end{functions}
+
+Si noti come entrambe le funzioni usino come argomento il valore di un file
+descriptor, il risultato comunque non dipende dal file descriptor che si usa
+ma solo dal terminale cui fa riferimento; il kernel inoltre permette a ciascun
+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, 
 
 
-Per ciascuna sessione di lavoro avremo allora un terminale di controllo, ed un
-processo di \textit{foreground}, che è quello 
 
 
-Il kernel identifica 
 
 \subsection{Dal login alla shell}
 \label{sec:sess_login}
 
 \subsection{Dal login alla shell}
 \label{sec:sess_login}
@@ -415,6 +514,23 @@ 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. 
+
+
+
+
+
 \subsection{Prescrizioni per un programma \textit{daemon}}
 \label{sec:sess_daemon}
 
 \subsection{Prescrizioni per un programma \textit{daemon}}
 \label{sec:sess_daemon}