Inizio revisione capitolo 3 e solite indicizzazioni e aggiornamento
authorSimone Piccardi <piccardi@gnulinux.it>
Thu, 5 Jan 2012 23:26:51 +0000 (23:26 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Thu, 5 Jan 2012 23:26:51 +0000 (23:26 +0000)
dei riferimenti e uniformizzazione delle terminologie negli altri
capitoli.

17 files changed:
fileadv.tex
filedir.tex
fileintro.tex
filestd.tex
fileunix.tex
gapil.tex
img/endianess.dia [deleted file]
img/endianness.dia [new file with mode: 0644]
intro.tex
ipc.tex
macro.tex
process.tex
prochand.tex
signal.tex
sockctrl.tex
socket.tex
tcpsock.tex

index 16e7a7f820ccc0b123623ee9b5fe5c839d7c4a78..29a6eacf974ad6e134850c498cf664822570b53e 100644 (file)
@@ -223,7 +223,7 @@ fondamentale da capire è che un \textit{file lock}, qualunque sia
 l'interfaccia che si usa, anche se richiesto attraverso un file descriptor,
 agisce sempre su di un file; perciò le informazioni relative agli eventuali
 \textit{file lock} sono mantenute dal kernel a livello di
-inode\index{inode},\footnote{in particolare, come accennato in
+inode\itindex{inode},\footnote{in particolare, come accennato in
   fig.~\ref{fig:file_flock_struct}, i \textit{file lock} sono mantenuti in una
   \itindex{linked~list} \textit{linked list} di strutture
   \struct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
@@ -466,7 +466,7 @@ di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si
   bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}.  La struttura è
   comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
   impostato il bit \const{FL\_POSIX} ed il campo \var{fl\_file} non viene
-  usato.} il blocco è sempre associato \index{inode} all'inode, solo che in
+  usato.} il blocco è sempre associato \itindex{inode} all'inode, solo che in
 questo caso la titolarità non viene identificata con il riferimento ad una
 voce nella \itindex{file~table} \textit{file table}, ma con il valore del
 \acr{pid} del processo.
@@ -1236,7 +1236,7 @@ cui prototipo è:
     degli insiemi.
   \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
   \item[\errcode{EINVAL}] il valore di \param{nfds} eccede il limite
-    \macro{RLIMIT\_NOFILE}.
+    \const{RLIMIT\_NOFILE}.
   \end{errlist}
   ed inoltre \errval{EFAULT} e \errval{ENOMEM}.}
 \end{prototype}
@@ -1395,7 +1395,7 @@ prototipo è:
     degli insiemi.
   \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
   \item[\errcode{EINVAL}] il valore di \param{nfds} eccede il limite
-    \macro{RLIMIT\_NOFILE}.
+    \const{RLIMIT\_NOFILE}.
   \end{errlist}
   ed inoltre \errval{EFAULT} e \errval{ENOMEM}.}
 \end{prototype}
index f467b087cd63f42cfe6a372e978df07b675bf9e2..6d02656f05f4374eae593600db1d25f8c74db156 100644 (file)
@@ -3064,7 +3064,7 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
                       sez.~\ref{sec:proc_capabilities}.\\ 
     \texttt{system} & Gli \textit{extended security attributes}: sono usati
                       dal kernel per memorizzare dati di sistema associati ai
-                      file come le \itindex{Access~Control~List} ACL (vedi
+                      file come le \itindex{Access~Control~List~(ACL)} ACL (vedi
                       sez.~\ref{sec:file_ACL}) o le \itindex{capabilities}
                       \textit{capabilities} (vedi
                       sez.~\ref{sec:proc_capabilities}).\\
@@ -3086,13 +3086,13 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
 
 
 Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
-impiega per realizzare delle estensioni (come le \itindex{Access~Control~List}
-ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli
-di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa
-a seconda sia della loro classe sia di quali, fra le estensioni che li
-utilizzano, sono poste in uso. In particolare, per ciascuna delle classi
-riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti
-casi:
+impiega per realizzare delle estensioni (come le
+\itindex{Access~Control~List~(ACL)} ACL, \index{SELinux} SELinux, ecc.) al
+tradizionale meccanismo dei controlli di accesso di Unix, l'accesso ai loro
+valori viene regolato in maniera diversa a seconda sia della loro classe sia
+di quali, fra le estensioni che li utilizzano, sono poste in uso. In
+particolare, per ciascuna delle classi riportate in
+tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi:
 \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
 \item[\texttt{security}] L'accesso agli \textit{extended security attributes}
   dipende dalle politiche di sicurezza stabilite da loro stessi tramite
@@ -3109,12 +3109,13 @@ casi:
 \item[\texttt{system}] Anche l'accesso agli \textit{extended system
     attributes} dipende dalle politiche di accesso che il kernel realizza
   anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso
-  delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai
-  processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno
-  il permesso di lettura sulla directory che contiene il file) ed in scrittura
-  al proprietario del file o ai processi dotati della \textit{capability}
-  \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale a dire una politica
-    di accesso analoga a quella impiegata per gli ordinari permessi dei file.}
+  delle \itindex{Access~Control~List~(ACL)} ACL l'accesso è consentito in
+  lettura ai processi che hanno la capacità di eseguire una ricerca sul file
+  (cioè hanno il permesso di lettura sulla directory che contiene il file) ed
+  in scrittura al proprietario del file o ai processi dotati della
+  \textit{capability} \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale
+    a dire una politica di accesso analoga a quella impiegata per gli ordinari
+    permessi dei file.}
 
 \item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
   per la lettura che per la scrittura, è consentito soltanto ai processi con
@@ -3376,7 +3377,7 @@ illustrate in precedenza per le altre funzioni relative agli attributi estesi.
 % la documentazione di sistema è nei pacchetti libacl1-dev e acl 
 % vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
 
-\itindbeg{Access~Control~List}
+\itindbeg{Access~Control~List~(ACL)}
 
 Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente,
 è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
@@ -4145,7 +4146,7 @@ vengono utilizzati tipi di dato ad hoc.\footnote{descritti nelle singole
 ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con
 \funcd{acl\_delete\_entry}.
 
-\itindend{Access~Control~List}
+\itindend{Access~Control~List~(ACL)}
 
 
 \subsection{La gestione delle quote disco}
index 1d2f9368fc94313fc10ff094b45a438f6de8c776..374a87017cb9b7303cee2ab1ac5ea6d56d5307cd 100644 (file)
@@ -172,7 +172,7 @@ dispositivo sottostante effettua le operazioni di I/O.\footnote{in sostanza i
       Un file che contiene dei dati (l'accezione normale di file).\\
       \textit{directory} & \textsl{cartella o direttorio} &
       Un file che contiene una lista di nomi associati a degli
-      \index{inode} \textit{inode} (vedi sez.~\ref{sec:file_vfs}).\\
+      \itindex{inode} \textit{inode} (vedi sez.~\ref{sec:file_vfs}).\\
       \textit{symbolic link} & \textsl{collegamento simbolico} &
       Un file che contiene un riferimento ad un altro file/directory.\\
       \textit{char device} & \textsl{dispositivo a caratteri} &
@@ -354,7 +354,7 @@ fig.~\ref{fig:file_VFS_scheme}.
 Il VFS definisce un insieme di funzioni che tutti i filesystem devono
 implementare. L'interfaccia comprende tutte le funzioni che riguardano i file;
 le operazioni sono suddivise su tre tipi di oggetti: \textit{filesystem},
-\index{inode} \textit{inode} e \textit{file}, corrispondenti a tre apposite
+\itindex{inode} \textit{inode} e \textit{file}, corrispondenti a tre apposite
 strutture definite nel kernel.
 
 Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
@@ -384,7 +384,7 @@ Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
 su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
 relative al file in uso, insieme ai puntatori alle funzioni dello specifico
 filesystem usate per l'accesso dal VFS; in particolare il descrittore
-\index{inode} dell'inode contiene i puntatori alle funzioni che possono essere
+\itindex{inode} dell'inode contiene i puntatori alle funzioni che possono essere
 usate su qualunque file (come \func{link}, \func{stat} e \func{open}), mentre
 il descrittore di file contiene i puntatori alle funzioni che vengono usate
 sui file già aperti.
@@ -401,7 +401,7 @@ viene eseguita una ricerca dentro la \textit{directory entry cache} (in breve
 efficiente il \textit{pathname} a una specifica \textit{dentry}.
 
 Una singola \textit{dentry} contiene in genere il puntatore ad un
-\index{inode} \textit{inode}; quest'ultimo è la struttura base che sta sul
+\itindex{inode} \textit{inode}; quest'ultimo è la struttura base che sta sul
 disco e che identifica un singolo oggetto del VFS sia esso un file ordinario,
 una directory, un link simbolico, una FIFO, un file di
 \index{file!di~dispositivo} dispositivo, o una qualsiasi altra cosa che possa
@@ -412,11 +412,11 @@ file, contiene anche il riferimento alle funzioni (i \textsl{metodi} del VFS)
 da usare per poterlo manipolare.
 
 Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
-vengono usate per motivi di velocità, gli \index{inode} \textit{inode} invece
+vengono usate per motivi di velocità, gli \itindex{inode} \textit{inode} invece
 stanno su disco e vengono copiati in memoria quando serve, ed ogni cambiamento
 viene copiato all'indietro sul disco (aggiornando i cosiddetti
-\textsl{metadati} del file), gli \index{inode} inode che stanno in memoria
-sono \index{inode} inode del VFS ed è ad essi che puntano le singole
+\textsl{metadati} del file), gli \itindex{inode} inode che stanno in memoria
+sono \itindex{inode} inode del VFS ed è ad essi che puntano le singole
 \textit{dentry}.
 
 La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
@@ -424,9 +424,9 @@ l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
 parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file
 per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo
 \itindex{pathname} \textit{pathname} il VFS deve creare una nuova
-\textit{dentry} e caricare \index{inode} l'inode corrispondente in memoria.
+\textit{dentry} e caricare \itindex{inode} l'inode corrispondente in memoria.
 
-Questo procedimento viene eseguito dal metodo \code{lookup()} \index{inode}
+Questo procedimento viene eseguito dal metodo \code{lookup()} \itindex{inode}
 dell'inode della directory che contiene il file; questo viene installato nelle
 relative strutture in memoria quando si effettua il montaggio lo specifico
 filesystem su cui l'inode va a vivere.
@@ -434,7 +434,7 @@ filesystem su cui l'inode va a vivere.
 Una volta che il VFS ha a disposizione la \textit{dentry} (ed il relativo
 \textit{inode}) diventa possibile accedere alle varie operazioni sul file come
 la \func{open} per aprire il file o la \func{stat} per leggere i dati
-\index{inode} dell'inode e passarli in user space.
+\itindex{inode} dell'inode e passarli in user space.
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
 una struttura di tipo \struct{file} in cui viene inserito un puntatore alla
@@ -515,7 +515,7 @@ superblock (ma sulle caratteristiche di \acr{ext2} e derivati torneremo in
 sez.~\ref{sec:file_ext2}). È comunque caratteristica comune di tutti i
 filesystem per Unix, indipendentemente da come poi viene strutturata nei
 dettagli questa informazione, prevedere una divisione fra la lista degli
-\index{inode} inode e lo spazio a disposizione per i dati e le directory.
+\itindex{inode} inode e lo spazio a disposizione per i dati e le directory.
 
 \begin{figure}[!htb]
   \centering
@@ -547,12 +547,12 @@ particolare è opportuno ricordare sempre che:
 
 \begin{enumerate}
   
-\item L'\textit{inode} \index{inode} contiene tutte le informazioni (i
+\item L'\textit{inode} \itindex{inode} contiene tutte le informazioni (i
   cosiddetti \textsl{metadati}) riguardanti il file: il tipo di file, i
   permessi di accesso, le dimensioni, i puntatori ai blocchi fisici che
   contengono i dati e così via. Le informazioni che la funzione \func{stat}
   fornisce provengono dall'\textit{inode}; dentro una directory si troverà
-  solo il nome del file e il numero \index{inode} dell'\textit{inode} ad esso
+  solo il nome del file e il numero \itindex{inode} dell'\textit{inode} ad esso
   associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come
   traduzione dell'inglese \textit{directory entry}, che non useremo anche per
   evitare confusione con le \textit{dentry} del kernel di cui si parlava in
@@ -565,18 +565,18 @@ particolare è opportuno ricordare sempre che:
   i dati del file vengono effettivamente rimossi dal disco. Per questo la
   funzione per cancellare un file si chiama \func{unlink}, ed in realtà non
   cancella affatto i dati del file, ma si limita ad eliminare la relativa voce
-  da una directory e decrementare il numero di riferimenti \index{inode}
+  da una directory e decrementare il numero di riferimenti \itindex{inode}
   nell'\textit{inode}.
   
 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
   nello stesso filesystem e non ci può essere una directory che contiene
-  riferimenti ad \index{inode} \textit{inode} relativi ad altri filesystem.
+  riferimenti ad \itindex{inode} \textit{inode} relativi ad altri filesystem.
   Questo limita l'uso del comando \cmd{ln} (che crea una nuova voce per un
   file esistente con la funzione \func{link}) al filesystem corrente.
   
 \item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto
   del file non viene spostato fisicamente, viene semplicemente creata una
-  nuova voce per \index{inode} l'\textit{inode} in questione e rimossa la
+  nuova voce per \itindex{inode} l'\textit{inode} in questione e rimossa la
   vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv}
   attraverso la funzione \func{rename}). Questa operazione non modifica
   minimamente neanche l'\textit{inode} del file dato che non si opera su
@@ -597,7 +597,7 @@ anche per le directory; per cui, se a partire dalla situazione mostrata in
 fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory \file{img}
 nella directory \file{gapil}, avremo una situazione come quella in
 fig.~\ref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri
-di \index{inode} inode.
+di \itindex{inode} inode.
 
 \begin{figure}[!htb]
   \centering 
@@ -657,7 +657,7 @@ le seguenti:
   in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
   permettono un accesso più veloce, ma sprecano più spazio disco).
 \item il filesystem implementa link simbolici veloci, in cui il nome del file
-  non è salvato su un blocco, ma tenuto all'interno \index{inode} dell'inode
+  non è salvato su un blocco, ma tenuto all'interno \itindex{inode} dell'inode
   (evitando letture multiple e spreco di spazio), non tutti i nomi però
   possono essere gestiti così per limiti di spazio (il limite è 60 caratteri).
 \item vengono supportati i file immutabili (che possono solo essere letti) per
@@ -683,7 +683,7 @@ filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
 una maggiore affidabilità e possibilità di recupero in caso di corruzione del
 superblock principale. L'utilizzo di raggruppamenti di blocchi ha inoltre
 degli effetti positivi nelle prestazioni dato che viene ridotta la distanza
-fra i dati e la tabella degli \index{inode} inode.
+fra i dati e la tabella degli \itindex{inode} inode.
 
 \begin{figure}[!htb]
   \centering
@@ -694,7 +694,7 @@ fra i dati e la tabella degli \index{inode} inode.
 
 Le directory sono implementate come una \itindex{linked~list} \textit{linked
   list} con voci di dimensione variabile. Ciascuna voce della lista contiene
-il numero di inode \index{inode}, la sua lunghezza, il nome del file e la sua
+il numero di inode \itindex{inode}, la sua lunghezza, il nome del file e la sua
 lunghezza, secondo lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo
 è possibile implementare nomi per i file anche molto lunghi (fino a 1024
 caratteri) senza sprecare spazio disco.
index ab03a980025d61fe3b9d6f746b40716bd0e625f5..9d1c6892b9318da5c6782728bf4a4a039b6481cb 100644 (file)
 \label{cha:files_std_interface}
 
 Esamineremo in questo capitolo l'interfaccia standard ANSI C per i file,
-quella che viene comunemente detta interfaccia degli \textit{stream}.  Dopo
-una breve sezione introduttiva tratteremo le funzioni base per la gestione
-dell'input/output, mentre tratteremo le caratteristiche più avanzate
-dell'interfaccia nell'ultima sezione.
+quella che viene comunemente detta interfaccia dei \textit{file stream} o
+anche più brevemente degli \textit{stream}.  Dopo una breve sezione
+introduttiva tratteremo le funzioni base per la gestione dell'input/output,
+mentre tratteremo le caratteristiche più avanzate dell'interfaccia nell'ultima
+sezione.
 
 
 \section{Introduzione}
@@ -24,7 +25,7 @@ dell'interfaccia nell'ultima sezione.
 
 Come visto in cap.~\ref{cha:file_unix_interface} le operazioni di I/O sui file
 sono gestibili a basso livello con l'interfaccia standard unix, che ricorre
-direttamente alle system call messe a disposizione dal kernel.
+direttamente alle \textit{system call} messe a disposizione dal kernel.
 
 Questa interfaccia però non provvede le funzionalità previste dallo standard
 ANSI C, che invece sono realizzate attraverso opportune funzioni di libreria,
@@ -104,20 +105,21 @@ questi tre stream sono identificabili attraverso dei nomi simbolici
 definiti nell'header \file{stdio.h} che sono:
 
 \begin{basedescript}{\desclabelwidth{3.0cm}}
-\item[\var{FILE *stdin}] Lo \textit{standard input} cioè lo stream da
-  cui il processo riceve ordinariamente i dati in ingresso. Normalmente
-  è associato dalla shell all'input del terminale e prende i caratteri
-  dalla tastiera.
-\item[\var{FILE *stdout}] Lo \textit{standard output} cioè lo stream su
-  cui il processo invia ordinariamente i dati in uscita. Normalmente è
-  associato dalla shell all'output del terminale e scrive sullo schermo.
-\item[\var{FILE *stderr}] Lo \textit{standard error} cioè lo stream su
-  cui il processo è supposto inviare i messaggi di errore. Normalmente
-  anch'esso è associato dalla shell all'output del terminale e scrive
-  sullo schermo.
+\item[\var{FILE *stdin}] Lo \textit{standard input} cioè il \textit{file
+    stream} da cui il processo riceve ordinariamente i dati in
+  ingresso. Normalmente è associato dalla shell all'input del terminale e
+  prende i caratteri dalla tastiera.
+\item[\var{FILE *stdout}] Lo \textit{standard output} cioè il \textit{file
+    stream} su cui il processo invia ordinariamente i dati in
+  uscita. Normalmente è associato dalla shell all'output del terminale e
+  scrive sullo schermo.
+\item[\var{FILE *stderr}] Lo \textit{standard error} cioè il \textit{file
+    stream} su cui il processo è supposto inviare i messaggi di
+  errore. Normalmente anch'esso è associato dalla shell all'output del
+  terminale e scrive sullo schermo.
 \end{basedescript}
 
-Nelle \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono effettivamente
+Nella \acr{glibc} \var{stdin}, \var{stdout} e \var{stderr} sono effettivamente
 tre variabili di tipo \type{FILE}\texttt{ *} che possono essere usate come
 tutte le altre, ad esempio si può effettuare una redirezione dell'output di un
 programma con il semplice codice: \includecodesnip{listati/redir_stdout.c} ma
index 674d023449bfebfe54bb405c3d815097c1142f45..bdef736c26e9d06d133261dd451478b71bb397d6 100644 (file)
@@ -40,7 +40,7 @@ tutte le implementazione di un sistema unix-like.
 Per poter accedere al contenuto di un file occorre creare un canale di
 comunicazione con il kernel che renda possibile operare su di esso (si ricordi
 quanto visto in sez.~\ref{sec:file_vfs_work}). Questo si fa aprendo il file
-con la funzione \func{open} che provvederà a localizzare \index{inode} l'inode
+con la funzione \func{open} che provvederà a localizzare \itindex{inode} l'inode
 del file e inizializzare i puntatori che rendono disponibili le funzioni che
 il VFS mette a disposizione (riportate in
 tab.~\ref{tab:file_file_operations}). Una volta terminate le operazioni, il
@@ -83,9 +83,9 @@ informazioni relative al file, fra cui:
 \item lo stato del file (nel campo \var{f\_flags}).
 \item il valore della posizione corrente (l'\textit{offset}) nel file (nel
   campo \var{f\_pos}).
-\item un puntatore \index{inode} all'inode\footnote{nel kernel 2.4.x si è in
+\item un puntatore \itindex{inode} all'inode\footnote{nel kernel 2.4.x si è in
     realtà passati ad un puntatore ad una struttura \struct{dentry} che punta
