From 5b2a6aa7395bed71cf47e8183cecd78c4b02fe5e Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sun, 8 Sep 2002 12:55:07 +0000 Subject: [PATCH] Continua la ristrutturazione. --- session.tex | 150 ++++++++++++++++++++++++++++++++-------------------- signal.tex | 12 ++--- 2 files changed, 99 insertions(+), 63 deletions(-) diff --git a/session.tex b/session.tex index b629433..b97024d 100644 --- a/session.tex +++ b/session.tex @@ -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: diff --git a/signal.tex b/signal.tex index 14e6d51..ea55790 100644 --- a/signal.tex +++ b/signal.tex @@ -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} -- 2.30.2