Continua la ristrutturazione.
authorSimone Piccardi <piccardi@gnulinux.it>
Sun, 8 Sep 2002 12:55:07 +0000 (12:55 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sun, 8 Sep 2002 12:55:07 +0000 (12:55 +0000)
session.tex
signal.tex

index b629433ea10b3080ee7ac72b9fcdb74ff1836e38..b97024deb0ee38f8fc2d3d4ab07c2686d80806bf 100644 (file)
@@ -1,32 +1,95 @@
-\chapter{Sessioni di lavoro}
+\chapter{Sessioni di lavoro e terminali}
 \label{cha:session}
 
-Unix nasce prima dell'esistenza dei moderni PC, quando i computer occupavano
-stanze intere e ci si poteva collegare solo attraverso dei terminali, ma fin
-dalle sue origini è sempre stato un sistema multitasking e multiutente,
-in grado di consentire l'utilizzo di un solo computer da parte di più persone.
-
 Esamineremo in questo capitolo i concetti base del sistema delle sessioni di
 lavoro, vale a dire il metodo con cui il kernel gestisce l'accesso concorrente
 al sistema da parte di più utenti, permettendo loro di eseguire più programmi
-in contemporanea.
+in contemporanea.  Nella seconda parte del capitolo tratteremo poi il
+funzionamento dell'I/O su terminale, e delle varie peculiarità che esso viene
+ad assumere a causa del suo stretto legame con le modalità di accesso al
+sistema da parte degli utenti.
 
 
-\section{Il \textit{Job control}}
+\section{Il \textit{job control}}
 \label{sec:sess_job_control}
 
-Viene comunemente chiamato \textit{Job control} quell'insieme di funzionalità
-del sistema il cui scopo è quello di permettere ad un utente di poter
-sfruttare le capacità multitasking di un sistema Unix per eseguire in
-contemporanea più processi, pur potendo accedere, di solito, ad un solo
-terminale,\footnote{con X e con i terminali vituali tutto questo non è più
-  vero, dato che si può accedere a molti terminali in contemporanea, ma il
-  sistema è nato prima dell'esistenza di tutto ciò.} avendo cioè un solo punto
-in cui si può avere accesso all'input ed all'output degli stessi.
+Viene comunemente chiamato \textit{job control} quell'insieme di funzionalità
+il cui scopo è quello di permettere ad un utente di poter sfruttare le
+capacità multitasking di un sistema Unix per eseguire in contemporanea più
+processi, pur potendo accedere, di solito, ad un solo terminale,\footnote{con
+  X e con i terminali vituali tutto questo non è più vero, dato che si può
+  accedere a molti terminali in contemporanea, ma il sistema è nato prima
+  dell'esistenza di tutto ciò.} avendo cioè un solo punto in cui si può avere
+accesso all'input ed all'output degli stessi. 
+
+
+\subsection{Una panoramica introduttiva}
+\label{sec:sess_job_control_overview}
+
+Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
+negli anni '80, e successivamente standardizzata da POSIX.1; la sua
+disponibilità nel sistema è verificabile attraverso il controllo della macro
+\macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il
+supporto sia da parte della shell (quasi tutte ormai lo fanno), che da parte
+del kernel; in particolare il kernel deve assicurare sia la presenza di un
+driver per i terminali abilitato al \textit{job control} che quella dei
+relativi segnali illustrati in \secref{sec:sig_job_control}. 
+
+In un sistema che supporta il \textit{job cotrol} una volta completato il
+login (che esamineremo in dettaglio in \secref{sec:sess_login}), l'utente avrà
+a disposizione una shell dalla quale eseguire i comandi e potrà iniziare
+quella che viene chiamata una \textsl{sessione}, che riunisce (vedi
+\secref{sec:sess_sessions}) tutti i processi eseguiti all'interno dello stesso
+login.
+
+Siccome la shell è collegata ad un solo terminale (il \textsl{terminale di
+  controllo}, vedi \secref{sec:sess_control_term}) solo un 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} (si fa 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
+più programmi in una sola riga di comando con le pipe, ed in tal caso verranno
+eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
+questo potrà sempre lanciare altri processi per eseguire dei compiti
+specifici.
+
+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
+\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.
+
+In generale allora all'interno di una sessione avremo un solo \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} 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 in lettura o
+scrittura)
+
+
+
+
+
+
+
+
+
+
+
+
+\subsection{I \textit{process group}}
+\label{sec:sess_proc_group}
 
 
-\subsection{La struttura di base}
-\label{sec:sess_relation}
 
 Per poter gestire il \textit{Job Control} il kernel associa a ciascun processo
 due ulteriori identificatori (oltre quelli visti in \secref{sec:proc_pid}):
@@ -47,45 +110,24 @@ suo stesso \acr{pid} (creando cos
 si modifica il \acr{sid} il processo viene automaticamente messo anche in un
 nuovo \textit{process group}, corrispondente al suo \acr{pid}.
 
-Per capire meglio il significato di questi identificatori vediamone subito
-l'uso concreto nella gestione del \textit{job control} della linea di comando.
-Una volta che si è completata la procedura di login (che esamineremo in
-dettaglio in \secref{sec:sess_login}), si avrà a disposizione una shell,
-associata ad un terminale (detto \textsl{terminale di controllo}), dalla quale
-eseguire i comandi, una delle caratteristiche della shell è quella di
-consentire di inviare un comando in \textit{background}, cioè di farlo
-eseguire distaccandolo dal terminale, che potrà essere utilizzato da altri
-comandi. Così un solo un comando alla volta potrà leggere e scrivere sul
-terminale (quello che viene detto in \textit{foreground}).
-
-Fra le funzionalità della shell c'è anche quella di consentire di concatenare
-più programmi in una sola riga di comando con le pipe, in tal caso verranno
-eseguiti più programmi, inoltre, anche quando si invoca un singolo programma,
-questo può sempre lanciare ulteriori sottoprocessi per eseguire dei compiti
-specifici. In tutti qesti casi la shell farà sì che tutti i processi che
-originano da un sola riga di comando vengano raggruppati in un unico
-\textit{process group}; questo perché i segnali inviati sul terminale con i
-comandi da tastiera (quelli illustrati in \secref{sec:sig_job_control})
-vengono inviati a tutti i processi che fan parte del raggruppamento di
-\textit{foreground}, cioè quelli che stanno corre
-
 
-Per consentire l'utilizzo contemporaneo dello stesso terminale la shell deve
-essere in grado di garantire che solo un comando alla volta possa accedervi; 
 
 
+\subsection{Le sessioni}
+\label{sec:sess_sessions}
 
 
 
-Lo stato del sistema può essere verificato con il comando \cmd{ps -je f}
+\subsection{Il terminale di controllo}
+\label{sec:sess_ctrl_term}
 
 
 
-\subsection{Il login ed il terminale di controllo}
+\subsection{La procedura di login}
 \label{sec:sess_login}
 
-L'organizzazione del sistema del \textit{Job Control} è strettamente connessa
-alle modalità con cui un utente accede al sistema, collegandosi ad esso con un
+L'organizzazione del sistema del job control è strettamente connessa alle
+modalità con cui un utente accede al sistema, collegandosi ad esso con un
 terminale, che sia questo realmente tale, come un VT100 collegato ad una
 seriale o virtuale, come quelli associati a schermo e tastiera o ad una
 connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
@@ -196,24 +238,18 @@ per ripetere da capo tutto il procedimento.
 
 
 
-\subsection{I \textit{process group}}
-\label{sec:sess_proc_group}
-
-
-
-\subsection{Le sessioni}
-\label{sec:sess_sessions}
+Lo stato del sistema può essere verificato con il comando \cmd{ps -je f}
 
 
 
-\subsection{Il terminale di controllo}
-\label{sec:sess_ctrl_term}
 
 
 
-\subsection{La shell e i programmi}
-\label{sec:sess_shell}
+\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 
 
 
 %%% Local Variables: 
index 14e6d51dd03f51af9e8c478fe7a0a8b719056414..ea55790e3cf568567f24bcc8657330a37789c448 100644 (file)
@@ -622,21 +622,21 @@ cui si trattano gli argomenti relativi.  Questi segnali sono:
   intercettato, né ignorato, né bloccato.
 \item[\macro{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale
   ferma il processo interattivamente, ed è generato dal carattere SUSP
-  (prodotto dalla combinazione \macro{C-z}), ed al contrario di
+  (prodotto dalla combinazione \cmd{C-z}), ed al contrario di
   \macro{SIGSTOP} può essere intercettato e ignorato. In genere un programma
   installa un gestore per questo segnale quando vuole lasciare il sistema
   o il terminale in uno stato definito prima di fermarsi; se per esempio un
   programma ha disabilitato l'eco sul terminale può installare un gestore
   per riabilitarlo prima di fermarsi.
 \item[\macro{SIGTTIN}] Un processo non può leggere dal terminale se esegue una
-  sessione di lavoro in background. Quando un processo in background tenta di
-  leggere da un terminale viene inviato questo segnale a tutti i processi
-  della sessione di lavoro. L'azione predefinita è di fermare il processo.
-  L'argomento è trattato in \secref{sec:sess_xxx}.
+  sessione di lavoro in \textit{background}. Quando un processo in background
+  tenta di leggere da un terminale viene inviato questo segnale a tutti i
+  processi della sessione di lavoro. L'azione predefinita è di fermare il
+  processo.  L'argomento è trattato in \secref{sec:sess_job_control_overview}.
 \item[\macro{SIGTTOU}] Segnale analogo al precedente \macro{SIGTTIN}, ma
   generato quando si tenta di scrivere o modificare uno dei modi del
   terminale. L'azione predefinita è di fermare il processo, l'argomento è
-  trattato in \secref{sec:sess_xxx}.
+  trattato in \secref{sec:sess_job_control_overview}.
 \end{basedescript}