-    a sua volta \index{inode} all'inode passando per la nuova struttura del
+    a sua volta \itindex{inode} all'inode passando per la nuova struttura del
     VFS.}  del file.
 %\item un puntatore alla tabella delle funzioni \footnote{la struttura
 %    \var{f\_op} descritta in sez.~\ref{sec:file_vfs_work}} che si possono usare
@@ -142,7 +142,7 @@ tab.~\ref{tab:file_std_files}.
   \footnotesize
   \begin{tabular}[c]{|l|l|}
     \hline
-    \textbf{Costante} & \textbf{Significato} \\
+    \textbf{File} & \textbf{Significato} \\
     \hline
     \hline
     \const{STDIN\_FILENO}  & \textit{file descriptor} dello \textit{standard
@@ -162,7 +162,7 @@ In fig.~\ref{fig:file_proc_file} si è rappresentata una situazione diversa,
 facendo riferimento ad un programma in cui lo \textit{standard input} è
 associato ad un file mentre lo \textit{standard output} e lo \textit{standard
   error} sono entrambi associati ad un altro file (e quindi utilizzano lo
-stesso \index{inode} inode).
+stesso \itindex{inode} inode).
 
 Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
 numero di file aperti era anche soggetto ad un limite massimo dato dalle
@@ -844,7 +844,7 @@ situazione come quella illustrata in fig.~\ref{fig:file_mult_acc}: ciascun
 processo avrà una sua voce nella \textit{file table} referenziata da un
 diverso file descriptor nella sua \struct{file\_struct}. Entrambe le voci
 nella \itindex{file~table} \textit{file table} faranno però riferimento allo
-stesso \index{inode} inode su disco.
+stesso \itindex{inode} inode su disco.
 
 Questo significa che ciascun processo avrà la sua posizione corrente sul file,
 la sua modalità di accesso e versioni proprie di tutte le proprietà che
@@ -856,17 +856,17 @@ che:
 \item ciascun processo può scrivere indipendentemente; dopo ciascuna
   \func{write} la posizione corrente sarà cambiata solo nel processo. Se la
   scrittura eccede la dimensione corrente del file questo verrà esteso
-  automaticamente con l'aggiornamento del campo \var{i\_size} \index{inode}
+  automaticamente con l'aggiornamento del campo \var{i\_size} \itindex{inode}
   nell'inode.
 \item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte
   le volte che viene effettuata una scrittura la posizione corrente viene
-  prima impostata alla dimensione corrente del file letta \index{inode}
+  prima impostata alla dimensione corrente del file letta \itindex{inode}
   dall'inode. Dopo la scrittura il file viene automaticamente esteso.
 \item l'effetto di \func{lseek} è solo quello di cambiare il campo
   \var{f\_pos} nella struttura \struct{file} della \itindex{file~table}
   \textit{file table}, non c'è nessuna operazione sul file su disco. Quando la
   si usa per porsi alla fine del file la posizione viene impostata leggendo la
-  dimensione corrente \index{inode} dall'inode.
+  dimensione corrente \itindex{inode} dall'inode.
 \end{itemize}
 
 \begin{figure}[!htb]
@@ -1019,7 +1019,7 @@ Entrambe le funzioni forzano la sincronizzazione col disco di tutti i dati del
 file specificato, ed attendono fino alla conclusione delle operazioni;
 \func{fsync} forza anche la sincronizzazione dei meta-dati del file (che
 riguardano sia le modifiche alle tabelle di allocazione dei settori, che gli
-altri dati contenuti \index{inode} nell'inode che si leggono con \func{fstat},
+altri dati contenuti \itindex{inode} nell'inode che si leggono con \func{fstat},
 come i tempi del file).
 
 Si tenga presente che questo non comporta la sincronizzazione della
index cb0bb1d1cf33e2cd6e85d7a4c9ab89aa737a1692..60af0113aaf04274165c890358b927546a897f91 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -47,6 +47,18 @@ inner=2.5cm,outer=1.8cm,bottom=3.3cm,top=2.3cm]{geometry}
 
 % fancy verbatim
 \usepackage{fancyvrb}
+\DefineVerbatimEnvironment{Example}{Verbatim}
+{xleftmargin=1cm,xrightmargin=1cm}
+
+\DefineVerbatimEnvironment{FileExample}{Verbatim}
+{frame=lines,framerule=0.5mm,framesep=2mm,xleftmargin=1cm,xrightmargin=1cm,fontsize=\footnotesize}
+
+\DefineVerbatimEnvironment{Terminal}{Verbatim}
+{xleftmargin=\parindent,xrightmargin=\parindent,fontfamily=courier,fontsize=\footnotesize}
+
+\DefineVerbatimEnvironment{Command}{Verbatim}
+{xleftmargin=\parindent,xrightmargin=\parindent,fontseries=b,
+fontfamily=courier,fontsize=\footnotesize}
 
 \usepackage[bookmarks=true,plainpages=false,pdfpagelabels,
 hyperfootnotes=false]{hyperref}
diff --git a/img/endianess.dia b/img/endianess.dia
deleted file mode 100644 (file)
index ca45c9e..0000000
Binary files a/img/endianess.dia and /dev/null differ
diff --git a/img/endianness.dia b/img/endianness.dia
new file mode 100644 (file)
index 0000000..ca45c9e
Binary files /dev/null and b/img/endianness.dia differ
index 289c5bf7df8707d266f6e5cd0c2da0eb1d306f4d..6be78445689f7d202f0df72855676ff6449e54e2 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -452,7 +452,7 @@ infinita serie di problemi di portabilità.
     \type{dev\_t}   & Numero di dispositivo (vedi sez.~\ref{sec:file_mknod}).\\
     \type{gid\_t}   & Identificatore di un gruppo (vedi
                       sez.~\ref{sec:proc_access_id}).\\
-    \type{ino\_t}   & Numero di \index{inode} \textit{inode}.\\
+    \type{ino\_t}   & Numero di \itindex{inode} \textit{inode}.\\
     \type{key\_t}   & Chiave per il System V IPC (vedi
                       sez.~\ref{sec:ipc_sysv_generic}).\\
     \type{loff\_t}  & Posizione corrente in un file.\\
diff --git a/ipc.tex b/ipc.tex
index c7af63283aa8f317c9b47ccd05779bfefaf91b3a..742846d1d9729b2b5f0bdc327f539f21af28c131 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -418,13 +418,13 @@ o nella relazione padre/figlio; per superare questo problema lo standard
 POSIX.1 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
 caratteristiche delle pipe, ma che invece di essere strutture interne del
 kernel, visibili solo attraverso un file descriptor, sono accessibili
-attraverso un \index{inode} inode che risiede sul filesystem, così che i
+attraverso un \itindex{inode} inode che risiede sul filesystem, così che i
 processi le possono usare senza dovere per forza essere in una relazione di
 \textsl{parentela}.
 
 Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
 attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
-\index{inode} l'inode allocato sul filesystem serve infatti solo a fornire un
+\itindex{inode} l'inode allocato sul filesystem serve infatti solo a fornire un
 punto di riferimento per i processi, che permetta loro di accedere alla stessa
 fifo; il comportamento delle funzioni di lettura e scrittura è identico a
 quello illustrato per le pipe in sez.~\ref{sec:ipc_pipes}.
@@ -892,7 +892,7 @@ gli 8 bit meno significativi.\footnote{nelle libc4 e libc5, come avviene in
 
 Il problema è che anche così non c'è la sicurezza che il valore della chiave
 sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
-con i 16 bit meno significativi \index{inode} dell'inode del file
+con i 16 bit meno significativi \itindex{inode} dell'inode del file
 \param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano
 i possibili errori), e gli 8 bit meno significativi del numero del dispositivo
 su cui è il file.  Diventa perciò relativamente facile ottenere delle
@@ -1686,7 +1686,7 @@ viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura
 della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
 il problema delle fifo che restavano nel filesystem). In questo caso però il
 problemi sono maggiori, sia perché è molto più facile esaurire la memoria
-dedicata ad una coda di messaggi che gli \index{inode} inode di un filesystem,
+dedicata ad una coda di messaggi che gli \itindex{inode} inode di un filesystem,
 sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
 eseguito in un momento successivo potrebbe ricevere un messaggio non
 indirizzato a lui.
@@ -3868,7 +3868,7 @@ segmento di memoria condiviso con le stesse modalità di
 il flag \const{FD\_CLOEXEC}.  Chiamate effettuate da diversi processi usando
 lo stesso nome, restituiranno file descriptor associati allo stesso segmento
 (così come, nel caso di file di dati, essi sono associati allo stesso
-\index{inode} inode).  In questo modo è possibile effettuare una chiamata ad
+\itindex{inode} inode).  In questo modo è possibile effettuare una chiamata ad
 \func{mmap} sul file descriptor restituito da \func{shm\_open} ed i processi
 vedranno lo stesso segmento di memoria condivisa.
 
index 4adb7f3011588c8362b11fdefc33eeeb84066e56..797bc176e4a54954870e2cf86a050336639bace4 100644 (file)
--- a/macro.tex
+++ b/macro.tex
 \newlength{\funcboxwidth}
 \setlength{\funcboxwidth}{0.85\textwidth}
 
+
 %
 % Nuove macro per diversa formattazione delle definizioni delle funzioni
 %
index 8ea65d75e52f5beab2157b991aa9dc9b14f639bd..c7c6756c22454091f1059b18659e8e1273ce2fac 100644 (file)
@@ -331,7 +331,7 @@ se si è definita la macro \macro{\_GNU\_SOURCE}, è:
   \fdesc{Esegue la \textit{system call} indicata da \param{number}.}
 }
 {La funzione ritorna un intero dipendente dalla \textit{system call} invocata,
-in generale $0$ indica il successo e un valore negativo un errore.}
+ in generale $0$ indica il successo ed un valore negativo un errore.}
 \end{funcproto}
 
 La funzione richiede come primo argomento il numero della \textit{system call}
@@ -378,11 +378,11 @@ standard ANSI C, è quella che deve essere invocata per una terminazione
 La funzione è pensata per eseguire una conclusione pulita di un programma che
 usi la libreria standard del C; essa esegue tutte le funzioni che sono state
 registrate con \func{atexit} e \func{on\_exit} (vedi
-sez.~\ref{sec:proc_atexit}), chiude tutti gli stream effettuando il
-salvataggio dei dati sospesi (chiamando \func{fclose}, vedi
-sez.~\ref{sec:file_fopen}), infine passa il controllo al kernel chiamando la
-\textit{system call} \func{\_exit} (che vedremo a breve) che completa la
-terminazione del processo.
+sez.~\ref{sec:proc_atexit}), chiude tutti i \textit{file stream} (vedi
+sez.~\ref{sec:file_stream}) effettuando il salvataggio dei dati sospesi
+(chiamando \func{fclose}, vedi sez.~\ref{sec:file_fopen}), infine passa il
+controllo al kernel chiamando la \textit{system call} \func{\_exit} (che
+vedremo a breve) che completa la terminazione del processo.
 
 \itindbeg{exit~status}
 
@@ -395,11 +395,11 @@ terminato.
 
 Anche se l'argomento \param{status} (ed il valore di ritorno di \func{main})
 sono numeri interi di tipo \ctyp{int}, si deve tener presente che il valore
-dello stato di uscita viene comunque troncato ad 8 bit, per cui deve essere
-sempre compreso fra 0 e 255. Si tenga presente che se si raggiunge la fine
-della funzione \func{main} senza ritornare esplicitamente si ha un valore di
-uscita indefinito, è pertanto consigliabile di concludere sempre in maniera
-esplicita detta funzione.
+dello stato di uscita viene comunque troncato ad 8 bit,
+per cui deve essere sempre compreso fra 0 e 255. Si tenga presente che se si
+raggiunge la fine della funzione \func{main} senza ritornare esplicitamente si
+ha un valore di uscita indefinito, è pertanto consigliabile di concludere
+sempre in maniera esplicita detta funzione.
 
 Non esiste un valore significato intrinseco della stato di uscita, ma una
 convenzione in uso pressoché universale è quella di restituire 0 in caso di
@@ -442,11 +442,12 @@ concludendo immediatamente il processo, il suo prototipo è:
 La funzione termina immediatamente il processo e le eventuali funzioni
 registrate con \func{atexit} e \func{on\_exit} non vengono eseguite. La
 funzione chiude tutti i file descriptor appartenenti al processo, cosa che
-però non comporta il salvataggio dei dati eventualmente presenti nei buffer
-degli stream, (torneremo sulle due interfacce dei file a partire da
-cap.~\ref{cha:file_intro}). Infine fa sì che ogni figlio del processo sia
-adottato da \cmd{init} (vedi cap.~\ref{cha:process_handling}), manda un
-segnale \signal{SIGCHLD} al processo padre (vedi
+però non comporta il salvataggio dei dati eventualmente presenti nei buffer di
+\textit{file stream}, (torneremo sulle due interfacce dei file in
+cap.~\ref{cha:files_std_interface} e
+cap.~\ref{cha:file_unix_interface})). Infine fa sì che ogni figlio del
+processo sia adottato da \cmd{init} (vedi sez.~\ref{sec:proc_termination}),
+manda un segnale \signal{SIGCHLD} al processo padre (vedi
 sez.~\ref{sec:sig_job_control}) e ritorna lo stato di uscita specificato
 in \param{status} che può essere raccolto usando la funzione \func{wait} (vedi
 sez.~\ref{sec:proc_wait}).
@@ -483,8 +484,8 @@ ritorno di \func{main}. La prima funzione che si può utilizzare a tal fine è
 
 \begin{funcproto}{ \fhead{stdlib.h} \fdecl{void (*function)(void)}
     \fdesc{Registra la funzione \param{function} per la chiamata all'uscita
-      dal programma.}  } {La funzione restituisce $0$ in caso di successo e
-    $-1$ in caso di fallimento, \var{errno} non viene modificata.}
+      dal programma.}  } {La funzione ritorna $0$ in caso di successo e
+    $-1$ per un errore, \var{errno} non viene modificata.}
 \end{funcproto}
 
 La funzione richiede come argomento \param{function} l'indirizzo di una
@@ -501,8 +502,10 @@ definita su altri sistemi,\footnote{non essendo prevista dallo standard POSIX
 \fhead{stdlib.h} 
 \fdecl{void (*function)(int , void *), void *arg)}
 \fdesc{Registra la funzione \param{function} per la chiamata all'uscita dal
-  programma.} }{La funzione restituisce $0$ in caso di successo e $-1$ in caso
-di fallimento, \var{errno} non viene modificata.}
+  programma.} 
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, \var{errno}
+  non viene modificata.} 
 \end{funcproto}
 
 In questo caso la funzione da chiamare all'uscita prende i due argomenti
@@ -521,11 +524,11 @@ di esecuzione sarà riferito alla registrazione in quanto tale,
 indipendentemente dalla funzione usata per farla.
 
 Una volta completata l'esecuzione di tutte le funzioni registrate verranno
-chiusi tutti gli stream aperti ed infine verrà chiamata \func{\_exit} per la
-terminazione del programma. Questa è la sequenza ordinaria, eseguita a meno
-che una delle funzioni registrate non esegua al suo interno \func{\_exit}, nel
-qual caso la terminazione del programma sarà immediata ed anche le successive
-funzioni registrate non saranno invocate.
+chiusi tutti i \textit{file stream} aperti ed infine verrà chiamata
+\func{\_exit} per la terminazione del programma. Questa è la sequenza
+ordinaria, eseguita a meno che una delle funzioni registrate non esegua al suo
+interno \func{\_exit}, nel qual caso la terminazione del programma sarà
+immediata ed anche le successive funzioni registrate non saranno invocate.
 
 Se invece all'interno di una delle funzioni registrate si chiama un'altra
 volta \func{exit} lo standard POSIX.1-2001 prescrive un comportamento
@@ -963,8 +966,8 @@ suo prototipo è:
 \fhead{stdlib.h} 
 \fdecl{void *realloc(void *ptr, size\_t size)}
 \fdesc{Cambia la dimensione di un'area di memoria precedentemente allocata.}
-}  {La funzione restituisce il puntatore alla zona di memoria allocata in caso
-  di successo e \val{NULL} in caso di fallimento, nel qual caso \var{errno}
+}  {La funzione ritorna il puntatore alla zona di memoria allocata in caso
+  di successo e \val{NULL} per un errore, nel qual caso \var{errno}
   assumerà il valore \errval{ENOMEM}.}
 \end{funcproto}
 
@@ -1089,8 +1092,8 @@ sintassi è identica a quella di \func{malloc}; il suo prototipo è:
 \fdecl{void *alloca(size\_t size)}
 \fdesc{Alloca un'area di memoria nello \textit{stack}.} 
 }
-{La funzione restituisce il puntatore alla zona di memoria allocata, in caso
-  di fallimento il comportamento è indefinito.}
+{La funzione ritorna il puntatore alla zona di memoria allocata, in caso
+  di errore il comportamento è indefinito.}
 \end{funcproto}
 
 La funzione alloca la quantità di memoria (non inizializzata) richiesta
@@ -1151,7 +1154,7 @@ prototipo è:
 \fdecl{int brk(void *addr)}
 \fdesc{Sposta la fine del segmento dati del processo.} 
 }
-{La funzione restituisce 0 in caso di successo e $-1$ in caso di fallimento,
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
   nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
 \end{funcproto}
 
@@ -1181,8 +1184,8 @@ Una seconda funzione per la manipolazione diretta delle dimensioni
 \fdecl{void *sbrk(intptr\_t increment)}
 \fdesc{Incrementa la dimensione del segmento dati del processo.} 
 }
-{La funzione restituisce il puntatore all'inizio della nuova zona di memoria
-  allocata in caso di successo e \val{NULL} in caso di fallimento, nel qual
+{La funzione ritorna il puntatore all'inizio della nuova zona di memoria
+  allocata in caso di successo e \val{NULL} per un errore, nel qual
   caso \var{errno} assumerà il valore \errval{ENOMEM}.}
 \end{funcproto}
 
@@ -1191,7 +1194,7 @@ programma del valore indicato dall'argomento \param{increment}, restituendo il
 nuovo indirizzo finale dello stesso.  L'argomento è definito come di tipo
 \type{intptr\_t}, ma a seconda della versione delle librerie e del sistema può
 essere indicato con una serie di tipi equivalenti come \type{ptrdiff\_t},
-\type{ssize\_t}, \ctyp{int}. Se invocata con un valore nullo la funzone
+\type{ssize\_t}, \ctyp{int}. Se invocata con un valore nullo la funzione
 permette di ottenere l'attuale posizione della fine del \index{segmento!dati}
 segmento dati.
 
@@ -1249,27 +1252,6 @@ però non è standardizzata da POSIX e pertanto non è disponibile su tutte le
 versioni di kernel unix-like;\footnote{nel caso di Linux devono essere
   comunque definite le macro \macro{\_BSD\_SOURCE} e \macro{\_SVID\_SOURCE}.}
 il suo prototipo è:
-% \begin{functions}
-%   \headdecl{unistd.h} 
-%   \headdecl{sys/mman.h} 
-
-%   \funcdecl{int mincore(void *addr, size\_t length, unsigned char *vec)}
-%   Ritorna lo stato delle pagine di memoria occupate da un processo.
-  
-%   \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
-%     errore, nel qual caso \var{errno} assumerà uno dei valori:
-%   \begin{errlist}
-%   \item[\errcode{ENOMEM}] o \param{addr} + \param{length} eccede la dimensione
-%     della memoria usata dal processo o l'intervallo di indirizzi specificato
-%     non è mappato.
-%   \item[\errcode{EINVAL}] \param{addr} non è un multiplo delle dimensioni di
-%     una pagina.
-%   \item[\errcode{EFAULT}] \param{vec} punta ad un indirizzo non valido.
-%   \item[\errcode{EAGAIN}] il kernel è temporaneamente non in grado di fornire
-%     una risposta.
-%   \end{errlist}
-% }
-% \end{functions}
 
 \begin{funcproto}{
 \fhead{unistd.h}
@@ -1277,7 +1259,7 @@ il suo prototipo è:
 \fdecl{int mincore(void *addr, size\_t length, unsigned char *vec)}
 \fdesc{Ritorna lo stato delle pagine di memoria occupate da un processo.}
 }
