Correzioni e chiarimenti in base ai suggerimenti di D. Masini, prima
authorSimone Piccardi <piccardi@gnulinux.it>
Thu, 21 Nov 2002 19:51:27 +0000 (19:51 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Thu, 21 Nov 2002 19:51:27 +0000 (19:51 +0000)
parte.

ChangeLog
fileintro.tex
process.tex
prochand.tex
session.tex

index 2d63dd8..1dfa3b3 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2002-11-21  Simone Piccardi  <piccardi@firenze.linux.it>
+
+       * prochand.tex: Correzioni e chiarimenti su suggerimento di D. Masini.
+
+       * process.tex: Correzioni varie da D. Masini.
+
 2002-10-23  Simone Piccardi  <piccardi@firenze.linux.it>
 
        * process.tex: Aggiunta nota di Daniele Masini sulle differenze
index 794d611..d20ab6b 100644 (file)
@@ -84,7 +84,7 @@ specificandone il nome\footnote{Il manuale delle \acr{glibc} chiama i nomi
     components}), noi li chiameremo più semplicemente \textit{nomi}.} da essa
 contenuto.  All'interno dello stesso albero si potranno poi inserire anche
 tutti gli altri oggetti visti attraverso l'interfaccia che manipola i file
-come le fifo, i link, i socket e gli stessi file di dispositivo (questi
+come le fifo, i link, i socket e gli stessi file di dispositivo (questi
 ultimi, per convenzione, sono inseriti nella directory \file{/dev}).
 
 Il nome completo di un file viene chiamato \textit{pathname} ed il
@@ -111,8 +111,9 @@ parte dalla directory corrente (su cui torneremo in
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
 in ogni directory: il primo fa riferimento alla directory corrente e il
 secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè
-la directory che contiene il riferimento alla directory corrente; nel caso
-questa sia la directory radice, allora il riferimento è a se stessa.
+la directory che contiene il riferimento alla directory corrente; nel caso la
+directory corrente coincida con la directory radice, allora il riferimento è a
+se stessa.
 
 
 \subsection{I tipi di file}
@@ -330,16 +331,16 @@ POSIX.1 dei sistemi Unix, ed 
 \label{sec:file_arch_func}
 
 Per capire fino in fondo le proprietà di file e directory in un sistema
-unix-like ed il comportamento delle relative funzioni di manipolazione occorre
-una breve introduzione al funzionamento gestione dei file da parte del kernel
-e sugli oggetti su cui è basato un filesystem. In particolare occorre tenere
-presente dov'è che si situa la divisione fondamentale fra kernel space e user
-space che tracciavamo al \capref{cha:intro_unix}.
+unix-like ed il comportamento delle relative funzioni di manipolazione,
+occorre una breve introduzione al funzionamento gestione dei file da parte del
+kernel e sugli oggetti su cui è basato un filesystem. In particolare occorre
+tenere presente dov'è che si situa la divisione fondamentale fra kernel space
+e user space che tracciavamo al \capref{cha:intro_unix}.
 
 In questa sezione esamineremo come viene implementato l'accesso ai file in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
 prima le caratteristiche generali di un filesystem di un sistema unix-like,
-per poi trattare in maniera un po' più dettagliata il filesystem standard di
+per poi trattare in maniera un po' più dettagliata il filesystem più usato con
 Linux, l'\acr{ext2}.
 
 % in particolare si riprenderà, approfondendolo sul piano dell'uso nelle
@@ -348,7 +349,7 @@ Linux, l'\acr{ext2}.
 % \secref{sec:file_vfs}.
 
 
-\subsection{Il \textit{Virtual Filesystem} di Linux}
+\subsection{Il \textit{Virtual File System} di Linux}
 \label{sec:file_vfs}
 
 % Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
@@ -358,7 +359,7 @@ Linux, l'\acr{ext2}.
 % \textit{inode}, \textit{dentry}, \textit{dcache}.
 
 In Linux il concetto di \textit{everything is a file} è stato implementato
-attraverso il \textit{Virtual Filesystem} (da qui in avanti VFS) che è uno
+attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è uno
 strato intermedio che il kernel usa per accedere ai più svariati filesystem
 mantenendo la stessa interfaccia per i programmi in user space. Esso fornisce
 un livello di indirezione che permette di collegare le operazioni di
index 67cb4f5..dd898a8 100644 (file)
@@ -680,7 +680,7 @@ l'attuale posizione della fine del segmento dati.
 Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
 per i programmi normali è sempre opportuno usare le funzioni di allocazione
 standard descritte in precedenza, che sono costruite su di esse.  L'uso di
-queste funzione è ristretto alle specifiche necessità di chi debba
+queste funzioni è ristretto alle specifiche necessità di chi debba
 implementare una sua versione delle routine di allocazione.  
 
 
index 4bb15c6..4348a7b 100644 (file)
@@ -32,8 +32,9 @@ generazione di nuovi processi 
 caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
 qualunque processo può a sua volta generarne altri, detti processi figli
 (\textit{child process}). Ogni processo è identificato presso il sistema da un
-numero unico, il cosiddetto \textit{process identifier} o, più brevemente, 
-\acr{pid}.
+numero univoco, il cosiddetto \textit{process identifier} o, più brevemente,
+\acr{pid}, assengnato in forma progressiva (vedi \secref{sec:proc_pid}) quando
+il processo viene creato.
 
 Una seconda caratteristica di un sistema Unix è che la generazione di un
 processo è un'operazione separata rispetto al lancio di un programma. In
@@ -159,7 +160,7 @@ I processi vengono creati dalla funzione \func{fork}; in molti unix questa 
 una system call, Linux però usa un'altra nomenclatura, e la funzione
 \func{fork} è basata a sua volta sulla system call \func{\_\_clone}, che viene
 usata anche per generare i \textit{thread}.  Il processo figlio creato dalla
-\func{fork} è una copia identica del processo processo padre, ma ha nuovo
+\func{fork} è una copia identica del processo processo padre, ma ha un nuovo
 \acr{pid} e viene eseguito in maniera indipendente (le differenze fra padre e
 figlio sono affrontate in dettaglio in \secref{sec:proc_fork}).
 
@@ -187,7 +188,7 @@ Il programma che un processo sta eseguendo si chiama immagine del processo (o
 \textit{process image}), le funzioni della famiglia \func{exec} permettono di
 caricare un'altro programma da disco sostituendo quest'ultimo all'immagine
 corrente; questo fa sì che l'immagine precedente venga completamente
-cancellata. Questo significa che quando il nuovo programma esce, anche il
+cancellata. Questo significa che quando il nuovo programma termina, anche il
 processo termina, e non si può tornare alla precedente immagine.
 
 Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
@@ -212,18 +213,21 @@ programmi.
 \label{sec:proc_pid}
 
 Come accennato nell'introduzione, ogni processo viene identificato dal sistema
-da un numero identificativo unico, il \textit{process id} o \acr{pid};
+da un numero identificativo univoco, il \textit{process id} o \acr{pid};
 quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
 intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
 \ctyp{int}).
 
-Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
-processo viene creato, fino ad un limite che, essendo il \acr{pid} un numero
-positivo memorizzato in un intero a 16 bit, arriva ad un massimo di 32767.
-Oltre questo valore l'assegnazione riparte dal numero più basso disponibile a
-partire da un minimo di 300,\footnote{questi valori, fino al kernel 2.4.x,
-  sono definiti dalla macro \macro{PID\_MAX} in \file{threads.h} e
-  direttamente in \file{fork.c}, con il kernel 2.5.x e la nuova interfaccia
+Il \acr{pid} viene assegnato in forma progressiva\footnote{in genere viene
+  assegnato il numero successivo a quello usato per l'ultimo processo creato,
+  a meno che questo numero non sia già utilizzato per un altro \acr{pid},
+  \acr{pgid} o \acr{sid} (vedi \secref{sec:sess_proc_group}).} ogni volta che
+un nuovo processo viene creato, fino ad un limite che, essendo il \acr{pid} un
+numero positivo memorizzato in un intero a 16 bit, arriva ad un massimo di
+32768.  Oltre questo valore l'assegnazione riparte dal numero più basso
+disponibile a partire da un minimo di 300,\footnote{questi valori, fino al
+  kernel 2.4.x, sono definiti dalla macro \macro{PID\_MAX} in \file{threads.h}
+  e direttamente in \file{fork.c}, con il kernel 2.5.x e la nuova interfaccia
   per i thread creata da Ingo Molnar anche il meccanismo di allocazione dei
   \acr{pid} è stato modificato.} che serve a riservare i \acr{pid} più bassi
 ai processi eseguiti dal direttamente dal kernel.  Per questo motivo, come
@@ -295,23 +299,24 @@ prototipo della funzione 
 \end{functions}
 
 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
-il processo figlio continuano ad essere eseguiti normalmente all'istruzione
-seguente la \func{fork}; il processo figlio è però una copia del padre, e
-riceve una copia dei segmenti di testo, stack e dati (vedi
+il processo figlio continuano ad essere eseguiti normalmente a partire
+dall'istruzione seccessiva alla \func{fork}; il processo figlio è però una
+copia del padre, e riceve una copia dei segmenti di testo, stack e dati (vedi
 \secref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
 padre. Si tenga presente però che la memoria è copiata, non condivisa,
 pertanto padre e figlio vedono variabili diverse.
 
-Per quanto riguarda la gestione della memoria in generale il segmento di
-testo, che è identico, è condiviso e tenuto in read-only per il padre e per i
-figli. Per gli altri segmenti Linux utilizza la tecnica del \textit{copy on
-  write}\index{copy on write}; questa tecnica comporta che una pagina di
-memoria viene effettivamente copiata per il nuovo processo solo quando ci
-viene effettuata sopra una scrittura (e si ha quindi una reale differenza fra
-padre e figlio). In questo modo si rende molto più efficiente il meccanismo
-della creazione di un nuovo processo, non essendo più necessaria la copia di
-tutto lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di
-memoria che sono state modificate, e solo al momento della modifica stessa.
+Per quanto riguarda la gestione della memoria, in generale il segmento di
+testo, che è identico per i due processi, è condiviso e tenuto in read-only
+per il padre e per i figli. Per gli altri segmenti Linux utilizza la tecnica
+del \textit{copy on write}\index{copy on write}; questa tecnica comporta che
+una pagina di memoria viene effettivamente copiata per il nuovo processo solo
+quando ci viene effettuata sopra una scrittura (e si ha quindi una reale
+differenza fra padre e figlio). In questo modo si rende molto più efficiente
+il meccanismo della creazione di un nuovo processo, non essendo più necessaria
+la copia di tutto lo spazio degli indirizzi virtuali del padre, ma solo delle
+pagine di memoria che sono state modificate, e solo al momento della modifica
+stessa.
 
 La differenza che si ha nei due processi è che nel processo padre il valore di
 ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
@@ -388,16 +393,16 @@ sul numero totale di processi permessi all'utente (vedi
 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
 quella in cui all'interno di un programma si creano processi figli cui viene
 affidata l'esecuzione di una certa sezione di codice, mentre il processo padre
-ne esegue un'altra. È il caso tipico dei server (il modello
-\textit{client-server} è illustrato in \secref{sec:net_cliserv}) di rete in
-cui il padre riceve ed accetta le richieste da parte dei client, per ciascuna
-delle quali pone in esecuzione un figlio che è incaricato di fornire il
-servizio.
+ne esegue un'altra. È il caso tipico dei programmi server (il modello
+\textit{client-server} è illustrato in \secref{sec:net_cliserv}) in cui il
+padre riceve ed accetta le richieste da parte dei programmi client, per
+ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
+il servizio.
 
 La seconda modalità è quella in cui il processo vuole eseguire un altro
 programma; questo è ad esempio il caso della shell. In questo caso il processo
-crea un figlio la cui unica operazione è quella fare una \func{exec} (di cui
-parleremo in \secref{sec:proc_exec}) subito dopo la \func{fork}.
+crea un figlio la cui unica operazione è quella di fare una \func{exec} (di
+cui parleremo in \secref{sec:proc_exec}) subito dopo la \func{fork}.
 
 Alcuni sistemi operativi (il VMS ad esempio) combinano le operazioni di questa
 seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
@@ -411,16 +416,16 @@ dell'output, identificatori) prima della \func{exec}, rendendo cos
 relativamente facile intervenire sulle le modalità di esecuzione del nuovo
 programma.
 
-In \figref{fig:proc_fork_code} si è riportato il corpo del codice del
-programma di esempio \cmd{forktest}, che ci permette di illustrare molte
-caratteristiche dell'uso della funzione \func{fork}. Il programma permette di
-creare un numero di figli specificato da linea di comando, e prende anche
-alcune opzioni per indicare degli eventuali tempi di attesa in secondi
-(eseguiti tramite la funzione \func{sleep}) per il padre ed il figlio (con
-\cmd{forktest -h} si ottiene la descrizione delle opzioni); il codice
-completo, compresa la parte che gestisce le opzioni a riga di comando, è
-disponibile nel file \file{ForkTest.c}, distribuito insieme agli altri
-sorgenti degli esempi su \href{http://gapil.firenze.linux.it/gapil_source.tgz}
+In \figref{fig:proc_fork_code} è riportato il corpo del codice del programma
+di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
+dell'uso della funzione \func{fork}. Il programma crea un numero di figli
+specificato da linea di comando, e prende anche alcune opzioni per indicare
+degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
+\func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
+descrizione delle opzioni); il codice completo, compresa la parte che gestisce
+le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
+distribuito insieme agli altri sorgenti degli esempi su
+\href{http://gapil.firenze.linux.it/gapil_source.tgz}
 {\texttt{http://gapil.firenze.linux.it/gapil\_source.tgz}}.
 
 Decifrato il numero di figli da creare, il ciclo principale del programma
@@ -861,7 +866,7 @@ segnale termina il processo o chiama una funzione di gestione.
 processo figlio termina. Se un figlio è già terminato la funzione ritorna
 immediatamente.
 
-Al ritorno lo stato di terminazione del processo viene salvato nella
+Al ritorno, lo stato di terminazione del processo viene salvato nella
 variabile puntata da \var{status} e tutte le informazioni relative al
 processo (vedi \secref{sec:proc_termination}) vengono rilasciate.  Nel
 caso un processo abbia più figli il valore di ritorno permette di
@@ -1274,10 +1279,10 @@ chiamato come se si fosse eseguito il comando \cmd{interpreter [arg]
 
 Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
 basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
-processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
-\func{wait} si effettua e verifica la conclusione dei programmi. Tutte le
-altre funzioni sono ausiliarie e servono la lettura e l'impostazione dei vari
-parametri connessi ai processi.
+processo, con \func{exec} si lancia un nuovo programma, con \func{exit} e
+\func{wait} si effettua e verifica la conclusione dei processi. Tutte le
+altre funzioni sono ausiliarie e servono per la lettura e l'impostazione dei
+vari parametri connessi ai processi.
 
 
 
@@ -1384,10 +1389,10 @@ completata la procedura di autenticazione, lancia una shell per la quale
 imposta questi identificatori ai valori corrispondenti all'utente che entra
 nel sistema.
 
-Al secondo gruppo appartengono l'\textsl{userid effettivo} e l'\textsl{groupid
-  effettivo} (a cui si aggiungono gli eventuali \textsl{groupid supplementari}
-dei gruppi dei quali l'utente fa parte).  Questi sono invece gli
-identificatori usati nella verifiche dei permessi del processo e per il
+Al secondo gruppo appartengono lo \textsl{userid effettivo} ed il
+\textsl{groupid effettivo} (a cui si aggiungono gli eventuali \textsl{groupid
+  supplementari} dei gruppi dei quali l'utente fa parte).  Questi sono invece
+gli identificatori usati nella verifiche dei permessi del processo e per il
 controllo di accesso ai file (argomento affrontato in dettaglio in
 \secref{sec:file_perm_overview}).
 
@@ -1586,7 +1591,7 @@ fallimento della chiamata; l'amministratore invece pu
 qualunque.  Specificando un argomento di valore -1 l'identificatore
 corrispondente verrà lasciato inalterato.
 
-Con queste funzione si possono scambiare fra loro gli userid reale e
+Con queste funzioni si possono scambiare fra loro gli userid reale e
 effettivo, e pertanto è possibile implementare un comportamento simile a
 quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo
 scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo
@@ -1944,8 +1949,7 @@ processi che devono essere eseguiti in un determinato momento non debbano
 aspettare la conclusione di altri che non hanno questa necessità.
 
 Il concetto di priorità assoluta dice che quando due processi si contendono
-l'esecuzione, vince sempre quello con la priorità assoluta più alta, anche
-quando l'altro è in esecuzione (grazie al \textit{prehemptive scheduling}).
+l'esecuzione, vince sempre quello con la priorità assoluta più alta.
 Ovviamente questo avviene solo per i processi che sono pronti per essere
 eseguiti (cioè nello stato \textit{runnable}).  La priorità assoluta viene in
 genere indicata con un numero intero, ed un valore più alto comporta una
@@ -2004,11 +2008,11 @@ La priorit
 \var{nice}, che stabilisce la durata della \textit{time-slice}; per il
 meccanismo appena descritto infatti un valore più lungo infatti assicura una
 maggiore attribuzione di CPU.  L'origine del nome di questo parametro sta nel
-fatto che in genere esso viene generalmente usato per diminuire la priorità di
-un processo, come misura di cortesia nei confronti degli altri.
-I processi infatti vengono creati dal sistema con lo stesso valore di
-\var{nice} (nullo) e nessuno è privilegiato rispetto agli altri; il valore può
-essere modificato solo attraverso la funzione \func{nice}, il cui prototipo è:
+fatto che generalmente questo viene usato per diminuire la priorità di un
+processo, come misura di cortesia nei confronti degli altri.  I processi
+infatti vengono creati dal sistema con lo stesso valore di \var{nice} (nullo)
+e nessuno è privilegiato rispetto agli altri; il valore può essere modificato
+solo attraverso la funzione \func{nice}, il cui prototipo è:
 \begin{prototype}{unistd.h}
 {int nice(int inc)}
   Aumenta il valore di \var{nice} per il processo corrente.
@@ -2347,7 +2351,7 @@ volontariamente la CPU; questo viene fatto attraverso la funzione
     nel qual caso \var{errno} viene impostata opportunamente.}
 \end{prototype}
 
-La funzione fa si che il processo rilasci la CPU, in modo da essere rimesso in
+La funzione fa sì che il processo rilasci la CPU, in modo da essere rimesso in
 coda alla lista dei processi da eseguire, e permettere l'esecuzione di un
 altro processo; se però il processo è l'unico ad essere presente sulla coda
 l'esecuzione non sarà interrotta. In genere usano questa funzione i processi
@@ -2451,7 +2455,12 @@ problematiche di questo tipo in \capref{cha:IPC}).
 
 Un caso particolare di \textit{race condition} sono poi i cosiddetti
 \textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
-completo di un servizio, e non il fallimento di una singola operazione.
+completo di un servizio, e non il fallimento di una singola operazione. Per
+definizione un \textit{deadlock} è una situazione in cui due o più processi
+non sono più in grado di proseguire perché ciascuno aspetta il risultato di
+una operazione che dovrebbe essere eseguita dall'altro.
+
+
 L'esempio tipico di una situazione che può condurre ad un \textit{deadlock} è
 quello in cui un flag di ``occupazione'' viene rilasciato da un evento
 asincrono (come un segnale o un altro processo) fra il momento in cui lo si è
index a43f078..b2016fc 100644 (file)
@@ -247,7 +247,7 @@ componente.  Inoltre la funzione distacca il processo da ogni terminale di
 controllo (torneremo sull'argomento in \secref{sec:sess_ctrl_term}) cui fosse
 in precedenza associato.
 
-  funzione ha successo soltanto se il processo non è già leader di un
+La 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