-{La funzione ritorna 0 in caso di successo e $-1$ in caso di errore, nel qual
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
 caso \var{errno} assumerà uno dei valori:
 \begin{errlist}
    \item[\errcode{ENOMEM}] o \param{addr} + \param{length} eccede la dimensione
@@ -1613,7 +1595,7 @@ suo prototipo è:
 \fdecl{int mcheck(void (*abortfn) (enum mcheck\_status status))}
 \fdesc{Attiva i controlli di consistenza delle allocazioni di memoria.}   
 }
-{La funzione restituisce $0$ in caso di successo e $-1$ in caso di fallimento;
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errorre;
   \var{errno} non viene impostata.} 
 \end{funcproto}
 
@@ -1645,20 +1627,20 @@ tipologia di errore riscontrata.
     \textbf{Valore} & \textbf{Significato} \\
     \hline
     \hline
-    \macro{MCHECK\_OK}      & riportato a \func{mprobe} se nessuna
+    \const{MCHECK\_OK}      & riportato a \func{mprobe} se nessuna
                               inconsistenza è presente.\\
-    \macro{MCHECK\_DISABLED}& riportato a \func{mprobe} se si è chiamata
+    \const{MCHECK\_DISABLED}& riportato a \func{mprobe} se si è chiamata
                               \func{mcheck} dopo aver già usato
                               \func{malloc}.\\
-    \macro{MCHECK\_HEAD}    & i dati immediatamente precedenti il buffer sono
+    \const{MCHECK\_HEAD}    & i dati immediatamente precedenti il buffer sono
                               stati modificati, avviene in genere quando si
                               decrementa eccessivamente il valore di un
                               puntatore scrivendo poi prima dell'inizio del
                               buffer.\\
-    \macro{MCHECK\_TAIL}    & i dati immediatamente seguenti il buffer sono
+    \const{MCHECK\_TAIL}    & i dati immediatamente seguenti il buffer sono
                               stati modificati, succede quando si va scrivere
                               oltre la dimensione corretta del buffer.\\
-    \macro{MCHECK\_FREE}    & il buffer è già stato disallocato.\\
+    \const{MCHECK\_FREE}    & il buffer è già stato disallocato.\\
     \hline
   \end{tabular}
   \caption{Valori dello stato dell'allocazione di memoria ottenibili dalla
@@ -1676,8 +1658,8 @@ prototipo è:
 \fdecl{enum mcheck\_status mprobe(ptr)}
 \fdesc{Esegue un controllo di consistenza delle allocazioni.}   
 }
-{La funzione restituisce un codice fra quelli riportati in
-   tab.\ref{tab:mcheck_status_value} e non ha errori.} 
+{La funzione ritorna un codice fra quelli riportati in
+   tab.~\ref{tab:mcheck_status_value} e non ha errori.} 
 \end{funcproto}
 
 La funzione richiede che si passi come argomento un puntatore ad un blocco di
@@ -1883,6 +1865,7 @@ vettore \param{argv}.
 \subsection{Le variabili di ambiente}
 \label{sec:proc_environ}
 
+\index{variabili!di~ambiente|(}
 Oltre agli argomenti passati a linea di comando esiste un'altra modalità che
 permette di trasferire ad un processo delle informazioni in modo da
 modificarne il comportamento.  Ogni processo infatti riceve dal sistema, oltre
@@ -1944,7 +1927,7 @@ fig.~\ref{fig:proc_envirno_list}.
 \end{figure}
 
 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
-\textsl{\texttt{nome=valore}} ed in questa forma che le funzioni di gestione
+\textsl{\texttt{NOME=valore}} ed in questa forma che le funzioni di gestione
 che vedremo a breve se le aspettano, se pertanto si dovesse costruire
 manualmente un ambiente si abbia cura di rispettare questa convenzione.
 Inoltre alcune variabili, come quelle elencate in
@@ -2027,7 +2010,7 @@ il suo prototipo è:
 \fdesc{Cerca una variabile di ambiente del processo.} 
 }
 {La funzione ritorna il puntatore alla stringa contenente il valore della
-  variabile di ambiente in caso di successo e \val{NULL} in caso di errore.} 
+  variabile di ambiente in caso di successo e \val{NULL} per un errore.} 
 \end{funcproto}
 
 La funzione effettua una ricerca nell'ambiente del processo cercando una
@@ -2080,7 +2063,7 @@ variabile di ambiente; il suo prototipo è:
 \fdecl{int putenv(char *string)}
 \fdesc{Inserisce, modifica o rimuove una variabile d'ambiente.} 
 }
-{La funzione ritorna 0 in caso di successo e $-1$ in caso di errore, che può
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, che può
   essere solo \errval{ENOMEM}.}
 \end{funcproto}
 
@@ -2090,7 +2073,7 @@ specificata (nel caso \texttt{NOME}) non esiste la stringa sarà aggiunta
 all'ambiente, se invece esiste il suo valore sarà impostato a quello
 specificato dal contenuto di \param{string} (nel caso \texttt{valore}).  Se
 invece si passa come argomento solo il nome di una variabile di ambiente
-(cioè \param{string} è nella forma ``\texttt{NAME}'' e non contiene il
+(cioè \param{string} è nella forma ``\texttt{NOME}'' e non contiene il
 carattere ``\texttt{=}'') allora questa, se presente nell'ambiente, verrà
 cancellata.
 
@@ -2106,7 +2089,9 @@ sostituendo il relativo puntatore;\footnote{il comportamento è lo stesso delle
   dal prototipo.}  pertanto ogni cambiamento alla stringa in questione si
 riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
 questa funzione una \index{variabili!automatiche} variabile automatica (per
-evitare i problemi esposti in sez.~\ref{sec:proc_var_passing}).
+evitare i problemi esposti in sez.~\ref{sec:proc_var_passing}). Benché non sia
+richiesto dallo standard nelle versioni della \acr{glibc} a partire dalla 2.1
+la funzione è rientrante (vedi sez.~\ref{sec:proc_reentrant}).
 
 Infine quando una chiamata a \func{putenv} comporta la necessità di creare una
 nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
@@ -2114,10 +2099,10 @@ ma la versione corrente sarà deallocata solo se anch'essa è risultante da
 un'allocazione fatta in precedenza da un'altra \func{putenv}. Questo avviene
 perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
 ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
-sopra dello \itindex{stack} stack, (vedi fig.~\ref{fig:proc_mem_layout}) e non
-nello \itindex{heap} \textit{heap} e quindi non può essere deallocato.
-Inoltre la memoria associata alle variabili di ambiente eliminate non viene
-liberata.
+sopra dello \itindex{stack} \textit{stack}, (vedi
+fig.~\ref{fig:proc_mem_layout}) e non nello \itindex{heap} \textit{heap} e
+quindi non può essere deallocato.  Inoltre la memoria associata alle variabili
+di ambiente eliminate non viene liberata.
 
 Come alternativa a \func{putenv} si può usare la funzione \funcd{setenv} che
 però consente solo di aggiungere o modificare una variabile di ambiente; il
@@ -2128,7 +2113,7 @@ suo prototipo è:
 \fdecl{int setenv(const char *name, const char *value, int overwrite)}
 \fdesc{Inserisce o modifica una variabile di ambiente.} 
 }
-{La funzione ritorna 0 in caso di successo e $-1$ per un errore,
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
   nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{ENOMEM}] non c'è memoria sufficiente per aggiungere una nuova
@@ -2155,12 +2140,12 @@ esplicitamente con \funcd{unsetenv}, il cui prototipo è:
 \fdecl{int unsetenv(const char *name)}
 \fdesc{Rimuove una variabile di ambiente.} 
 }
-{La funzione ritorna 0 in caso di successo e $-1$ per un errore,
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
   nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza
   nulla o che contiene il carattere ``\texttt{=}''.
-  \end{errlist}}  
+\end{errlist}}
 \end{funcproto}
 
 La funzione richiede soltanto il nome della variabile di ambiente
@@ -2169,15 +2154,30 @@ comunque con un valore di successo.\footnote{questo con le versioni della
   \acr{glibc} successive la 2.2.2, per le precedenti \func{unsetenv} era
   definita come \texttt{void} e non restituiva nessuna informazione.}
 
-L'ultima funzione per la gestione dell'ambiente è \funcd{clearenv}, che viene
-usata per cancellare completamente tutto l'ambiente; il suo prototipo è:
+L'ultima funzione per la gestione dell'ambiente è
+\funcd{clearenv},\footnote{che come accennato è l'unica non presente nello
+  standard POSIX.1-2000, ed è disponibili solo per versioni della \acr{glibc}
+  a partire dalla 2.0; per poterla utilizzare occorre aver definito le macro
+  \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE}.} che viene usata per
+cancellare completamente tutto l'ambiente; il suo prototipo è:
 
+\begin{funcproto}{ 
+\fhead{stdlib.h}
+\fdecl{int clearenv(void)}
+\fdesc{Cancella tutto l'ambiente.} 
+}
+{La funzione ritorna $0$ in caso di successo e un valore diverso da zero per
+  un errore.}
+\end{funcproto}
 
 In genere si usa questa funzione in maniera precauzionale per evitare i
 problemi di sicurezza connessi nel trasmettere ai programmi che si invocano un
-ambiente che può contenere dei dati non controllati. In tal caso si provvede
-alla cancellazione di tutto l'ambiente per costruirne una versione
-``\textsl{sicura}'' da zero.
+ambiente che può contenere dei dati non controllati, le cui variabili possono
+causare effetti indesiderati. Con l'uso della funzione si provvede alla
+cancellazione di tutto l'ambiente originale in modo da poterne costruirne una
+versione ``\textsl{sicura}'' da zero.
+
+\index{variabili!di~ambiente|)}
 
 
 \subsection{La localizzazione}
@@ -2340,16 +2340,16 @@ inoltre che l'ultimo degli argomenti fissi sia di tipo
   \ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
   a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
 \ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
-alcuni compilatori è di non dichiarare l'ultimo argomento fisso come
-\direct{register}.\footnote{la direttiva \direct{register} del compilatore
-  chiede che la variabile dichiarata tale sia mantenuta, nei limiti del
-  possibile, all'interno di un registro del processore; questa direttiva è
-  originaria dell'epoca dai primi compilatori, quando stava al programmatore
-  scrivere codice ottimizzato, riservando esplicitamente alle variabili più
-  usate l'uso dei registri del processore, oggi questa direttiva è in disuso
-  dato che tutti i compilatori sono normalmente in grado di valutare con
-  maggior efficacia degli stessi programmatori quando sia il caso di eseguire
-  questa ottimizzazione.}
+alcuni compilatori è di non dichiarare l'ultimo argomento fisso come variabile
+di tipo \direct{register}.\footnote{la direttiva \direct{register} del
+  compilatore chiede che la variabile dichiarata tale sia mantenuta, nei
+  limiti del possibile, all'interno di un registro del processore; questa
+  direttiva è originaria dell'epoca dai primi compilatori, quando stava al
+  programmatore scrivere codice ottimizzato, riservando esplicitamente alle
+  variabili più usate l'uso dei registri del processore, oggi questa direttiva
+  è in disuso pressoché completo dato che tutti i compilatori sono normalmente
+  in grado di valutare con maggior efficacia degli stessi programmatori quando
+  sia il caso di eseguire questa ottimizzazione.}
 
 Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
 quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
@@ -2398,12 +2398,12 @@ del valore da essa restituito. Si ricordi che il tipo deve essere
 \textit{self-promoting}.
 
 In generale è perfettamente legittimo richiedere meno argomenti di quelli che
-potrebbero essere stati effettivamente forniti, e nella esecuzione delle
+potrebbero essere stati effettivamente forniti, per cui nella esecuzione delle
 \macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
-saranno ignorati. Se invece si richiedono più argomenti di quelli forniti si
-otterranno dei valori indefiniti, si avranno risultati indefiniti anche quando
-si chiama \macro{va\_arg} specificando un tipo che non corrisponde a quello
-usato per il corrispondente argomento.
+saranno ignorati. Se invece si richiedono più argomenti di quelli
+effettivamente forniti si otterranno dei valori indefiniti. Si avranno
+risultati indefiniti anche quando si chiama \macro{va\_arg} specificando un
+tipo che non corrisponde a quello usato per il corrispondente argomento.
 
 Infine una volta completata l'estrazione occorre indicare che si sono concluse
 le operazioni con la macro \macro{va\_end}, la cui definizione è:
@@ -2464,12 +2464,14 @@ che viene chiamato un \index{tipo!opaco} \textsl{tipo opaco}. Si chiamano così
 quei tipi di dati, in genere usati da una libreria, la cui struttura interna
 non deve essere vista dal programma chiamante (da cui deriva il nome opaco)
 che li devono utilizzare solo attraverso dalle opportune funzioni di
-gestione. Per questo motivo non può essere assegnata direttamente ad un'altra
-variabile dello stesso tipo. Per risolvere questo problema lo standard ISO
-C99\footnote{alcuni sistemi che non hanno questa macro provvedono al suo posto
-  \macro{\_\_va\_copy} che era il nome proposto in una bozza dello standard.}
-ha previsto una macro ulteriore che permette di eseguire la copia di una lista
-degli argomenti:
+gestione. 
+
+Per questo motivo una variabile di tipo \type{va\_list} non può essere
+assegnata direttamente ad un'altra variabile dello stesso tipo, ma lo standard
+ISO C99\footnote{alcuni sistemi che non hanno questa macro provvedono al suo
+  posto \macro{\_\_va\_copy} che era il nome proposto in una bozza dello
+  standard.}  ha previsto una macro ulteriore che permette di eseguire la
+copia di una lista degli argomenti:
 
 {\centering
 \begin{funcbox}{ 
@@ -2497,20 +2499,21 @@ argomenti opzionali, questi verranno sempre promossi, pertanto nella ricezione
 dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
 \macro{va\_arg} come \ctyp{int}).
 
-Uno dei problemi che si devono affrontare con le funzioni con un numero
+Un altro dei problemi che si devono affrontare con le funzioni con un numero
 variabile di argomenti è che non esiste un modo generico che permetta di
-stabilire quanti sono gli argomenti passati effettivamente in una chiamata.
+stabilire quanti sono gli argomenti effettivamente passati in una chiamata.
 
 Esistono varie modalità per affrontare questo problema; una delle più
 immediate è quella di specificare il numero degli argomenti opzionali come uno
 degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
-per specificare anche il tipo degli argomenti (come fa la stringa di formato
-per \func{printf}). 
+fisso per specificare anche il tipo degli argomenti variabili, come fa la
+stringa di formato per \func{printf} (vedi sez.~\ref{sec:file_formatted_io}).
 
-Una modalità diversa, che può essere applicata solo quando il tipo degli
-argomenti lo rende possibile, è quella che prevede di usare un valore speciale
-come ultimo argomento (come fa ad esempio \func{execl} che usa un puntatore
-\val{NULL} per indicare la fine della lista degli argomenti).
+Infine una ulteriore modalità diversa, che può essere applicata solo quando il
+tipo degli argomenti lo rende possibile, è quella che prevede di usare un
+valore speciale per l'ultimo argomento, come fa ad esempio \func{execl} che
+usa un puntatore \val{NULL} per indicare la fine della lista degli argomenti
+(vedi sez.~\ref{sec:proc_exec}).
 
 
 \subsection{Il controllo di flusso non locale}
@@ -2518,11 +2521,11 @@ come ultimo argomento (come fa ad esempio \func{execl} che usa un puntatore
 
 Il controllo del flusso di un programma in genere viene effettuato con le
 varie istruzioni del linguaggio C; fra queste la più bistrattata è il
-\code{goto}, che viene deprecato in favore dei costrutti della programmazione
-strutturata, che rendono il codice più leggibile e mantenibile. Esiste però un
-caso in cui l'uso di questa istruzione porta all'implementazione più
-efficiente e più chiara anche dal punto di vista della struttura del
-programma: quello dell'uscita in caso di errore.
+\instruction{goto}, che viene deprecato in favore dei costrutti della
+programmazione strutturata, che rendono il codice più leggibile e
+mantenibile. Esiste però un caso in cui l'uso di questa istruzione porta
+all'implementazione più efficiente e più chiara anche dal punto di vista della
+struttura del programma: quello dell'uscita in caso di errore.
 
 \index{salto~non-locale|(} 
 
@@ -2551,19 +2554,19 @@ scartando l'input come errato.\footnote{a meno che, come precisa \cite{glibc},
 Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
 norma viene realizzato salvando il contesto dello \itindex{stack}
 \textit{stack} nel punto in cui si vuole tornare in caso di errore, e
-ripristinandolo, in modo da tornare nella funzione da cui si era partiti,
-quando serve.  La funzione che permette di salvare il contesto dello
+ripristinandolo, in modo da tornare quando serve nella funzione da cui si era
+partiti.  La funzione che permette di salvare il contesto dello
 \itindex{stack} \textit{stack} è \funcd{setjmp}, il cui prototipo è:
-\begin{functions}
-  \headdecl{setjmp.h}
-  \funcdecl{int setjmp(jmp\_buf env)}
-  
-  Salva il contesto dello stack. 
 
-  \bodydesc{La funzione ritorna zero quando è chiamata direttamente e un
-    valore diverso da zero quando ritorna da una chiamata di \func{longjmp}
-    che usa il contesto salvato in precedenza.}
-\end{functions}
+\begin{funcproto}{ 
+\fhead{setjmp.h}
+\fdecl{int setjmp(jmp\_buf env)}
+\fdesc{Salva il contesto dello \textit{stack}.} 
+}
+{La funzione ritorna $0$ quando è chiamata direttamente ed un valore diverso
+  da zero quando ritorna da una chiamata di \func{longjmp} che usa il contesto
+  salvato in precedenza.}
+\end{funcproto}
   
 Quando si esegue la funzione il contesto corrente dello \itindex{stack}
 \textit{stack} viene salvato nell'argomento \param{env}, una variabile di tipo
@@ -2582,42 +2585,43 @@ chiamato \func{setjmp} ritorna, nel qual caso un successivo uso di
 \func{longjmp} può comportare conseguenze imprevedibili (e di norma fatali)
 per il processo.
   
-Come accennato per effettuare un salto non-locale ad
-un punto precedentemente stabilito con \func{setjmp} si usa la funzione
-\funcd{longjmp}; il suo prototipo è:
-\begin{functions}
-  \headdecl{setjmp.h}
-  \funcdecl{void longjmp(jmp\_buf env, int val)}
-  
-  Ripristina il contesto dello stack.
-  
-  \bodydesc{La funzione non ritorna.}
-\end{functions}
+Come accennato per effettuare un salto non-locale ad un punto precedentemente
+stabilito con \func{setjmp} si usa la funzione \funcd{longjmp}; il suo
+prototipo è:
+
+\begin{funcproto}{ 
+\fhead{setjmp.h}
+\fdecl{void longjmp(jmp\_buf env, int val)}
+\fdesc{Ripristina il contesto dello stack.} 
+}
+{La funzione non ritorna.}   
+\end{funcproto}
 
 La funzione ripristina il contesto dello \itindex{stack} \textit{stack}
 salvato da una chiamata a \func{setjmp} nell'argomento \param{env}. Dopo
-l'esecuzione della funzione il programma prosegue nel codice successivo al
-ritorno della \func{setjmp} con cui si era salvato \param{env}, che restituirà
-il valore
-\param{val} invece di zero.  Il valore di \param{val} specificato nella
-chiamata deve essere diverso da zero, se si è specificato 0 sarà comunque
-restituito 1 al suo posto.
-
-In sostanza un \func{longjmp} è analogo ad un \code{return}, solo che invece
-di ritornare alla riga successiva della funzione chiamante, il programma
-ritorna alla posizione della relativa \func{setjmp}, l'altra differenza è che
-il ritorno può essere effettuato anche attraverso diversi livelli di funzioni
-annidate.
+l'esecuzione della funzione il programma prosegue nel codice successivo alla
+chiamata della \func{setjmp} con cui si era salvato \param{env}, che
+restituirà il valore dell'argomento \param{val} invece di zero.  Il valore
+dell'argomento \param{val} deve essere sempre diverso da zero, se si è
+specificato 0 sarà comunque restituito 1 al suo posto.
+
+In sostanza l'esecuzione di \func{longjmp} è analoga a quella di una
+istruzione \instruction{return}, solo che invece di ritornare alla riga
+successiva della funzione chiamante, il programma in questo caso ritorna alla
+posizione della relativa \func{setjmp}. L'altra differenza fondamentale con
+\instruction{return} è che il ritorno può essere effettuato anche attraverso
+diversi livelli di funzioni annidate.
 
 L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
 interagiscono direttamente con la gestione dello \itindex{stack}
 \textit{stack} ed il funzionamento del compilatore stesso. In particolare
 \func{setjmp} è implementata con una macro, pertanto non si può cercare di
-ottenerne l'indirizzo, ed inoltre delle chiamate a questa funzione sono sicure
+ottenerne l'indirizzo, ed inoltre le chiamate a questa funzione sono sicure
 solo in uno dei seguenti casi:
 \begin{itemize*}
-\item come espressione di controllo in un comando condizionale, di selezione
-  o di iterazione (come \code{if}, \code{switch} o \code{while});
+\item come espressione di controllo in un comando condizionale, di selezione o
+  di iterazione (come \instruction{if}, \instruction{switch} o
+  \instruction{while});
 \item come operando per un operatore di uguaglianza o confronto in una
   espressione di controllo di un comando condizionale, di selezione o di
   iterazione;
@@ -2628,8 +2632,8 @@ solo in uno dei seguenti casi:
 
 In generale, dato che l'unica differenza fra la chiamata diretta e quella
 ottenuta nell'uscita con un \func{longjmp} è costituita dal valore di ritorno
-di \func{setjmp}, quest'ultima usualmente viene chiamata all'interno di un
-comando \code{if}.
+di \func{setjmp}, pertanto quest'ultima viene usualmente chiamata all'interno
+di un una istruzione \instruction{if} che permetta di distinguere i due casi.
 
 Uno dei punti critici dei salti non-locali è quello del valore delle
 variabili, ed in particolare quello delle \index{variabili!automatiche}
@@ -2659,13 +2663,13 @@ dichiarandole tutte come \direct{volatile}.\footnote{la direttiva
 \index{salto~non-locale|)}
 
 
-\subsection{La \textit{endianess}}
-\label{sec:sock_endianess}
+\subsection{La \textit{endianness}}
+\label{sec:sock_endianness}
 
-\itindbeg{endianess} 
+\itindbeg{endianness} 
 
-Uno dei problemi di programmazione che può dar luogo ad effetti imprevisti è
-quello relativo alla cosiddetta \textit{endianess}.  Questa è una
+Un altro dei problemi di programmazione che può dar luogo ad effetti
+imprevisti è quello relativo alla cosiddetta \textit{endianness}.  Questa è una
 caratteristica generale dell'architettura hardware di un computer che dipende
 dal fatto che la rappresentazione di un numero binario può essere fatta in due
 modi, chiamati rispettivamente \textit{big endian} e \textit{little endian} a
@@ -2674,15 +2678,15 @@ intere (ed in genere in diretta corrispondenza a come sono poi in realtà
 cablati sui bus interni del computer).
 
 \begin{figure}[!htb]
-  \centering \includegraphics[height=3cm]{img/endianess}
+  \centering \includegraphics[height=3cm]{img/endianness}
   \caption{Schema della disposizione dei dati in memoria a seconda della
-    \textit{endianess}.}
-  \label{fig:sock_endianess}
+    \textit{endianness}.}
+  \label{fig:sock_endianness}
 \end{figure}
 
 Per capire meglio il problema si consideri un intero a 32 bit scritto in una
 locazione di memoria posta ad un certo indirizzo. Come illustrato in
-fig.~\ref{fig:sock_endianess} i singoli bit possono essere disposti in memoria
+fig.~\ref{fig:sock_endianness} i singoli bit possono essere disposti in memoria
 in due modi: a partire dal più significativo o a partire dal meno
 significativo.  Così nel primo caso si troverà il byte che contiene i bit più
 significativi all'indirizzo menzionato e il byte con i bit meno significativi
@@ -2691,43 +2695,49 @@ dato che si trova per prima la parte più grande. Il caso opposto, in cui si
 parte dal bit meno significativo è detto per lo stesso motivo \textit{little
   endian}.
 
-Si può allora verificare quale tipo di \textit{endianess} usa il proprio
+Si può allora verificare quale tipo di \textit{endianness} usa il proprio
 computer con un programma elementare che si limita ad assegnare un valore ad
 una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
 Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
 allora se lo eseguiamo su un normale PC compatibile, che è \textit{little
   endian} otterremo qualcosa del tipo:
-\begin{verbatim}
+\begin{Command}
 [piccardi@gont sources]$ ./endtest
+\end{Command}
+%$
+\begin{Terminal}
 Using value ABCDEF01
 val[0]= 1
 val[1]=EF
 val[2]=CD
 val[3]=AB
-\end{verbatim}%$
+\end{Terminal}
 mentre su un vecchio Macintosh con PowerPC, che è \textit{big endian} avremo
 qualcosa del tipo:
-\begin{verbatim}
+\begin{Command}
 piccardi@anarres:~/gapil/sources$ ./endtest
+\end{Command}
+%$
+\begin{Terminal}
 Using value ABCDEF01
 val[0]=AB
 val[1]=CD
 val[2]=EF
 val[3]= 1
-\end{verbatim}%$
+\end{Terminal}
 
-L'attenzione alla \textit{endianess} nella programmazione è importante, perché
+L'attenzione alla \textit{endianness} nella programmazione è importante, perché
 se si fanno assunzioni relative alla propria architettura non è detto che
 queste restino valide su un'altra architettura. Inoltre, come vedremo ad
 esempio in sez.~\ref{sec:sock_addr_func}, si possono avere problemi quando ci
 si trova a usare valori di un formato con una infrastruttura che ne usa
 un altro. 
 
-La \textit{endianess} di un computer dipende essenzialmente dalla architettura
+La \textit{endianness} di un computer dipende essenzialmente dalla architettura
 hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
 IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
 formato dei dati contenuti nelle intestazioni dei protocolli di rete (il
-cosiddetto \textit{network order} è anch'esso \textit{big endian}; altri
+cosiddetto \textit{network order}) è anch'esso \textit{big endian}; altri
 esempi di uso di questi due diversi formati sono quello del bus PCI, che è
 \textit{little endian}, o quello del bus VME che è \textit{big endian}.
 
@@ -2762,11 +2772,27 @@ di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
 Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
 accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
   11}) il valore della seconda assumendo che il primo byte sia quello meno
-significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianess}, che sia
+significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianness}, che sia
 \textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
 il valore del confronto delle due variabili. 
-\itindend{endianess}
 
+In generale non ci si deve preoccupare della \textit{endianness} all'interno
+di un programma fintanto che questo non deve generare o manipolare dei dati
+che sono scambiati con altre macchine, ad esempio tramite via rete o tramite
+dei file binari. Nel primo caso la scelta è già stata fatta nella
+standardizzazione dei protocolli, che hanno adottato il \textit{big endian}
+(che viene detto anche per questo \textit{network order} e vedremo in
+sez.~\ref{sec:sock_func_ord} le funzioni di conversione che devono essere
+usate.
+
+Nel secondo caso occorre sapere quale \textit{endianness} è stata usata nei
+dati memorizzati sul file e tenerne conto nella rilettura e nella
+manipolazione e relativa modifica (e salvataggio). La gran parte dei formati
+binari standardizzati specificano quale \textit{endianness} viene utilizzata e
+basterà identificare qual'è, se se ne deve definire uno per i propri scopi
+basterà scegliere una volta per tutte quale usare e attenersi alla scelta.
+
+\itindend{endianness}
 
 
 % LocalWords:  like exec kernel thread main ld linux static linker char envp Gb
@@ -2793,13 +2819,13 @@ il valore del confronto delle due variabili.
 % LocalWords:  exithandler handler violation inline SOURCE SVID XOPEN mincore
 % LocalWords:  length unsigned vec EFAULT EAGAIN dell'I memalign valloc posix
 % LocalWords:  boundary memptr alignment sizeof overrun mcheck abortfn enum big
-% LocalWords:  mprobe DISABLED HEAD TAIL touch right emacs OSTYPE endianess IBM
+% LocalWords:  mprobe DISABLED HEAD TAIL touch right emacs OSTYPE endianness IBM
 % LocalWords:  endian little endtest Macintosh PowerPC Intel Digital Motorola
 % LocalWords:  Sun order VME  loader Windows DLL shared objects PRELOAD termios
 % LocalWords:  is to LC SIG str mem wcs assert ctype dirent fcntl signal stdio
 % LocalWords:  times library utmp syscall number Filesystem Hierarchy pathname
 % LocalWords:  context assembler sysconf fork Dinamic huge segmentation program
-% LocalWords:  break  store
+% LocalWords:  break  store Using
 
 %%% Local Variables: 
 %%% mode: latex
index 5c526dfec4e17a394d79ef291303a8a759b25b5f..ba788ae20154f669f73a4f40bbfe8524843cb325 100644 (file)
@@ -12,7 +12,7 @@
 \chapter{La gestione dei processi}
 \label{cha:process_handling}
 
-Come accennato nell'introduzione in un sistema Unix tutte le operazioni
+Come accennato nell'introduzione in un sistema unix-like tutte le operazioni
 vengono svolte tramite opportuni processi.  In sostanza questi ultimi vengono
 a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
 
@@ -25,42 +25,45 @@ finale introdurremo alcune problematiche generiche della programmazione in
 ambiente multitasking.
 
 
-\section{Introduzione}
-\label{sec:proc_gen}
+\section{Le funzioni di base}% della gestione dei processi}
+\label{sec:proc_handling}
 
-Inizieremo con un'introduzione generale ai concetti che stanno alla base della
-gestione dei processi in un sistema unix-like. Introdurremo in questa sezione
-l'architettura della gestione dei processi e le sue principali
-caratteristiche, dando una panoramica sull'uso delle principali funzioni di
-gestione.
+In questa sezione tratteremo le problematiche della gestione dei processi
+all'interno del sistema, illustrandone tutti i dettagli.  Inizieremo con una
+panoramica dell'architettura dei processi, tratteremo poi le funzioni
+elementari che permettono di leggerne gli identificatori, per poi passare alla
+spiegazione delle funzioni base che si usano per la creazione e la
+terminazione dei processi, e per la messa in esecuzione degli altri programmi.
 
 
 \subsection{L'architettura della gestione dei processi}
 \label{sec:proc_hierarchy}
 
-A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
-generazione di nuovi processi è un'operazione privilegiata) una delle
-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 univoco, il cosiddetto \textit{process identifier} o, più brevemente,
-\acr{pid}, assegnato in forma progressiva (vedi sez.~\ref{sec:proc_pid})
-quando il processo viene creato.
+A differenza di quanto avviene in altri sistemi, ad esempio nel VMS la
+generazione di nuovi processi è un'operazione privilegiata, una delle
+caratteristiche fondanti di Unix, che esamineremo in dettaglio più avanti, è
+che qualunque processo può a sua volta generarne altri. Ogni processo è
+identificato presso il sistema da un numero univoco, il cosiddetto
+\textit{process identifier} o, più brevemente, \acr{pid}, assegnato in forma
+progressiva (vedi sez.~\ref{sec:proc_pid}) quando il processo viene creato.
 
-Una seconda caratteristica di un sistema Unix è che la generazione di un
+Una seconda caratteristica di un sistema unix-like è che la generazione di un
 processo è un'operazione separata rispetto al lancio di un programma. In
 genere la sequenza è sempre quella di creare un nuovo processo, il quale
 eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
 quello che fa la shell quando mette in esecuzione il programma che gli
 indichiamo nella linea di comando.
 
-Una terza caratteristica è che ogni processo è sempre stato generato da un
-altro, che viene chiamato processo padre (\textit{parent process}). Questo
-vale per tutti i processi, con una sola eccezione: dato che ci deve essere un
-punto di partenza esiste un processo speciale (che normalmente è
-\cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
-di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
-\acr{pid} uguale a 1 e non è figlio di nessun altro processo.
+Una terza caratteristica del sistema è che ogni processo è sempre stato
+generato da un altro processo, il processo generato viene chiamato
+\textit{processo figlio} (\textit{child process}) mentre quello che lo ha
+viene chiamato \textsl{processo padre} (\textit{parent process}). Questo vale
+per tutti i processi, con una sola eccezione, dato che ci deve essere un punto
+di partenza esiste un processo speciale (che normalmente è \cmd{/sbin/init}),
+che come abbiamo accennato in sez.~\ref{sec:intro_kern_and_sys} viene lanciato
+dal kernel alla conclusione della fase di avvio. Essendo questo il primo
+processo lanciato dal sistema ha sempre il \acr{pid} uguale a 1 e non è figlio
+di nessun altro processo.
 
 Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
 partire tutti gli altri processi necessari al funzionamento del sistema,
@@ -70,12 +73,16 @@ essi in sez.~\ref{sec:proc_termination}) e non può mai essere terminato. La
 struttura del sistema comunque consente di lanciare al posto di \cmd{init}
 qualunque altro programma, e in casi di emergenza (ad esempio se il file di
 \cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
-posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
+posto.\footnote{la cosa si fa passando la riga \cmd{init=/bin/sh} come
+  parametro di avvio del kernel, l'argomento è di natura amministrativa e
+  trattato in sez.~5.3 di \cite{AGL}.}
 
 \begin{figure}[!htb]
   \footnotesize
-\begin{verbatim}
+\begin{Command}
 [piccardi@gont piccardi]$ pstree -n 
+\end{Command}
+\begin{Terminal}
 init-+-keventd
      |-kapm-idled
      |-kreiserfsd
@@ -107,34 +114,34 @@ init-+-keventd
      |-5*[getty]
      |-snort
      `-wwwoffled
-\end{verbatim} %$
+\end{Terminal}
+%$
   \caption{L'albero dei processi, così come riportato dal comando
     \cmd{pstree}.}
   \label{fig:proc_tree}
 \end{figure}
 
 Dato che tutti i processi attivi nel sistema sono comunque generati da
-\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
-  vero, in Linux ci sono alcuni processi speciali che pur comparendo come
-  figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
-  direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, ecc.).} si
-possono classificare i processi con la relazione padre/figlio in
-un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
-organizzati in un albero di directory (si veda
-sez.~\ref{sec:file_organization}); in fig.~\ref{fig:proc_tree} si è mostrato il
-risultato del comando \cmd{pstree} che permette di visualizzare questa
-struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
-processi.
+\cmd{init} o da uno dei suoi figli si possono classificare i processi con la
+relazione padre/figlio in un'organizzazione gerarchica ad albero. In
+fig.~\ref{fig:proc_tree} si è mostrato il risultato del comando \cmd{pstree}
+che permette di visualizzare questa struttura, alla cui base c'è \cmd{init}
+che è progenitore di tutti gli altri processi.\footnote{in realtà questo non è
+  del tutto vero, in Linux, specialmente nelle versioni più recenti del
+  kernel, ci sono alcuni processi speciali (come \cmd{keventd}, \cmd{kswapd},
+  ecc.) che pur comparendo nei comandi come figli di \cmd{init}, o con
+  \acr{pid} successivi ad uno, sono in realtà processi interni al kernel e che
+  non rientrano in questa classificazione.}
 
 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
-\itindex{process~table} \textit{process table}; per ciascun processo viene
-mantenuta una voce, costituita da una struttura \struct{task\_struct}, nella
-tabella dei processi che contiene tutte le informazioni rilevanti per quel
-processo. Tutte le strutture usate a questo scopo sono dichiarate nell'header
-file \file{linux/sched.h}, ed uno schema semplificato, che riporta la
-struttura delle principali informazioni contenute nella \struct{task\_struct}
-(che in seguito incontreremo a più riprese), è mostrato in
-fig.~\ref{fig:proc_task_struct}.
+\itindex{process~table} \textit{process table}. Per ciascun processo viene
+mantenuta una voce in questa tabella, costituita da una struttura
+\struct{task\_struct}, che contiene tutte le informazioni rilevanti per quel
+processo. Tutte le strutture usate a questo scopo sono dichiarate
+nell'\textit{header file} \file{linux/sched.h}, ed uno schema semplificato,
+che riporta la struttura delle principali informazioni contenute nella
+\struct{task\_struct} (che in seguito incontreremo a più riprese), è mostrato
+in fig.~\ref{fig:proc_task_struct}.
 
 \begin{figure}[!htb]
   \centering \includegraphics[width=14cm]{img/task_struct}
@@ -149,10 +156,10 @@ fig.~\ref{fig:proc_task_struct}.
 
 Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
 \textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
-eseguito ad ogni system call ed ad ogni interrupt,\footnote{più in una serie
-  di altre occasioni.} ma può essere anche attivato esplicitamente. Il timer
-di sistema provvede comunque a che esso sia invocato periodicamente; generando
-un interrupt periodico secondo la frequenza specificata dalla costante
+eseguito ad ogni \textit{system call} ed ad ogni interrupt e in una serie di
+altre occasioni, ma può essere anche attivato esplicitamente. Il timer di
+sistema provvede comunque a che esso sia invocato periodicamente; generando un
+interrupt periodico secondo la frequenza specificata dalla costante
 \const{HZ},\footnote{fino al kernel 2.4 il valore di \const{HZ} era 100 su
   tutte le architetture tranne l'alpha, per cui era 1000, nel 2.6 è stato
   portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di
@@ -161,98 +168,46 @@ un interrupt periodico secondo la frequenza specificata dalla costante
   refresh della televisione); occorre fare attenzione a non confondere questo
   valore con quello dei \itindex{clock~tick} \textit{clock tick} (vedi
   sez.~\ref{sec:sys_unix_time}).} definita in \file{asm/param.h}, ed il cui
-valore è espresso in Hertz.\footnote{a partire dal kernel 2.6.21 è stato
-  introdotto (a cura di Ingo Molnar) un meccanismo completamente diverso,
-  detto \textit{tickless}, in cui non c'è più una interruzione periodica con
-  frequenza prefissata, ma ad ogni chiamata del timer viene programmata
-  l'interruzione successiva sulla base di una stima; in questo modo si evita
-  di dover eseguire un migliaio di interruzioni al secondo anche su macchine
-  che non stanno facendo nulla, con un forte risparmio nell'uso dell'energia
-  da parte del processore che può essere messo in stato di sospensione anche
-  per lunghi periodi di tempo.}
-
-Ogni volta che viene eseguito, lo \itindex{scheduler} \textit{scheduler}
-effettua il calcolo delle priorità dei vari processi attivi (torneremo su
-questo in sez.~\ref{sec:proc_priority}) e stabilisce quale di essi debba
-essere posto in esecuzione fino alla successiva invocazione.
-
-
-\subsection{Una panoramica sulle funzioni fondamentali}
-\label{sec:proc_handling_intro}
-
-Tradizionalmente in un sistema unix-like i processi vengono sempre creati da
-altri processi tramite la funzione \func{fork}; il nuovo processo (che viene
-chiamato \textsl{figlio}) creato dalla \func{fork} è una copia identica del
-processo processo originale (detto \textsl{padre}), ma ha un nuovo \acr{pid} e
-viene eseguito in maniera indipendente (le differenze fra padre e figlio sono
-affrontate in dettaglio in sez.~\ref{sec:proc_fork}).
-
-Se si vuole che il processo padre si fermi fino alla conclusione del processo
-figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
-funzione \func{wait} o la funzione \func{waitpid} (si veda
-sez.~\ref{sec:proc_wait}); queste funzioni restituiscono anche un'informazione
-abbastanza limitata sulle cause della terminazione del processo figlio.
-
-Quando un processo ha concluso il suo compito o ha incontrato un errore non
-risolvibile esso può essere terminato con la funzione \func{exit} (si veda
-quanto discusso in sez.~\ref{sec:proc_conclusion}). La vita del processo però
-termina completamente solo quando la notifica della sua conclusione viene
-ricevuta dal processo padre, a quel punto tutte le risorse allocate nel
-sistema ad esso associate vengono rilasciate.
-
-Avere due processi che eseguono esattamente lo stesso codice non è molto
-utile, normalmente si genera un secondo processo per affidargli l'esecuzione
-di un compito specifico (ad esempio gestire una connessione dopo che questa è
-stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
-quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
-coi processi che è la \func{exec}.
-
-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 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
-particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
-prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
-non ritorna mai (in quanto con essa viene eseguito un altro programma).
-
+valore è espresso in Hertz.
 
-\section{Le funzioni di base}% della gestione dei processi}
-\label{sec:proc_handling}
+A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo
+completamente diverso, detto \textit{tickless}, in cui non c'è più una
+interruzione periodica con frequenza prefissata, ma ad ogni chiamata del timer
+viene programmata l'interruzione successiva sulla base di una stima; in questo
+modo si evita di dover eseguire un migliaio di interruzioni al secondo anche
+su macchine che non stanno facendo nulla, con un forte risparmio nell'uso
+dell'energia da parte del processore che può essere messo in stato di
+sospensione anche per lunghi periodi di tempo.
 
-In questa sezione tratteremo le problematiche della gestione dei processi
-all'interno del sistema, illustrandone tutti i dettagli.  Inizieremo con le
-funzioni elementari che permettono di leggerne gli identificatori, per poi
-passare alla spiegazione delle funzioni base che si usano per la creazione e
-la terminazione dei processi, e per la messa in esecuzione degli altri
-programmi.
+Indipendentemente dalle motivazioni per cui questo avviene, ogni volta che
+viene eseguito lo \itindex{scheduler} \textit{scheduler} effettua il calcolo
+delle priorità dei vari processi attivi (torneremo su questo in
+sez.~\ref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
+esecuzione fino alla successiva invocazione.
 
 
 \subsection{Gli identificatori dei processi}
 \label{sec:proc_pid}
 
-Come accennato nell'introduzione, ogni processo viene identificato dal sistema
-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
+Come accennato nella sezione precedente ogni processo viene identificato dal
+sistema da un numero identificativo univoco, il \textit{process ID} o
+\acr{pid}. Questo è un tipo di dato standard, \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\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 sez.~\ref{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 \const{PID\_MAX} in
-  \file{threads.h} e direttamente in \file{fork.c}, con il kernel 2.5.x e la
-  nuova interfaccia per i \itindex{thread} \textit{thread} creata da Ingo
-  Molnar anche il meccanismo di allocazione dei \acr{pid} è stato modificato;
-  il valore massimo è impostabile attraverso il file
+Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
+processo viene creato,\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
+  sez.~\ref{sec:sess_proc_group}).} fino ad un limite che, essendo il
+tradizionalmente 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, erano definiti dalla macro
+  \const{PID\_MAX} nei file \file{threads.h} e \file{fork.c} dei sorgenti del
+  kernel, con il 2.6.x e la nuova interfaccia per i \itindex{thread}
+  \textit{thread} anche il meccanismo di allocazione dei \acr{pid} è stato
+  modificato ed il valore massimo è impostabile attraverso il file
   \procfile{/proc/sys/kernel/pid\_max} e di default vale 32768.} che serve a
 riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
 Per questo motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di
@@ -263,19 +218,18 @@ sono stati creati, questo viene chiamato in genere \acr{ppid} (da
 \textit{parent process ID}).  Questi due identificativi possono essere
 ottenuti usando le due funzioni \funcd{getpid} e \funcd{getppid}, i cui
 prototipi sono:
-\begin{functions}
-  \headdecl{sys/types.h} 
-  \headdecl{unistd.h} 
-  \funcdecl{pid\_t getpid(void)}
-  
-  Restituisce il \acr{pid} del processo corrente.  
-  
-  \funcdecl{pid\_t getppid(void)} 
-  
-  Restituisce il \acr{pid} del padre del processo corrente.
 
-\bodydesc{Entrambe le funzioni non riportano condizioni di errore.}
-\end{functions}
+\begin{funcproto}{ 
+\fhead{sys/types.h}
+\fhead{unistd.h}
+\fdecl{pid\_t getpid(void)}
+\fdesc{Restituisce il \acr{pid} del processo corrente..} 
+\fdecl{pid\_t getppid(void)}
+\fdesc{Restituisce il \acr{pid} del padre del processo corrente.} 
+}
+{Entrambe le funzioni non riportano condizioni di errore.}   
+\end{funcproto}
+
 \noindent esempi dell'uso di queste funzioni sono riportati in
 fig.~\ref{fig:proc_fork_code}, nel programma \file{ForkTest.c}.
 
@@ -284,7 +238,11 @@ candidato per generare ulteriori indicatori associati al processo di cui
 diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
 funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
 \acr{pid} per generare un \itindex{pathname} \textit{pathname} univoco, che
-non potrà essere replicato da un altro processo che usi la stessa funzione.
+non potrà essere replicato da un altro processo che usi la stessa
+funzione. Questo utilizzo però può risultare pericoloso, un \acr{pid} infatti
+è univoco solo fintanto che un processo è attivo, una volta terminato esso
+potrà essere riutilizzato da un processo completamente diverso, e di questo
+bisogna essere ben consapevoli.
 
 Tutti i processi figli dello stesso processo padre sono detti
 \textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
@@ -294,13 +252,14 @@ cap.~\ref{cha:session}, dove esamineremo gli altri identificativi associati ad
 un processo e le varie relazioni fra processi utilizzate per definire una
 sessione.
 
-Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
-sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione), ad ogni
-processo vengono associati degli altri identificatori che vengono usati per il
-controllo di accesso.  Questi servono per determinare se un processo può
-eseguire o meno le operazioni richieste, a seconda dei privilegi e
-dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
-affrontato in dettaglio in sez.~\ref{sec:proc_perms}.
+Oltre al \acr{pid} e al \acr{ppid}, e a quelli che vedremo in
+sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione, ad ogni
+processo vengono associati degli ulteriori identificatori ed in particolare
+quelli che vengono usati per il controllo di accesso.  Questi servono per
+determinare se un processo può eseguire o meno le operazioni richieste, a
+seconda dei privilegi e dell'identità di chi lo ha posto in esecuzione;
+l'argomento è complesso e sarà affrontato in dettaglio in
+sez.~\ref{sec:proc_perms}.
 
 
 \subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
@@ -319,15 +278,15 @@ multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei
   \textit{thread} che tratteremo al cap.~\ref{cha:threads}, è in parte minore,
   ma \func{fork} resta comunque la funzione principale per la creazione di
   processi.} Il prototipo della funzione è:
-\begin{functions}
-  \headdecl{sys/types.h} 
-  \headdecl{unistd.h} 
-  \funcdecl{pid\_t fork(void)} 
-  Crea un nuovo processo.
-  
-  \bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
-    zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
-    errore; \var{errno} può assumere i valori:
+
+\begin{funcproto}{ 
+\fhead{unistd.h}
+\fdecl{pid\_t fork(void)}
+\fdesc{Crea un nuovo processo.} 
+}
+{La funzione ritorna il \acr{pid} del figlio al padre e $0$ al figlio in caso 
+  di successo e $-1$ al padre senza creare il figlio per un errore,
+  nel qual caso \var{errno} assumerà uno dei valori: 
   \begin{errlist}
   \item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro
     processo (per allocare la tabella delle pagine e le strutture del task) o
@@ -335,24 +294,25 @@ multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei
   \item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
     strutture necessarie al kernel per creare il nuovo processo.
   \end{errlist}}
-\end{functions}
+\end{funcproto}
 
 Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
 il processo figlio continuano ad essere eseguiti normalmente a partire
-dall'istruzione successiva alla \func{fork}; il processo figlio è però una
-copia del padre, e riceve una copia dei \index{segmento!testo} segmenti di
-testo, \itindex{stack} \textit{stack} e \index{segmento!dati} dati (vedi
+dall'istruzione successiva alla \func{fork}. Il processo figlio è una copia del
+padre, e riceve una copia dei \index{segmento!testo} segmenti di testo,
+\index{segmento!dati} dati e dello \itindex{stack} \textit{stack} (vedi
 sez.~\ref{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.
+padre. Si tenga presente però che la memoria è copiata e non condivisa,
+pertanto padre e figlio vedranno variabili diverse e le eventuali modifiche
+saranno totalmente indipendenti.
 
 Per quanto riguarda la gestione della memoria, in generale il
 \index{segmento!testo} 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
+condiviso e tenuto in sola lettura per il padre e per i figli. Per gli altri
 segmenti Linux utilizza la tecnica del \itindex{copy~on~write} \textit{copy on
-  write}; questa tecnica comporta che una pagina di memoria viene
+  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).
+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
@@ -362,30 +322,20 @@ 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
 nel figlio è zero; in questo modo il programma può identificare se viene
 eseguito dal padre o dal figlio.  Si noti come la funzione \func{fork} ritorni
-\textbf{due} volte: una nel padre e una nel figlio. 
+due volte, una nel padre e una nel figlio.
 
 La scelta di questi valori di ritorno non è casuale, un processo infatti può
 avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
-permette di identificare quello appena creato; al contrario un figlio ha
-sempre un solo padre (il cui \acr{pid} può sempre essere ottenuto con
-\func{getppid}, vedi sez.~\ref{sec:proc_pid}) per cui si usa il valore nullo,
-che non è il \acr{pid} di nessun processo.
-
-\begin{figure}[!htbp]
-  \footnotesize \centering
-  \begin{minipage}[c]{\codesamplewidth}
-  \includecodesample{listati/ForkTest.c}
-  \end{minipage}
-  \normalsize
-  \caption{Esempio di codice per la creazione di nuovi processi.}
-  \label{fig:proc_fork_code}
-\end{figure}
-
-Normalmente la chiamata a \func{fork} può fallire solo per due ragioni, o ci
-sono già troppi processi nel sistema (il che di solito è sintomo che
-qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
-sul numero totale di processi permessi all'utente (vedi
-sez.~\ref{sec:sys_resource_limit}, ed in particolare
+permette di identificare quello appena creato. Al contrario un figlio ha
+sempre un solo padre, il cui \acr{pid} può sempre essere ottenuto con
+\func{getppid}, come spiegato in sez.~\ref{sec:proc_pid}, per cui si usa il
+valore nullo, che non è il \acr{pid} di nessun processo.
+
+Normalmente la chiamata a \func{fork} può fallire solo per due ragioni: o ci
+sono già troppi processi nel sistema, il che di solito è sintomo che
+qualcos'altro non sta andando per il verso giusto, o si è ecceduto il limite
+sul numero totale di processi permessi all'utente argomento su cui torneremo
+in sez.~\ref{sec:sys_resource_limit}, (vedi in particolare
 tab.~\ref{tab:sys_rlimit_values}).
 
 L'uso di \func{fork} avviene secondo due modalità principali; la prima è
@@ -407,12 +357,24 @@ seconda modalità (una \func{fork} seguita da una \func{exec}) in un'unica
 operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
 scelto di mantenere questa separazione, dato che, come per la prima modalità
 d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
-aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
-seconda modalità d'uso, avere le due funzioni separate permette al figlio di
-cambiare gli attributi del processo (maschera dei segnali, redirezione
-dell'output, identificatori) prima della \func{exec}, rendendo così
-relativamente facile intervenire sulle le modalità di esecuzione del nuovo
-programma.
+aver bisogno di eseguire una \func{exec}. 
+
+Inoltre, anche nel caso della seconda modalità d'uso, avere le due funzioni
+separate permette al figlio di cambiare alcune caratteristiche del processo
+(maschera dei segnali, redirezione dell'output, utente per conto del cui viene
+eseguito, e molto altro su cui torneremo in seguito) prima della \func{exec},
+rendendo così relativamente facile intervenire sulle le modalità di esecuzione
+del nuovo programma.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{\codesamplewidth}
+  \includecodesample{listati/ForkTest.c}
+  \end{minipage}
+  \normalsize
+  \caption{Esempio di codice per la creazione di nuovi processi.}
+  \label{fig:proc_fork_code}
+\end{figure}
 
 In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
 di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
@@ -420,11 +382,10 @@ 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
+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.truelite.it/gapil_source.tgz}
-{\textsf{http://gapil.truelite.it/gapil\_source.tgz}}.
+\url{http://gapil.truelite.it/gapil_source.tgz}.
 
 Decifrato il numero di figli da creare, il ciclo principale del programma
 (\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
@@ -437,13 +398,16 @@ attende il numero di secondi specificato, e procede nell'esecuzione del ciclo;
 alla conclusione del ciclo, prima di uscire, può essere specificato un altro
 periodo di attesa.
 
-Se eseguiamo il comando\footnote{che è preceduto dall'istruzione \code{export
-    LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche.}
-senza specificare attese (come si può notare in (\texttt{\small 17--19}) i
-valori predefiniti specificano di non attendere), otterremo come output sul
+Se eseguiamo il comandoche è preceduto dall'istruzione \code{export
+  LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche, senza
+specificare attese (come si può notare in (\texttt{\small 17--19}) i valori
+predefiniti specificano di non attendere), otterremo come risultato sul
 terminale:
-\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
+\begin{Command}
 [piccardi@selidor sources]$ export LD_LIBRARY_PATH=./; ./forktest 3
+\end{Command}
+%$
+\begin{Terminal}
 Process 1963: forking 3 child
 Spawned 1 child, pid 1964 
 Child 1 successfully executing
@@ -457,8 +421,7 @@ Child 3 successfully executing
 Child 3, parent 1963, exiting
 Spawned 3 child, pid 1966 
 Go to next child 
-\end{Verbatim} 
-%$
+\end{Terminal} 
 
 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
 si può dire quale processo fra il padre ed il figlio venga eseguito per primo
@@ -485,41 +448,54 @@ occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
 rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race
   condition} (vedi sez.~\ref{sec:proc_race_cond}).
 
-In realtà a partire dal kernel 2.5.2-pre10 il nuovo \itindex{scheduler}
-\textit{scheduler} di Ingo Molnar esegue sempre per primo il
-figlio;\footnote{i risultati precedenti sono stati ottenuti usando un kernel
-  della serie 2.4.}  questa è una ottimizzazione che serve a evitare che il
-padre, effettuando per primo una operazione di scrittura in memoria, attivi il
-meccanismo del \itindex{copy~on~write} \textit{copy on write}. Questa
-operazione infatti potrebbe risultare del tutto inutile qualora il figlio
-fosse stato creato solo per eseguire una \func{exec}, in tal caso infatti si
-invocherebbe un altro programma scartando completamente lo spazio degli
-indirizzi, rendendo superflua la copia della memoria modificata dal padre.
-
-% TODO spiegare l'ulteriore cambiamento in ponte con il 2.6.32, che fa girare
-% prima il padre per questioni di caching nella CPU
-
-Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata subito
-avendo così la certezza che il \itindex{copy~on~write} \textit{copy on write}
-viene utilizzato solo quando necessario. Quanto detto in precedenza vale
-allora soltanto per i kernel fino al 2.4; per mantenere la portabilità è però
-opportuno non fare affidamento su questo comportamento, che non si riscontra
-in altri Unix e nelle versioni del kernel precedenti a quella indicata.
-
-Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
-processi completamente separati, le modifiche delle variabili nei processi
-figli (come l'incremento di \var{i} in \texttt{\small 31}) sono visibili solo
-a loro (ogni processo vede solo la propria copia della memoria), e non hanno
-alcun effetto sul valore che le stesse variabili hanno nel processo padre (ed
-in eventuali altri processi figli che eseguano lo stesso codice).
+In realtà con l'introduzione dei kernel della serie 2.6 lo \itindex{scheduler}
+\textit{scheduler} è stato modificato per eseguire sempre per primo il
+figlio.\footnote{i risultati precedenti infatti sono stati ottenuti usando un
+  kernel della serie 2.4.}  Questa è una ottimizzazione adottata per evitare
+che il padre, effettuando per primo una operazione di scrittura in memoria,
+attivasse il meccanismo del \itindex{copy~on~write} \textit{copy on write},
+operazione inutile qualora il figlio venga creato solo per eseguire una
+\func{exec} su altro programma che scarta completamente lo spazio degli
+indirizzi e rende superflua la copia della memoria modificata dal
+padre. Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata
+subito, con la certezza di utilizzare \itindex{copy~on~write} \textit{copy on
+  write} solo quando necessario.
+
+Con il kernel 2.6.32 però il comportamento è stato nuovamente cambiato,
+stavolta facendo eseguire per primo sempre il padre. Si è realizzato infatti
+che l'eventualità prospettata per la scelta precedente era comunque molto
+improbabile, mentre l'esecuzione immediata del padre presenta sempre il
+vantaggio di poter utilizzare immediatamente tutti i dati che sono nella cache
+della CPU e nella unità di gestione della memoria virtuale senza doverli
+invalidare, cosa che per i processori moderni, che hanno linee di cache
+interne molto profonde, avrebbe un forte impatto sulle prestazioni.
+
+Allora anche se quanto detto in precedenza vale come comportamento effettivo
+dei programmi soltanto per i kernel fino alla serie 2.4, per mantenere la
+portabilità con altri kernel unix-like, e con i diversi comportamenti adottati
+dalle Linux nelle versioni successive, è opportuno non fare affidamento su
+nessun tipo comportamento predefinito e non dare per assunta l'esecuzione
+preventiva del padre o del figlio.
+
+Si noti poi come dopo la \func{fork}, essendo i segmenti di memoria utilizzati
+dai singoli processi completamente indipendenti, le modifiche delle variabili
+nei processi figli, come l'incremento di \var{i} in (\texttt{\small 31}), sono
+visibili solo a loro, (ogni processo vede solo la propria copia della
+memoria), e non hanno alcun effetto sul valore che le stesse variabili hanno
+nel processo padre ed in eventuali altri processi figli che eseguano lo stesso
+codice.
 
 Un secondo aspetto molto importante nella creazione dei processi figli è
-quello dell'interazione dei vari processi con i file; per illustrarlo meglio
-proviamo a redirigere su un file l'output del nostro programma di test, quello
-che otterremo è:
-\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
+quello dell'interazione dei vari processi con i file. Ne parleremo qui anche
+se buona parte dei concetti relativi ai file verranno trattati più avanti
+(principalmente nel cap.~\ref{cha:file_unix_interface}). Per illustrare meglio
+quello che avviene si può redirigere su un file l'output del programma di
+test, quello che otterremo è:
+\begin{Command}
 [piccardi@selidor sources]$ ./forktest 3 > output
 [piccardi@selidor sources]$ cat output
+\end{Command}
+\begin{Terminal}
 Process 1967: forking 3 child
 Child 1 successfully executing
 Child 1, parent 1967, exiting
@@ -542,64 +518,70 @@ Spawned 2 child, pid 1969
 Go to next child 
 Spawned 3 child, pid 1970 
 Go to next child 
-\end{Verbatim}
+\end{Terminal}
 che come si vede è completamente diverso da quanto ottenevamo sul terminale.
 
 Il comportamento delle varie funzioni di interfaccia con i file è analizzato
-in gran dettaglio in cap.~\ref{cha:file_unix_interface} e in
-cap.~\ref{cha:files_std_interface}. Qui basta accennare che si sono usate le
-funzioni standard della libreria del C che prevedono l'output bufferizzato; e
-questa bufferizzazione (trattata in dettaglio in sez.~\ref{sec:file_buffering})
-varia a seconda che si tratti di un file su disco (in cui il buffer viene
-scaricato su disco solo quando necessario) o di un terminale (nel qual caso il
-buffer viene scaricato ad ogni carattere di a capo).
-
-Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
-buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
-l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
-non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
-ogni figlio riceve una copia della memoria del padre, esso riceverà anche
-quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
-padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
-figlio, troveremo nel file anche tutto quello che il processo padre aveva
-scritto prima della sua creazione. E alla fine del file (dato che in questo
-caso il padre esce per ultimo) troveremo anche l'output completo del padre.
+in gran dettaglio in cap.~\ref{cha:file_unix_interface} per l'interfaccia
+nativa Unix ed in cap.~\ref{cha:files_std_interface} per la standardizzazione
+adottata nelle librerie del linguaggio C e valida per qualunque sistema
+operativo. Qui basta accennare che si sono usate le funzioni standard della
+libreria del C che prevedono l'output bufferizzato. Il punto è che questa
+bufferizzazione (che tratteremo in dettaglio in sez.~\ref{sec:file_buffering})
+varia a seconda che si tratti di un file su disco, in cui il buffer viene
+scaricato su disco solo quando necessario, o di un terminale, in cui il buffer
+viene scaricato ad ogni carattere di a capo.
+
+Nel primo esempio allora avevamo che, essendovi un a capo nella stringa
+stampata, ad ogni chiamata a \func{printf} il buffer veniva scaricato, per cui
+le singole righe comparivano a video subito dopo l'esecuzione della
+\func{printf}. Ma con la redirezione su file la scrittura non avviene più alla
+fine di ogni riga e l'output resta nel buffer. Dato che ogni figlio riceve una
+copia della memoria del padre, esso riceverà anche quanto c'è nel buffer delle
+funzioni di I/O, comprese le linee scritte dal padre fino allora. Così quando
+il buffer viene scritto su disco all'uscita del figlio, troveremo nel file
+anche tutto quello che il processo padre aveva scritto prima della sua
+creazione. E alla fine del file (dato che in questo caso il padre esce per
+ultimo) troveremo anche l'output completo del padre.
 
 L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
 valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
 solo processi diversi possono scrivere in contemporanea sullo stesso file
 (l'argomento della condivisione dei file è trattato in dettaglio in
 sez.~\ref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
-le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
-i processi figli.
-
-Quello che succede è che quando lo standard output del padre viene rediretto
-come si è fatto nell'esempio, lo stesso avviene anche per tutti i figli; la
-funzione \func{fork} infatti ha la caratteristica di duplicare nei processi
-figli tutti i file descriptor aperti nel processo padre (allo stesso modo in
-cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}), il che
-comporta che padre e figli condividono le stesse voci della
-\itindex{file~table} \textit{file table} (per la spiegazione di questi termini
-si veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente
-nel file.
-
-In questo modo se un processo scrive sul file aggiornerà la posizione corrente
-sulla \itindex{file~table} \textit{file table}, e tutti gli altri processi,
-che vedono la stessa \itindex{file~table} \textit{file table}, vedranno il
-nuovo valore. In questo modo si evita, in casi come quello appena mostrato in
-cui diversi processi scrivono sullo stesso file, che l'output successivo di un
-processo vada a sovrapporsi a quello dei precedenti: l'output potrà risultare
-mescolato, ma non ci saranno parti perdute per via di una sovrascrittura.
+le variabili in memoria, la posizione corrente sul file è condivisa fra il
+padre e tutti i processi figli. 
+
+Quello che succede è che quando lo \textit{standard output}\footnote{si chiama
+  così il file su cui un programma scrive i suoi dati in uscita, tratteremo
+  l'argomento in dettaglio in sez.~\ref{sec:file_std_descr}.} del padre viene
+rediretto come si è fatto nell'esempio, lo stesso avviene anche per tutti i
+figli. La funzione \func{fork} infatti ha la caratteristica di duplicare nei
+processi figli tutti i file descriptor (vedi sez.~\ref{sec:file_fd}) dei file
+aperti nel processo padre (allo stesso modo in cui lo fa la funzione
+\func{dup}, trattata in sez.~\ref{sec:file_dup}), il che comporta che padre e
+figli condividono le stesse voci della \itindex{file~table} \textit{file
+  table} (tratteremo in dettagli questi termini in
+sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente nel file.
+
+In questo modo se un processo scrive su un file aggiornerà la posizione
+corrente sulla \itindex{file~table} \textit{file table}, e tutti gli altri
+processi, che vedono la stessa \itindex{file~table} \textit{file table},
+vedranno il nuovo valore. In questo modo si evita, in casi come quello appena
+mostrato in cui diversi processi scrivono sullo stesso file, che l'output
+successivo di un processo vada a sovrapporsi a quello dei precedenti: l'output
+potrà risultare mescolato, ma non ci saranno parti perdute per via di una
+sovrascrittura.
 
 Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
 crea un figlio e attende la sua conclusione per proseguire, ed entrambi
-scrivono sullo stesso file; un caso tipico è la shell quando lancia un
-programma, il cui output va sullo standard output.  In questo modo, anche se
-l'output viene rediretto, il padre potrà sempre continuare a scrivere in coda
-a quanto scritto dal figlio in maniera automatica; se così non fosse ottenere
-questo comportamento sarebbe estremamente complesso necessitando di una
-qualche forma di comunicazione fra i due processi per far riprendere al padre
-la scrittura al punto giusto.
+scrivono sullo stesso file. Un caso tipico di questo comportamento è la shell
+quando lancia un programma.  In questo modo, anche se lo standard output viene
+rediretto, il padre potrà sempre continuare a scrivere in coda a quanto
+scritto dal figlio in maniera automatica; se così non fosse ottenere questo
+comportamento sarebbe estremamente complesso necessitando di una qualche forma
+di comunicazione fra i due processi per far riprendere al padre la scrittura
+al punto giusto.
 
 In generale comunque non è buona norma far scrivere più processi sullo stesso
 file senza una qualche forma di sincronizzazione in quanto, come visto anche
@@ -643,13 +625,20 @@ comune dopo l'esecuzione di una \func{fork} è la seguente:
   processore (vedi sez.~\ref{sec:proc_sched_stand},
   sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
 \item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
+\item l'insieme dei descrittori associati alle code di messaggi POSIX (vedi
+  sez.~\ref{sec:ipc_posix_mq}) che vengono copiate come i file descriptor,
+  questo significa che entrambi condivideranno gli stessi flag.
 \end{itemize*}
-Le differenze fra padre e figlio dopo la \func{fork} invece sono:\footnote{a
-  parte le ultime quattro, relative a funzionalità specifiche di Linux, le
-  altre sono esplicitamente menzionate dallo standard POSIX.1-2001.}
+
+Oltre a quelle relative ad un diverso spazio degli indirizzi (e una memoria
+totalmente indipendente) le differenze fra padre e figlio dopo l'esecuzione di
+una \func{fork} invece sono:\footnote{a parte le ultime quattro, relative a
+  funzionalità specifiche di Linux, le altre sono esplicitamente menzionate
+  dallo standard POSIX.1-2001.}
 \begin{itemize*}
 \item il valore di ritorno di \func{fork};
-\item il \acr{pid} (\textit{process id}), assegnato ad un nuovo valore univoco;
+\item il \acr{pid} (\textit{process id}), quello del figlio viene assegnato ad
+  un nuovo valore univoco;
 \item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
   impostato al \acr{pid} del padre;
 \item i valori dei tempi di esecuzione (vedi sez.~\ref{sec:sys_cpu_times}) e
@@ -670,7 +659,8 @@ Le differenze fra padre e figlio dopo la \func{fork} invece sono:\footnote{a
 \item le mappature di memoria marcate come \const{MADV\_DONTFORK} (vedi
   sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;
 \item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:process_prctl}) che
-  notifica al figlio la terminazione del padre viene cancellata;
+  notifica al figlio la terminazione del padre viene cancellata se presente
+  nel padre;
 \item il segnale di terminazione del figlio è sempre \signal{SIGCHLD} anche
   qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}). 
 \end{itemize*}
@@ -701,28 +691,29 @@ questo eviteremo di trattarla ulteriormente.
 \label{sec:proc_termination}
 
 In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
-chiudere un programma, ma dall'interno del programma stesso; avendo a che fare
-con un sistema multitasking resta da affrontare l'argomento dal punto di vista
-di come il sistema gestisce la conclusione dei processi.
+chiudere un programma, ma dall'interno del programma stesso. Avendo a che fare
+con un sistema \textit{multitasking} resta da affrontare l'argomento dal punto
+di vista di come il sistema gestisce la conclusione dei processi.
 
 Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
-programma viene terminato in maniera normale: la chiamata di \func{exit} (che
-esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
-dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
-chiamata ad \func{\_exit} (che passa direttamente alle operazioni di
-terminazione del processo da parte del kernel).
+programma viene terminato in maniera normale: la chiamata di \func{exit}che
+esegue le funzioni registrate per l'uscita e chiude i \textit{file stream} e
+poi esegue \func{\_exit}, il ritorno dalla funzione \func{main} equivalente
+alla chiamata di \func{exit}, e la chiamata diretta a \func{\_exit}, che passa
+direttamente alle operazioni di terminazione del processo da parte del kernel.
 
 Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
-modalità di conclusione anomala; queste sono in sostanza due: il programma può
-chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
-terminato da un segnale (torneremo sui segnali in cap.~\ref{cha:signals}).  In
-realtà anche la prima modalità si riconduce alla seconda, dato che
-\func{abort} si limita a generare il segnale \signal{SIGABRT}.
+modalità di conclusione anomala. Queste sono in sostanza due: il programma può
+chiamare la funzione \func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}) per
+invocare una chiusura anomala, o essere terminato da un segnale (torneremo sui
+segnali in cap.~\ref{cha:signals}).  In realtà anche la prima modalità si
+riconduce alla seconda, dato che \func{abort} si limita a generare il segnale
+\signal{SIGABRT}.
 
 Qualunque sia la modalità di conclusione di un processo, il kernel esegue
-comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
-memoria che stava usando, e così via; l'elenco completo delle operazioni
-eseguite alla chiusura di un processo è il seguente:
+comunque una serie di operazioni di terminazione: chiude tutti i file aperti,
+rilascia la memoria che stava usando, e così via; l'elenco completo delle
+operazioni eseguite alla chiusura di un processo è il seguente:
 \begin{itemize*}
 \item tutti i file descriptor sono chiusi;
 \item viene memorizzato lo stato di terminazione del processo;
@@ -740,46 +731,61 @@ eseguite alla chiusura di un processo è il seguente:
   (vedi ancora sez.~\ref{sec:sess_ctrl_term}).
 \end{itemize*}
 
+\itindbeg{termination~status} 
+
 Oltre queste operazioni è però necessario poter disporre di un meccanismo
 ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
 un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
-scelto consiste nel riportare lo stato di terminazione (il cosiddetto
-\textit{termination status}) al processo padre.
+scelto consiste nel riportare lo \itindex{termination~status} \textsl{stato di
+  terminazione} (il cosiddetto \textit{termination status}) al processo padre.
 
 Nel caso di conclusione normale, abbiamo visto in
 sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
 caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
-valore passato alle funzioni \func{exit} o \func{\_exit} (o dal valore di
-ritorno per \func{main}).  Ma se il processo viene concluso in maniera anomala
-il programma non può specificare nessun \textit{exit status}, ed è il kernel
-che deve generare autonomamente il \textit{termination status} per indicare le
-ragioni della conclusione anomala.
+valore passato come argomento alle funzioni \func{exit} o \func{\_exit} o il
+valore di ritorno per \func{main}.  Ma se il processo viene concluso in
+maniera anomala il programma non può specificare nessun \textit{exit status},
+ed è il kernel che deve generare autonomamente il \textit{termination status}
+per indicare le ragioni della conclusione anomala.
 
 Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
 quello che contraddistingue lo stato di chiusura del processo e viene
 riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
-sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
-il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
-secondo.
+sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione
+normale il kernel usa il primo (nel codice eseguito da \func{\_exit}) per
+produrre il secondo.
 
 La scelta di riportare al padre lo stato di terminazione dei figli, pur
 essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
-alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
-che sia così alla sua conclusione, dato che il padre potrebbe essere già
+alla sua creazione è scontato che ogni nuovo processo abbia un padre, non è
+detto che sia così alla sua conclusione, dato che il padre potrebbe essere già
 terminato; si potrebbe avere cioè quello che si chiama un processo
-\textsl{orfano}. 
+\textsl{orfano}.
 
 Questa complicazione viene superata facendo in modo che il processo orfano
-venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
-termina, il kernel controlla se è il padre di altri processi in esecuzione: in
-caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
-con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
-avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
-cui riportare il suo stato di terminazione.  Come verifica di questo
-comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
-ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
-\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
+venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \acr{pid} 1,
+cioè quello lanciato direttamente dal kernel all'avvio, che sta alla base
+dell'albero dei processi visto in sez.~\ref{sec:proc_hierarchy} e che anche
+per questo motivo ha un ruolo essenziale nel sistema e non può mai
+terminare.\footnote{almeno non senza un blocco completo del sistema, in caso
+  di terminazione o di non esecuzione di \cmd{init} infatti il kernel si
+  blocca con un cosiddetto \textit{kernel panic}, dato che questo è un errore
+  fatale.}
+
+Come già accennato quando un processo termina, il kernel controlla se è il
+padre di altri processi in esecuzione: in caso positivo allora il \acr{ppid}
+di tutti questi processi verrà sostituito dal kernel con il \acr{pid} di
+\cmd{init}, cioè con 1. In questo modo ogni processo avrà sempre un padre (nel
+caso possiamo parlare di un padre \textsl{adottivo}) cui riportare il suo
+stato di terminazione.  
+
+Come verifica di questo comportamento possiamo eseguire il nostro programma
+\cmd{forktest} imponendo a ciascun processo figlio due secondi di attesa prima
+di uscire, il risultato è:
+\begin{Command}
 [piccardi@selidor sources]$ ./forktest -c2 3
+\end{Command}
+\begin{Terminal}[commandchars=\\\{\}]
 Process 1972: forking 3 child
 Spawned 1 child, pid 1973 
 Child 1 successfully executing
@@ -790,10 +796,11 @@ Go to next child
 Child 3 successfully executing
 Spawned 3 child, pid 1975 
 Go to next child 
-[piccardi@selidor sources]$ Child 3, parent 1, exiting
+
+\textbf{[piccardi@selidor sources]$} Child 3, parent 1, exiting
 Child 2, parent 1, exiting
 Child 1, parent 1, exiting
-\end{Verbatim}
+\end{Terminal}
 come si può notare in questo caso il processo padre si conclude prima dei
 figli, tornando alla shell, che stampa il prompt sul terminale: circa due
 secondi dopo viene stampato a video anche l'output dei tre figli che
@@ -808,23 +815,27 @@ informazioni riguardo ai processi che sta terminando.
 Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
 memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
 dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
-mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
-processi che sono terminati, ma il cui stato di terminazione non è stato
-ancora ricevuto dal padre sono chiamati \index{zombie} \textit{zombie}, essi
+mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. 
+
+I processi che sono terminati, ma il cui stato di terminazione non è stato
+ancora ricevuto dal padre sono chiamati \itindex{zombie} \textit{zombie}, essi
 restano presenti nella tabella dei processi ed in genere possono essere
 identificati dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella
 colonna che ne indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando
-il padre effettuerà la lettura dello stato di uscita anche questa
-informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi
-completamente conclusa.
+il padre effettuerà la lettura dello stato di terminazione anche questa
+informazione, non più necessaria, verrà scartata ed il processo potrà
+considerarso completamente concluso.
 
 Possiamo utilizzare il nostro programma di prova per analizzare anche questa
 condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi
 sez.~\ref{sec:sess_job_control}), indicando al processo padre di aspettare 10
-secondi prima di uscire; in questo caso, usando \cmd{ps} sullo stesso
+secondi prima di uscire. In questo caso, usando \cmd{ps} sullo stesso
 terminale (prima dello scadere dei 10 secondi) otterremo:
-\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
+\begin{Command}
 [piccardi@selidor sources]$ ps T
+\end{Command}
+%$
+\begin{Terminal}
   PID TTY      STAT   TIME COMMAND
   419 pts/0    S      0:00 bash
   568 pts/0    S      0:00 ./forktest -e10 3
@@ -832,40 +843,44 @@ terminale (prima dello scadere dei 10 secondi) otterremo:
   570 pts/0    Z      0:00 [forktest <defunct>]
   571 pts/0    Z      0:00 [forktest <defunct>]
   572 pts/0    R      0:00 ps T
-\end{Verbatim} 
-%$
-e come si vede, dato che non si è fatto nulla per riceverne lo
-stato di terminazione, i tre processi figli sono ancora presenti pur essendosi
-conclusi, con lo stato di \index{zombie} \textit{zombie} e l'indicazione che
-sono stati terminati.
+\end{Terminal} 
+e come si vede, dato che non si è fatto nulla per riceverne lo stato di
+terminazione, i tre processi figli sono ancora presenti pur essendosi
+conclusi, con lo stato di \itindex{zombie} \textit{zombie} e l'indicazione che
+sono terminati (la scritta \texttt{defunct}).
 
-La possibilità di avere degli \index{zombie} \textit{zombie} deve essere
+La possibilità di avere degli \itindex{zombie} \textit{zombie} deve essere
 tenuta sempre presente quando si scrive un programma che deve essere mantenuto
 in esecuzione a lungo e creare molti figli. In questo caso si deve sempre
-avere cura di far leggere l'eventuale stato di uscita di tutti i figli (in
+avere cura di far leggere l'eventuale stato di uscita di tutti i figli. In
 genere questo si fa attraverso un apposito \textit{signal handler}, che chiama
-la funzione \func{wait}, vedi sez.~\ref{sec:sig_sigchld} e
-sez.~\ref{sec:proc_wait}).  Questa operazione è necessaria perché anche se gli
-\index{zombie} \textit{zombie} non consumano risorse di memoria o processore,
-occupano comunque una voce nella tabella dei processi, che a lungo andare
-potrebbe esaurirsi.
-
-Si noti che quando un processo adottato da \cmd{init} termina, esso non
-diviene uno \index{zombie} \textit{zombie}; questo perché una delle funzioni
-di \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i
-processi cui fa da padre, completandone la terminazione. Questo è quanto
-avviene anche quando, come nel caso del precedente esempio con \cmd{forktest},
-il padre termina con dei figli in stato di \index{zombie} \textit{zombie}:
-alla sua terminazione infatti tutti i suoi figli (compresi gli \index{zombie}
-\textit{zombie}) verranno adottati da \cmd{init}, il quale provvederà a
-completarne la terminazione.
-
-Si tenga presente infine che siccome gli \index{zombie} \textit{zombie} sono
-processi già usciti, non c'è modo di eliminarli con il comando \cmd{kill};
-l'unica possibilità di cancellarli dalla tabella dei processi è quella di
-terminare il processo che li ha generati, in modo che \cmd{init} possa
-adottarli e provvedere a concluderne la terminazione.
-
+la funzione \func{wait}, (vedi sez.~\ref{sec:sig_sigchld} e
+sez.~\ref{sec:proc_wait}) di cui vedremo un esempio in
+fig.~\ref{fig:sig_sigchld_handl}.  
+
+Questa operazione è necessaria perché anche se gli \itindex{zombie}
+\textit{zombie} non consumano risorse di memoria o processore, occupano
+comunque una voce nella tabella dei processi e se li si lascia accumulare a
+lungo quest'ultima potrebbe riempirsi, con l'impossibilità di lanciare nuovi
+processi. 
+
+Si noti tuttavia che quando un processo adottato da \cmd{init} termina, non
+diviene mai uno \itindex{zombie} \textit{zombie}. Questo perché una delle
+funzioni di \cmd{init} è appunto quella di chiamare la funzione \func{wait}
+per i processi a cui fa da padre, completandone la terminazione. Questo è
+quanto avviene anche quando, come nel caso del precedente esempio con
+\cmd{forktest}, il padre termina con dei figli in stato di \itindex{zombie}
+\textit{zombie}. Questi scompaiono quando, alla terminazione del padre dopo i
+secondi programmati, tutti figli che avevamo generato, e che erano diventati
+\itindex{zombie} \textit{zombie}, vengono adottati da \cmd{init}, il quale
+provvede a completarne la terminazione.
+
+Si tenga presente infine che siccome gli \itindex{zombie} \textit{zombie} sono
+processi già terminati, non c'è modo di eliminarli con il comando \cmd{kill} o
+inviandogli un qualunque segnale di terminazione (l'argomento è trattato in
+sez.~\ref{sec:sig_termination}). L'unica possibilità di cancellarli dalla
+tabella dei processi è quella di terminare il processo che li ha generati, in
+modo che \cmd{init} possa adottarli e concluderne la terminazione.
 
 \subsection{Le funzioni di attesa e ricezione degli stati di uscita}
 \label{sec:proc_wait}
@@ -873,47 +888,56 @@ adottarli e provvedere a concluderne la terminazione.
 Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
 consiste nella creazione di programmi di tipo server, in cui un processo
 principale attende le richieste che vengono poi soddisfatte da una serie di
-processi figli. Si è già sottolineato al paragrafo precedente come in questo
-caso diventi necessario gestire esplicitamente la conclusione dei figli onde
-evitare di riempire di \index{zombie} \textit{zombie} la tabella dei processi;
-le funzioni deputate a questo compito sono principalmente due, la prima è
-\funcd{wait} ed il suo prototipo è:
-\begin{functions}
-\headdecl{sys/types.h}
-\headdecl{sys/wait.h}
-\funcdecl{pid\_t wait(int *status)} 
-
-Sospende il processo corrente finché un figlio non è uscito, o finché un
-segnale termina il processo o chiama una funzione di gestione. 
-
-\bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
-  e -1 in caso di errore; \var{errno} può assumere i valori:
+processi figli. 
+
+Si è già sottolineato al paragrafo precedente come in questo caso diventi
+necessario gestire esplicitamente la conclusione dei figli onde evitare di
+riempire di \itindex{zombie} \textit{zombie} la tabella dei
+processi. Tratteremo in questa sezione le funzioni deputate a questo compito;
+la prima è \funcd{wait} ed il suo prototipo è:
+
+\begin{funcproto}{ 
+\fhead{sys/types.h}
+\fhead{sys/wait.h}
+\fdecl{pid\_t wait(int *status)}
+\fdesc{Attende la terminazione di un processo.} 
+}
+{La funzione ritorna il \acr{pid} del figlio in caso di successo e $-1$ per un
+  errore, nel qual caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
+  \item[\errcode{ECHILD}] il processo non ha nessun figlio di cui attendere
+    uno stato di terminazione.
   \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
   \end{errlist}}
-\end{functions}
-\noindent
+\end{funcproto}
 
-Questa funzione è presente fin dalle prime versioni di Unix; essa ritorna non
-appena un qualunque processo figlio termina. Se un figlio è già terminato
-prima della chiamata la funzione ritorna immediatamente, se più di un figlio è
-già terminato occorre continuare chiamare la funzione più volte se si vuole
-recuperare lo stato di terminazione di tutti quanti.
+Questa funzione è presente fin dalle prime versioni di Unix ed è quella usata
+tradizionalmente per attendere la terminazione dei figli. La funzione sospende
+l'esecuzione del processo corrente e ritorna non appena un qualunque processo
+figlio termina. Se un figlio è già terminato prima della sua chiamata la
+funzione ritorna immediatamente, se più processi figli sono già terminati
+occorrerà continuare a chiamare la funzione più volte fintanto che non si è
+recuperato lo stato di terminazione di tutti quanti.
 
 Al ritorno della funzione lo stato di terminazione del figlio viene salvato
-nella variabile puntata da \param{status} e tutte le risorse del kernel
-relative al processo (vedi sez.~\ref{sec:proc_termination}) vengono
-rilasciate.  Nel caso un processo abbia più figli il valore di ritorno della
-funzione sarà impostato al \acr{pid} del processo di cui si è ricevuto lo
-stato di terminazione, cosa che permette di identificare qual è il figlio che
-è terminato.
+(come \itindex{value~result~argument} \textit{value result argument}) nella
+variabile puntata da \param{status} e tutte le risorse del kernel relative al
+processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate.  Nel caso
+un processo abbia più figli il valore di ritorno della funzione sarà impostato
+al \acr{pid} del processo di cui si è ricevuto lo stato di terminazione, cosa
+che permette di identificare qual è il figlio che è terminato.
+
+\itindend{termination~status} 
 
 Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
 all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
-necessario attendere la conclusione di un processo specifico occorrerebbe
-predisporre un meccanismo che tenga conto dei processi già terminati, e
-provvedere a ripetere la chiamata alla funzione nel caso il processo cercato
-sia ancora attivo.
+necessario attendere la conclusione di uno specifico processo fra tutti quelli
+esistenti occorre predisporre un meccanismo che tenga conto di tutti processi
+che sono terminati, e provveda a ripetere la chiamata alla funzione nel caso
+il processo cercato non risulti fra questi. Se infatti il processo cercato è
+già terminato e se è già ricevuto lo stato di uscita senza registrarlo, la
+funzione non ha modo di accorgersene, e si continuerà a chiamarla senza
+accorgersi che quanto interessava è già accaduto.
 
 Per questo motivo lo standard POSIX.1 ha introdotto una seconda funzione che
 effettua lo stesso servizio, ma dispone di una serie di funzionalità più
@@ -923,15 +947,17 @@ comportamento di \func{wait}\footnote{in effetti il codice
   \code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
     \&status, 0)}.} si consiglia di utilizzare sempre questa nuova funzione,
 \funcd{waitpid}, il cui prototipo è:
-\begin{functions}
-\headdecl{sys/types.h}
-\headdecl{sys/wait.h}
-\funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)} 
-Attende la conclusione di un processo figlio.
 
-\bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
-  è stata specificata l'opzione \const{WNOHANG} e il processo non è uscito e
-  -1 per un errore, nel qual caso \var{errno} assumerà i valori:
+\begin{funcproto}{ 
+\fhead{sys/types.h}
+\fhead{sys/wait.h}
+\fdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
+\fdesc{Attende il cambiamento di stato di un processo figlio.} 
+}
+{La funzione ritorna il \acr{pid} del processo che ha cambiato stato in caso
+  di successo, o 0 se è stata specificata l'opzione \const{WNOHANG} e il
+  processo non è uscito e $-1$ per un errore, nel qual caso \var{errno}
+  assumerà uno dei valori:
   \begin{errlist}
   \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
     la funzione è stata interrotta da un segnale.
@@ -940,7 +966,7 @@ Attende la conclusione di un processo figlio.
   \item[\errcode{EINVAL}] si è specificato un valore non valido per
     l'argomento \param{options}.
   \end{errlist}}
-\end{functions}
+\end{funcproto}
 
 La prima differenza fra le due funzioni è che con \func{waitpid} si può
 specificare in maniera flessibile quale processo attendere, sulla base del
@@ -978,21 +1004,21 @@ sono riportate anche le costanti definite per indicare alcuni di essi.
 
 Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
 funzione delle opportune opzioni tramite l'argomento \param{options}; questo
-deve essere specificato come maschera binaria dei flag riportati nella prima
-parte in tab.~\ref{tab:proc_waitpid_options} che possono essere combinati fra
-loro con un OR aritmetico. Nella seconda parte della stessa tabella si sono
-riportati anche alcuni valori non standard specifici di Linux, che consentono
-un controllo più dettagliato per i processi creati con la \textit{system call}
-generica \func{clone} (vedi sez.~\ref{sec:process_clone}) usati principalmente
-per la gestione della terminazione dei \itindex{thread} \textit{thread} (vedi
-sez.~\ref{sec:thread_xxx}).
+deve essere specificato come maschera binaria delle costanti riportati nella
+prima parte in tab.~\ref{tab:proc_waitpid_options} che possono essere
+combinate fra loro con un OR aritmetico. Nella seconda parte della stessa
+tabella si sono riportati anche alcuni valori non standard specifici di Linux,
+che consentono un controllo più dettagliato per i processi creati con la
+\textit{system call} generica \func{clone} (vedi sez.~\ref{sec:process_clone})
+usati principalmente per la gestione della terminazione dei \itindex{thread}
+\textit{thread} (vedi sez.~\ref{sec:thread_xxx}).
 
 \begin{table}[!htb]
   \centering
   \footnotesize
   \begin{tabular}[c]{|l|p{8cm}|}
     \hline
-    \textbf{Macro} & \textbf{Descrizione}\\
+    \textbf{Valore} & \textbf{Descrizione}\\
     \hline
     \hline
     \const{WNOHANG}   & La funzione ritorna immediatamente anche se non è
@@ -1130,7 +1156,7 @@ attendono la terminazione di un processo figlio e ritornano il relativo
 In generale in un programma non si vuole essere forzati ad attendere la
 conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
 questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente
-la presenza di \index{zombie} \textit{zombie}). 
+la presenza di \itindex{zombie} \textit{zombie}). 
 
 Per questo la modalità più comune di chiamare queste funzioni è quella di
 utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
@@ -1168,27 +1194,24 @@ stata introdotta una nuova funzione di attesa che consente di avere un
 controllo molto più preciso sui possibili cambiamenti di stato dei processi
 figli e più dettagli sullo stato di uscita; la funzione è \funcd{waitid} ed il
 suo prototipo è:
-\begin{functions}
-  \headdecl{sys/types.h} 
-
-  \headdecl{sys/wait.h}
-  
-  \funcdecl{int waitid(idtype\_t idtype, id\_t id, siginfo\_t *infop, int
-    options)}    
 
-  Attende la conclusione di un processo figlio.
-
-  \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore,
-    nel qual caso \var{errno} assumerà i valori:
+\begin{funcproto}{ 
+\fhead{sys/types.h}
+\fhead{sys/wait.h}
+\fdecl{int waitid(idtype\_t idtype, id\_t id, siginfo\_t *infop, int options)}
+\fdesc{Attende il cambiamento di stato di un processo figlio.} 
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+  caso \var{errno} assumerà uno dei valori:
   \begin{errlist}
-  \item[\errcode{EINTR}] se non è stata specificata l'opzione \const{WNOHANG} e
+  \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
     la funzione è stata interrotta da un segnale.
   \item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
     non è figlio del processo chiamante.
   \item[\errcode{EINVAL}] si è specificato un valore non valido per
     l'argomento \param{options}.
   \end{errlist}}
-\end{functions}
+\end{funcproto}
 
 La funzione prevede che si specifichi quali processi si intendono osservare
 usando i due argomenti \param{idtype} ed \param{id}; il primo indica se ci si
@@ -1202,7 +1225,7 @@ primo, quale processo o quale gruppo di processi selezionare.
   \footnotesize
   \begin{tabular}[c]{|l|p{8cm}|}
     \hline
-    \textbf{Macro} & \textbf{Descrizione}\\
+    \textbf{Valore} & \textbf{Descrizione}\\
     \hline
     \hline
     \const{P\_PID} & Indica la richiesta di attendere per un processo figlio
@@ -1239,7 +1262,7 @@ nuovo riceverne lo stato.
   \footnotesize
   \begin{tabular}[c]{|l|p{8cm}|}
     \hline
-    \textbf{Macro} & \textbf{Descrizione}\\
+    \textbf{Valore} & \textbf{Descrizione}\\
     \hline
     \hline
     \const{WEXITED}   & Ritorna quando un processo figlio è terminato.\\
@@ -1294,6 +1317,21 @@ kernel può restituire al padre informazioni sulle risorse (vedi
 sez.~\ref{sec:sys_res_limits}) usate dal processo terminato e dai vari figli.
 Le due funzioni sono \funcd{wait3} e \funcd{wait4}, che diventano accessibili
 definendo la macro \macro{\_USE\_BSD}; i loro prototipi sono:
+
+\begin{funcproto}{ 
+\fhead{sys/types.h}
+\fhead{sys/times.h}
+\fhead{sys/resource.h}
+\fhead{sys/wait.h}
+\fdecl{int wait4(pid\_t pid, int *status, int options, struct rusage *rusage))}
+\fdesc{Attende il cambiamento di stato di un processo figlio, riportando l'uso
+  delle risorsr.} 
+}
+{La funzione ha gli stessi valori di ritorno e codici di errore di
+  \func{waitpid}. }
+\end{funcproto}
+
+
 \begin{functions}
   \headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
   \headdecl{sys/resource.h} 
@@ -1314,6 +1352,7 @@ utilizzata anche dalla funzione \func{getrusage} (vedi
 sez.~\ref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
 processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
 
+
 \subsection{La funzione \func{exec} e le funzioni di esecuzione dei programmi}
 \label{sec:proc_exec}
 
@@ -2237,7 +2276,7 @@ kernel provvedere a mettere in esecuzione un altro processo.
 Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
 processo, in Linux un processo può trovarsi in uno degli stati riportati in
 tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
-\textbf{Runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
+\textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
 sia la sua priorità, un processo non potrà mai essere messo in esecuzione
 fintanto che esso si trova in uno qualunque degli altri stati.
 
@@ -2249,24 +2288,24 @@ fintanto che esso si trova in uno qualunque degli altri stati.
     \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
     \hline
     \hline
-    \textbf{Runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
+    \textit{runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
                                     essere eseguito (cioè è in attesa che gli
                                     venga assegnata la CPU).\\
-    \textbf{Sleep}   & \texttt{S} & Il processo  è in attesa di un
+    \textit{sleep}   & \texttt{S} & Il processo  è in attesa di un
                                     risposta dal sistema, ma può essere 
                                     interrotto da un segnale.\\
-    \textbf{Uninterrutible Sleep}& \texttt{D} & Il  processo è in
+    \textit{uninterrutible sleep}& \texttt{D} & Il  processo è in
                                     attesa di un risposta dal sistema (in 
                                     genere per I/O), e non può essere
                                     interrotto in nessuna circostanza.\\
-    \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
+    \textit{stopped} & \texttt{T} & Il processo è stato fermato con un
                                     \signal{SIGSTOP}, o è tracciato.\\
-    \textbf{Zombie}\index{zombie} & \texttt{Z} & Il processo è terminato ma il
+    \textit{zombie}\itindex{zombie}& \texttt{Z} & Il processo è terminato ma il
                                     suo stato di terminazione non è ancora
                                     stato letto dal padre.\\
-    \textbf{Killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
+    \textit{killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
                                     2.6.25, sostanzialmente identico
-                                    all'\textbf{Uninterrutible Sleep} con la
+                                    all'\textit{uninterrutible sleep} con la
                                     sola differenza che il processo può
                                     terminato con \signal{SIGKILL} (usato per
                                     lo più per NFS).\\ 
@@ -2418,24 +2457,25 @@ partire da questa versione è consentito anche agli utenti normali alzare
 (entro certi limiti, che vedremo più avanti) la priorità dei propri processi.
 
 Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
-di \var{nice} del processo; tuttavia la system call di Linux non segue questa
-convenzione e restituisce sempre 0 in caso di successo e $-1$ in caso di
-errore; questo perché $-1$ è un valore di \var{nice} legittimo e questo
-comporta una confusione con una eventuale condizione di errore. La system call
-originaria inoltre non consente, se non dotati di adeguati privilegi, di
-diminuire un valore di \var{nice} precedentemente innalzato.
+di \var{nice} del processo; tuttavia la \textit{system call} di Linux non
+segue questa convenzione e restituisce sempre 0 in caso di successo e $-1$ in
+caso di errore; questo perché $-1$ è un valore di \var{nice} legittimo e
+questo comporta una confusione con una eventuale condizione di errore. La
+\textit{system call} originaria inoltre non consente, se non dotati di
+adeguati privilegi, di diminuire un valore di \var{nice} precedentemente
+innalzato.
  
 Fino alle \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
-risultato dalla system call, violando lo standard, per cui per ottenere il
-nuovo valore occorreva una successiva chiamata alla funzione
+risultato dalla \textit{system call}, violando lo standard, per cui per
+ottenere il nuovo valore occorreva una successiva chiamata alla funzione
 \func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
-reimplementata e non viene più chiamata la omonima system call, con questa
-versione viene restituito come valore di ritorno il valore di \var{nice}, come
-richiesto dallo standard.\footnote{questo viene fatto chiamando al suo interno
-  \func{setpriority}, che tratteremo a breve.}  In questo caso l'unico modo
-per rilevare in maniera affidabile una condizione di errore è quello di
-azzerare \var{errno} prima della chiamata della funzione e verificarne il
-valore quando \func{nice} restituisce $-1$.
+reimplementata e non viene più chiamata la omonima \textit{system call}, con
+questa versione viene restituito come valore di ritorno il valore di
+\var{nice}, come richiesto dallo standard.\footnote{questo viene fatto
+  chiamando al suo interno \func{setpriority}, che tratteremo a breve.}  In
+questo caso l'unico modo per rilevare in maniera affidabile una condizione di
+errore è quello di azzerare \var{errno} prima della chiamata della funzione e
+verificarne il valore quando \func{nice} restituisce $-1$.
 
 Per leggere il valore di \textit{nice} di un processo occorre usare la
 funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è:
@@ -2835,7 +2875,7 @@ il suo prototipo è:
     nel qual caso \var{errno} può assumere i valori:
     \begin{errlist}
     \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
-    \item[\errcode{ENOSYS}] la system call non è stata implementata.
+    \item[\errcode{ENOSYS}] la \textit{system call} non è stata implementata.
   \end{errlist}}
 \end{prototype}
 
@@ -2930,12 +2970,12 @@ sempre eseguito dallo stesso processore,\footnote{quella che viene detta
   \textit{hard CPU affinity}, in contrasto con quella fornita dallo scheduler,
   detta \textit{soft CPU affinity}, che di norma indica solo una preferenza,
   non un requisito assoluto.} e per poter risolvere questo tipo di
-problematiche nei nuovi kernel\footnote{le due system call per la gestione
-  della \textit{CPU affinity} sono state introdotte nel kernel 2.5.8, e le
-  funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
-l'opportuna infrastruttura ed una nuova system call che permette di impostare
-su quali processori far eseguire un determinato processo attraverso una
-\textsl{maschera di affinità}. La corrispondente funzione di libreria è
+problematiche nei nuovi kernel\footnote{le due \textit{system call} per la
+  gestione della \textit{CPU affinity} sono state introdotte nel kernel 2.5.8,
+  e le funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
+l'opportuna infrastruttura ed una nuova \textit{system call} che permette di
+impostare su quali processori far eseguire un determinato processo attraverso
+una \textsl{maschera di affinità}. La corrispondente funzione di libreria è
 \funcd{sched\_setaffinity} ed il suo prototipo è:
 \begin{prototype}{sched.h}
   {int sched\_setaffinity (pid\_t pid, unsigned int cpusetsize, const
@@ -2956,9 +2996,9 @@ su quali processori far eseguire un determinato processo attraverso una
 
 
 Questa funzione e la corrispondente \func{sched\_setaffinity} hanno una storia
-abbastanza complessa, la system call prevede l'uso di due ulteriori argomenti
-di tipo \texttt{unsigned int len} e \texttt{unsigned long *mask}, che
-corrispondono al fatto che la implementazione effettiva usa una semplice
+abbastanza complessa, la \textit{system call} prevede l'uso di due ulteriori
+argomenti di tipo \texttt{unsigned int len} e \texttt{unsigned long *mask},
+che corrispondono al fatto che la implementazione effettiva usa una semplice
 maschera binaria. Quando le funzioni vennero incluse nelle \acr{glibc}
 assunsero invece il prototipo appena mostrato. A complicare la cosa si
 aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} l'argomento
@@ -3292,7 +3332,7 @@ spesso presuppongono la conoscenza di altri argomenti trattati nel seguito
 della guida, si può saltare questa sezione in una prima lettura, tornando su
 di essa in un secondo tempo.
 
-\subsection{La system call \func{clone}}
+\subsection{La \textit{system call} \func{clone}}
 \label{sec:process_clone}
 
 La funzione tradizionale con cui creare un nuovo processo in un sistema
@@ -3522,14 +3562,14 @@ predefinite del seguente elenco, che illustra quelle disponibili al momento:
   lo stato corrente del flag che controlla la effettiva generazione dei
   \itindex{core~dump} \textit{core dump}. Introdotta a partire dal kernel
   2.3.20.
-\item[\const{PR\_SET\_ENDIAN}] Imposta la \textit{endianess} del processo
+\item[\const{PR\_SET\_ENDIAN}] Imposta la \textit{endianness} del processo
   chiamante secondo il valore fornito in \param{arg2}. I valori possibili sono
   sono: \const{PR\_ENDIAN\_BIG} (\textit{big endian}),
   \const{PR\_ENDIAN\_LITTLE} (\textit{little endian}), e
   \const{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
   PowerPC). Introdotta a partire dal kernel 2.6.18, solo per architettura
   PowerPC.
-\item[\const{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianess} del
+\item[\const{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianness} del
   processo chiamante, salvato sulla variabile puntata da \param{arg2} che deve
   essere passata come di tipo \ctyp{(int *)}. Introdotta a partire dal kernel
   2.6.18, solo su PowerPC.
@@ -3781,13 +3821,13 @@ fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
 cap.~\ref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
 sez.~\ref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
 funzioni di libreria per compiere le operazioni necessarie è garanzia
-sufficiente di atomicità in quanto le system call con cui esse sono realizzate
-non possono essere interrotte (o subire interferenze pericolose) da altri
-processi.
+sufficiente di atomicità in quanto le \textit{system call} con cui esse sono
+realizzate non possono essere interrotte (o subire interferenze pericolose) da
+altri processi.
 
 Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
-stesso processo, e pure alcune system call, possono essere interrotti in
-qualunque momento, e le operazioni di un eventuale \textit{signal handler}
+stesso processo, e pure alcune \textit{system call}, possono essere interrotti
+in qualunque momento, e le operazioni di un eventuale \textit{signal handler}
 sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
 il solo accesso o l'assegnazione di una variabile possono non essere più
 operazioni atomiche (torneremo su questi aspetti in
@@ -3955,13 +3995,15 @@ aggiungendo il suffisso \code{\_r} al nome della versione normale.
 % LocalWords:  SIGKILL static RLIMIT preemption PREEMPT VOLUNTARY IDLE RTPRIO
 % LocalWords:  completely fair compat uniform CFQ queuing elevator dev cfq RT
 % LocalWords:  documentation block syscall ioprio IPRIO CLASS class best effort
-% LocalWords:  refresh semop dnotify MADV DONTFORK prctl WCLONE WALL big
-% LocalWords:  WNOTHREAD DUMPABLE KEEPCAPS IRIX CAPBSET endianess endian flags
+% LocalWords:  refresh semop dnotify MADV DONTFORK prctl WCLONE WALL big mount
+% LocalWords:  WNOTHREAD DUMPABLE KEEPCAPS IRIX CAPBSET endianness endian flags
 % LocalWords:  little PPC PowerPC FPEMU NOPRINT SIGFPE FPEXC point FP SW malloc
 % LocalWords:  exception EXC ENABLE OVF overflow UND underflow RES INV DISABLED
-% LocalWords:  NONRECOV ASYNC KEEP securebits NAME NUL PDEATHSIG SECCOMP VM
+% LocalWords:  NONRECOV ASYNC KEEP securebits NAME NUL PDEATHSIG SECCOMP VM FS
 % LocalWords:  secure computing sigreturn TIMING STATISTICAL TSC MCE conditions
 % LocalWords:  timestamp Stamp SIGSEGV UNALIGN SIGBUS MCEERR AO failure early
+% LocalWords:  namespace vsyscall SETTID FILES NEWIPC NEWNET NEWNS NEWPID ptid
+% LocalWords:  NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID
  
 %%% Local Variables: 
 %%% mode: latex
index b4e869f818714f40360ff416284cad7b27ca10e0..302b5e35f7031e15ecd249fa5593730e2000c223 100644 (file)
@@ -806,14 +806,15 @@ gestore; viene mantenuto invece ogni eventuale impostazione dell'azione a
 programmi eseguiti in background, che altrimenti sarebbero interrotti da una
 successiva pressione di \texttt{C-c} o \texttt{C-y}.
 
-Per quanto riguarda il comportamento di tutte le altre system call si danno
-sostanzialmente due casi, a seconda che esse siano \index{system~call~lente}
-\textsl{lente} (\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran
-parte di esse appartiene a quest'ultima categoria, che non è influenzata
-dall'arrivo di un segnale. Esse sono dette \textsl{veloci} in quanto la loro
-esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre
-data dopo che la system call è stata completata, in quanto attendere per
-eseguire un gestore non comporta nessun inconveniente.
+Per quanto riguarda il comportamento di tutte le altre \textit{system call} si
+danno sostanzialmente due casi, a seconda che esse siano
+\index{system~call~lente} \textsl{lente} (\textit{slow}) o \textsl{veloci}
+(\textit{fast}). La gran parte di esse appartiene a quest'ultima categoria,
+che non è influenzata dall'arrivo di un segnale. Esse sono dette
+\textsl{veloci} in quanto la loro esecuzione è sostanzialmente immediata; la
+risposta al segnale viene sempre data dopo che la \textit{system call} è stata
+completata, in quanto attendere per eseguire un gestore non comporta nessun
+inconveniente.
 
 In alcuni casi però alcune system call (che per questo motivo vengono chiamate
 \textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
@@ -1438,24 +1439,25 @@ conclusione di un processo è quella di inviare questo segnale al
 padre.\footnote{in realtà in SVr4 eredita la semantica di System V, in cui il
   segnale si chiama \signal{SIGCLD} e viene trattato in maniera speciale; in
   System V infatti se si imposta esplicitamente l'azione a \const{SIG\_IGN} il
-  segnale non viene generato ed il sistema non genera \index{zombie} zombie
-  (lo stato di terminazione viene scartato senza dover chiamare una
-  \func{wait}).  L'azione predefinita è sempre quella di ignorare il segnale,
-  ma non attiva questo comportamento. Linux, come BSD e POSIX, non supporta
-  questa semantica ed usa il nome di \signal{SIGCLD} come sinonimo di
+  segnale non viene generato ed il sistema non genera \itindex{zombie}
+  \textit{zombie} (lo stato di terminazione viene scartato senza dover
+  chiamare una \func{wait}).  L'azione predefinita è sempre quella di ignorare
+  il segnale, ma non attiva questo comportamento. Linux, come BSD e POSIX, non
+  supporta questa semantica ed usa il nome di \signal{SIGCLD} come sinonimo di
   \signal{SIGCHLD}.} In generale dunque, quando non interessa elaborare lo
 stato di uscita di un processo, si può completare la gestione della
 terminazione installando un gestore per \signal{SIGCHLD} il cui unico compito
 sia quello di chiamare \func{waitpid} per completare la procedura di
-terminazione in modo da evitare la formazione di \index{zombie} zombie.
+terminazione in modo da evitare la formazione di \itindex{zombie}
+\textit{zombie}.
 
 In fig.~\ref{fig:sig_sigchld_handl} è mostrato il codice contenente una
-implementazione generica di una funzione di gestione per \signal{SIGCHLD}, (che
-si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i test
-di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione
-\cmd{-s} (che si limita ad effettuare l'installazione di questa funzione come
-gestore di \signal{SIGCHLD}) potremo verificare che non si ha più la creazione
-di \index{zombie} zombie.
+implementazione generica di una funzione di gestione per \signal{SIGCHLD},
+(che si trova nei sorgenti allegati nel file \file{SigHand.c}); se ripetiamo i
+test di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con
+l'opzione \cmd{-s} (che si limita ad effettuare l'installazione di questa
+funzione come gestore di \signal{SIGCHLD}) potremo verificare che non si ha
+più la creazione di \itindex{zombie} \textit{zombie}.
 
 \begin{figure}[!htbp]
   \footnotesize  \centering
@@ -1495,7 +1497,8 @@ rimosso verrà recapitato un solo segnale.
 Allora, nel caso della terminazione dei processi figli, se si chiamasse
 \func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un
 solo processo, anche se i processi terminati sono più di uno, e gli altri
-resterebbero in stato di \index{zombie} zombie per un tempo indefinito.
+resterebbero in stato di \itindex{zombie} \textit{zombie} per un tempo
+indefinito.
 
 Per questo occorre ripetere la chiamata di \func{waitpid} fino a che essa non
 ritorni un valore nullo, segno che non resta nessun processo di cui si debba
@@ -1814,8 +1817,8 @@ tab.~\ref{tab:sig_sa_flag}.
                            \var{sa\_sigaction} al posto di
                            \var{sa\_handler}.\\
     \const{SA\_NOCLDWAIT}& Se il segnale è \signal{SIGCHLD} allora i processi
-                           figli non diventano \textit{zombie} quando
-                           terminano.\footnotemark \\ 
+                           figli non diventano \itindex{zombie}
+                           \textit{zombie} quando terminano.\footnotemark \\ 
     \hline
   \end{tabular}
   \caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
index 29df12ba216f41c4858017ee92d21703f07c280d..7d946bb65745dc527c5aaed646abf9d5cfe0dd30 100644 (file)
@@ -1752,7 +1752,7 @@ valore del relativo puntatore precedentemente (\texttt{\small 17}) salvato.
 Si noti come per la funzione sia del tutto irrilevante se la struttura
 ritornata contiene indirizzi IPv6 o IPv4, in quanto si fa uso direttamente dei
 dati relativi alle strutture degli indirizzi di \struct{addrinfo} che sono
-\textsl{opachi} rispetto all'uso della funzione \func{connect}.
+\index{tipo!opaco} opachi rispetto all'uso della funzione \func{connect}.
 
 \begin{figure}[!htbp]
   \footnotesize \centering
index 0066ed314a02af2fa4e1e7ad393fbfcedb7df84d..88029d662a01ea8828f051adfc1fb3967f1ea10f 100644 (file)
@@ -489,7 +489,7 @@ tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti.
 Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
 essere specificati in quello che viene chiamato \textit{network order}, cioè
 con i bit ordinati in formato \textit{big endian} (vedi
-sez.~\ref{sec:sock_endianess}), questo comporta la necessità di usare apposite
+sez.~\ref{sec:sock_endianness}), questo comporta la necessità di usare apposite
 funzioni di conversione per mantenere la portabilità del codice (vedi
 sez.~\ref{sec:sock_addr_func} per i dettagli del problema e le relative
 soluzioni).
@@ -604,7 +604,7 @@ inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
 usati solo da processi con i privilegi di amministratore o con la
 \itindex{capabilities} \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}.
 L'indirizzo remoto è specificato nella struttura \var{sat\_addr}, e deve
-essere in \textit{network order} (vedi sez.~\ref{sec:sock_endianess}); esso è
+essere in \textit{network order} (vedi sez.~\ref{sec:sock_endianness}); esso è
 composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
 valore \const{AT\_ANYNET}, che indica una rete generica e vale anche per
 indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
@@ -752,8 +752,8 @@ può comportare la necessità di eseguire delle conversioni.
 \subsection{Le funzioni per il riordinamento}
 \label{sec:sock_func_ord}
 
-Come già visto in sez.~\ref{sec:sock_endianess} il problema connesso
-\itindex{endianess} all'\textit{endianess} è che quando si passano dei dati da
+Come già visto in sez.~\ref{sec:sock_endianness} il problema connesso
+\itindex{endianness} all'\textit{endianness} è che quando si passano dei dati da
 un tipo di architettura all'altra i dati vengono interpretati in maniera
 diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà con i due
 byte in cui è suddiviso scambiati di posto.  Per questo motivo si usano delle
@@ -944,9 +944,9 @@ sez.~\ref{sec:IP_ipv6_notation} per IPv6.
 % LocalWords:  pathname AppleTalk netatalk personal Apple ATPROTO atalk sat if
 % LocalWords:  ANYNET node ANYNODE ATADDR BCAST pcap IEEE linux ether ETH ALL
 % LocalWords:  sll ifindex ethernet halen MAC hatype ARP arp pkttype HOST recv
-% LocalWords:  OTHERHOST OUTGOING recvfrom recvmsg endianess little endtest Mac
+% LocalWords:  OTHERHOST OUTGOING recvfrom recvmsg endianness little endtest Mac
 % LocalWords:  Intel Digital Motorola IBM VME PowerPC l'Intel xABCD ptr htonl
-% LocalWords:  all'endianess htons ntohl ntohs long hostlong hostshort netlong
+% LocalWords:  htons ntohl ntohs long hostlong hostshort netlong
 % LocalWords:  sort netshort host inet aton ntoa dotted decimal const char src
 % LocalWords:  strptr struct dest addrptr INADDR NULL pton ntop presentation af
 % LocalWords:  numeric EAFNOSUPPORT size ENOSPC ENOAFSUPPORT ADDRSTRLEN ROUTE
index 695603e744b7bb9b3f4dc81aca2098b5acd431d6..d92e6d882173e8008cd3553d856579df4c59cfc0 100644 (file)
@@ -731,7 +731,7 @@ Si noti che si è usato \func{htonl} per assegnare il valore
 \const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
 inutile.  Si tenga presente comunque che tutte le costanti \val{INADDR\_}
 (riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo
-\itindex{endianess} l'\textit{endianess} della macchina, ed anche se esse
+\itindex{endianness} l'\textit{endianness} della macchina, ed anche se esse
 possono essere invarianti rispetto all'ordinamento dei bit, è comunque buona
 norma usare sempre la funzione \func{htonl}.
 
@@ -1537,8 +1537,8 @@ quello in questione, non è opportuno bloccare un server nel servizio di un
 client per volta; per questo si ricorre alle capacità di multitasking del
 sistema.
 
-Come accennato anche in sez.~\ref{sec:proc_gen} una delle modalità più comuni
-di funzionamento da parte dei server è quella di usare la funzione \func{fork}
+Come spiegato in sez.~\ref{sec:proc_fork} una delle modalità più comuni di
+funzionamento da parte dei server è quella di usare la funzione \func{fork}
 per creare, ad ogni richiesta da parte di un client, un processo figlio che si
 incarichi della gestione della comunicazione.  Si è allora riscritto il server
 \textit{daytime} dell'esempio precedente in forma concorrente, inserendo anche
@@ -2010,7 +2010,7 @@ quando affronteremo il comportamento in caso di conclusioni anomale:
   restituendo un puntatore nullo che causa l'uscita dal ciclo di \code{while},
   così la funzione \code{ClientEcho} ritorna.
 \item al ritorno di \code{ClientEcho} ritorna anche la funzione \code{main}, e
-  come parte del processo terminazione tutti i file descriptor vengono chiusi
+  come parte del processo di terminazione tutti i file descriptor vengono chiusi
   (si ricordi quanto detto in sez.~\ref{sec:proc_term_conclusion}); questo
   causa la chiusura del socket di comunicazione; il client allora invierà un
   FIN al server a cui questo risponderà con un ACK.  A questo punto il client
@@ -2038,19 +2038,19 @@ esaminato in sez.~\ref{sec:proc_termination}). In questo caso avremo l'invio
 del segnale \signal{SIGCHLD} al padre, ma dato che non si è installato un
 gestore e che l'azione predefinita per questo segnale è quella di essere
 ignorato, non avendo predisposto la ricezione dello stato di terminazione,
-otterremo che il processo figlio entrerà nello stato di \index{zombie} zombie
-(si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}), come risulterà
-ripetendo il comando \cmd{ps}:
+otterremo che il processo figlio entrerà nello stato di \itindex{zombie}
+\textit{zombie} (si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}),
+come risulterà ripetendo il comando \cmd{ps}:
 \begin{verbatim}
  2356 pts/0    S      0:00 ./echod
  2359 pts/0    Z      0:00 [echod <defunct>]
 \end{verbatim}
 
-Dato che non è il caso di lasciare processi \index{zombie} zombie, occorrerà
-ricevere opportunamente lo stato di terminazione del processo (si veda
-sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \signal{SIGCHLD} secondo
-quanto illustrato in sez.~\ref{sec:sig_sigchld}. Una prima modifica al nostro
-server è pertanto quella di inserire la gestione della terminazione dei
+Dato che non è il caso di lasciare processi \itindex{zombie} \textit{zombie},
+occorrerà ricevere opportunamente lo stato di terminazione del processo (si
+veda sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \signal{SIGCHLD}
+secondo quanto illustrato in sez.~\ref{sec:sig_sigchld}. Una prima modifica al
+nostro server è pertanto quella di inserire la gestione della terminazione dei
 processi figli attraverso l'uso di un gestore.  Per questo useremo la funzione
 \code{Signal} (che abbiamo illustrato in fig.~\ref{fig:sig_Signal_code}), per
 installare il gestore che riceve i segnali dei processi figli terminati già
@@ -2069,13 +2069,13 @@ di \errcode{EINTR}.
 
 Vediamo allora cosa comporta tutto questo nel nostro caso: quando si chiude il
 client, il processo figlio che gestisce la connessione terminerà, ed il padre,
-per evitare la creazione di zombie, riceverà il segnale \signal{SIGCHLD}
-eseguendo il relativo gestore. Al ritorno del gestore però l'esecuzione nel
-padre ripartirà subito con il ritorno della funzione \func{accept} (a meno di
-un caso fortuito in cui il segnale arriva durante l'esecuzione del programma
-in risposta ad una connessione) con un errore di \errcode{EINTR}. Non avendo
-previsto questa eventualità il programma considera questo un errore fatale
-terminando a sua volta con un messaggio del tipo:
+per evitare la creazione di \itindex{zombie} \textit{zombie}, riceverà il
+segnale \signal{SIGCHLD} eseguendo il relativo gestore. Al ritorno del gestore
+però l'esecuzione nel padre ripartirà subito con il ritorno della funzione
+\func{accept} (a meno di un caso fortuito in cui il segnale arriva durante
+l'esecuzione del programma in risposta ad una connessione) con un errore di
+\errcode{EINTR}. Non avendo previsto questa eventualità il programma considera
+questo un errore fatale terminando a sua volta con un messaggio del tipo:
 \begin{verbatim}
 [root@gont sources]# ./echod -i
 accept error: Interrupted system call
@@ -3073,23 +3073,23 @@ vuole operare e come secondo argomento un valore intero \param{how} che indica
 la modalità di chiusura del socket, quest'ultima può prendere soltanto tre
 valori: 
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\macro{SHUT\_RD}] chiude il lato in lettura del socket, non sarà più
+\item[\const{SHUT\_RD}] chiude il lato in lettura del socket, non sarà più
   possibile leggere dati da esso, tutti gli eventuali dati trasmessi
   dall'altro capo del socket saranno automaticamente scartati dal kernel, che,
   in caso di socket TCP, provvederà comunque ad inviare i relativi segmenti di
   ACK.
-\item[\macro{SHUT\_WR}] chiude il lato in scrittura del socket, non sarà più
+\item[\const{SHUT\_WR}] chiude il lato in scrittura del socket, non sarà più
   possibile scrivere dati su di esso. Nel caso di socket TCP la chiamata causa
   l'emissione di un segmento FIN, secondo la procedura chiamata
   \itindex{half-close} \textit{half-close}. Tutti i dati presenti nel buffer
   di scrittura prima della chiamata saranno inviati, seguiti dalla sequenza di
   chiusura illustrata in sez.~\ref{sec:TCP_conn_term}.
-\item[\macro{SHUT\_RDWR}] chiude sia il lato in lettura che quello in
+\item[\const{SHUT\_RDWR}] chiude sia il lato in lettura che quello in
   scrittura del socket. È equivalente alla chiamata in sequenza con
-  \macro{SHUT\_RD} e \macro{SHUT\_WR}.
+  \const{SHUT\_RD} e \const{SHUT\_WR}.
 \end{basedescript}
 
-Ci si può chiedere quale sia l'utilità di avere introdotto \macro{SHUT\_RDWR}
+Ci si può chiedere quale sia l'utilità di avere introdotto \const{SHUT\_RDWR}
 quando questa sembra rendere \funcd{shutdown} del tutto equivalente ad una
 \func{close}. In realtà non è così, esiste infatti un'altra differenza con
 \func{close}, più sottile. Finora infatti non ci siamo presi la briga di
@@ -3116,7 +3116,7 @@ dato che restano altri riferimenti attivi, uno al socket connesso nel figlio
 ed uno a quello in ascolto nel padre.
 
 Questo non avviene affatto se si usa \func{shutdown} con argomento
-\macro{SHUT\_RDWR} al posto di \func{close}; in questo caso infatti la
+\const{SHUT\_RDWR} al posto di \func{close}; in questo caso infatti la
 chiusura del socket viene effettuata immediatamente, indipendentemente dalla
 presenza di altri riferimenti attivi, e pertanto sarà efficace anche per tutti
 gli altri file descriptor con cui, nello stesso o in altri processi, si fa
@@ -3601,7 +3601,7 @@ Da fare.
 % LocalWords:  lsof SOCK sys int sockfd const struct sockaddr serv addr socklen
 % LocalWords:  addrlen errno EBADF descriptor EINVAL ENOTSOCK EACCES EADDRINUSE
 % LocalWords:  EADDRNOTAVAIL EFAULT ENOTDIR ENOENT ENOMEM ELOOP ENOSR EROFS RPC
-% LocalWords:  portmapper htonl tab endianess BROADCAST broadcast any extern fd
+% LocalWords:  portmapper htonl tab endianness BROADCAST broadcast any extern fd
 % LocalWords:  ADRR INIT DGRAM SEQPACKET servaddr ECONNREFUSED ETIMEDOUT EAGAIN
 % LocalWords:  ENETUNREACH EINPROGRESS EALREADY EAFNOSUPPORT EPERM EISCONN proc
 % LocalWords:  sysctl filesystem syn retries reset ICMP backlog EOPNOTSUPP RECV