X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=process.tex;h=84cd0fef33faac87260763e2aa09032b4967e4ca;hb=ff956befad3d90f022455c0f9217f47672318185;hp=88e059d345e7f3b77f76b5b472080ff3c1771660;hpb=654eacf69fa5c0ad225fa0306e3ea27e72194957;p=gapil.git

diff --git a/process.tex b/process.tex
index 88e059d..84cd0fe 100644
--- a/process.tex
+++ b/process.tex
@@ -11,36 +11,415 @@ esecuzione.
 In genere un programma viene eseguito quando un processo lo fa partire
 eseguendo una funzione della famiglia \texttt{exec}; torneremo su questo e
 sulla la creazione e gestione dei processi nel prossimo capitolo, in questo
-affronteremo l'avvio e il funzionamento di un programma dal punto di vista del
-programma posto in esecuzione.
+affronteremo l'avvio e il funzionamento di un singolo processo partendo dal
+punto di vista del programma posto in esecuzione.
 
 
+
+\section{Esecuzione e conclusione di un programma}
+
+Una delle concetti base relativi ai processi è che un processo esegue sempre
+uno ed un solo programma: si possono avere più processi che eseguono lo stesso
+programma ma ciascun processo vedrà la sua copia del codice (in realtà il
+kernel fa si che tutte le parti uguali siano condivise) avrà un suo spazio di
+indirizzi, variabili proprie e sarà eseguito in maniera completamente
+indipendente da tutti gli altri. 
+
+Anche quando all'interno di un programma possono essere presenti più
+\textsl{filoni} di esecuzione (i cosiddetti \textit{thread}), o questo possa
+essere composto da moduli multipli completamente separati, quando questo sarà
+posto in esecuzione esso apparirà al sistema come un solo processo (il
+discorso dei \textit{thread} comunque in linux necessita di una trattazione a
+parte per la peculiarità dell'implementazione).
+
 \section{La funzione \texttt{main}} 
 \label{sec:proc_main}
 
+Quando un programma viene lanciato il kernel esegue una opportuna routine di
+avvio, usando il programma \texttt{ld-linux.so}, è questo programma che prima
+carica le librerie condivise che servono al programma, effettua il link
+dinamico del codice e poi alla fine lo esegue. Infatti, a meno di non aver
+specificato il flag \texttt{-static} durante la compilazione, tutti i
+programmi in linux sono incompleti e necessitano di essere linkati alle
+librerie condivise quando vengono avviati.  La procedura è controllata da
+alcune variabili di ambiente e dal contenuto di \texttt{/etc/ld.so.conf}, i
+dettagli sono riportati nella man page di \texttt{ld.so}.
+
+Il sistema fa partire qualunque programma chiamando la funzione \texttt{main};
+sta al programmatore chiamare così la funzione principale del programma da cui
+si suppone iniziale l'esecuzione; in ogni caso senza questa funzione lo stesso
+linker darebbe luogo ad errori.
+
+Lo stadard ISO C specifica che la funzione \texttt{main} può o non avere
+argomenti o prendere due argomenti che rappresentano gli argomenti passati da
+linea di comando, in sostanza un prototipo che va sempre bene è il seguente:
+\begin{verbatim}
+     int main (int argc, char *argv[])
+\end{verbatim}
 
+In realtà nei sistemi unix esiste un'altro modo per definire la funzione
+\texttt{main}, che prevede la presenza di un terzo parametro, \texttt{char
+  *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{proc_environ}) del
+programma; questa forma però non è prevista dallo standard POSIX.1 per cui se
+si vogliono scrivere programmi portabili è meglio evitarla.
+
+
+\subsection{Come chiudere un programma}
+\label{sec:proc_termination}
+
+La via normale per la quale un programma finisce è quando la funzione main
+ritorna, una modalità equivalente di conclusione è quella di chiamare
+direttamente la funzione \texttt{exit} (che viene comunque chiamata dalla
+routine di avvio del programma quando la funzione main ritorna). Una forma
+alternativa è quella di chiamare direttamente la system call \texttt{\_exit}
+che passa il controllo direttamente al kernel.
+
+Oltre alla conclusione ``normale'' esiste anche la possibilità di una
+conclusione ``anomala'' del programma a causa di segnali o della chiamata alla
+funzione \texttt{abort} (che comunque genera un segnale che termina il
+programma); torneremo su questo in \secref{sec:sig_abort}.
+
+Il valore di ritorno della funzione main, o quello usato nelle chiamate ad
+\texttt{exit} e \texttt{\_exit}, viene chiamato \textit{exit status} e passato
+al processo padre che aveva lanciato il programma (in genere la shell). In
+generale si usa questo valore per fornire un'informazione generica sulla
+riuscita o il fallimento del programma; l'informazione è necessariamente
+generica, ed il valore deve essere compreso fra 0 e 255.
+
+In generale si usa la convenzione di restituire 0 in caso di successo e 1 in
+caso di fallimento, i programmi che effettuano dei confronti (come
+\texttt{diff}) usano invece una notazione leggermente diversa, usando 0 per
+indicare la corrispondenza, 1 per indicare la non corrispondenza e 2 per
+indicare l'incapacità di effettuare il confronto. È opportuno adottare una di
+queste convenzioni a seconda dei casi. Si tenga presente che se si raggiunge
+la fine della funzione \texttt{main} senza ritornare esplicitamente si ha un
+valore di uscita indefinito, è pertanto consigliabile di concludere sempre in
+maniera esplicita detta funzione.
+
+Una altra convenzione riserva i valori da 128 in sù per usi speciali, ad
+esempio 128 viene usato per indicare l'incapacità di eseguire un altro
+programma in un sottoprocesso. Benché anche questa convenzione non sia
+universalmente seguita è una buona idea tenerne conto.
+
+Si tenga presente inoltre che non è una buona idea usare il valore dell'errore
+restituito dalla variabile \texttt{errno} come stato di uscita, in generale
+una shell non si cura di tutto questo e comunque il valore dello stato di
+uscita è sempre troncato ad 8 bit, per cui si potrebbe incorrere nel caso in
+cui l'errore 256, diventando zero, verrebbe interpretato come un successo. In
+\texttt{stdlib.h} sono definite due macro \texttt{EXIT\_SUCCESS} e
+\texttt{EXIT\_FAILURE}, che in linux sono poste rispettivamente ai valori 0 e
+1 (di tipo \texttt{int}), seguendo lo standard POSIX.
+
+Infine occorre distinguere fra lo stato di uscita di un programma
+(l'\textit{exit status}) e lo stato di conclusione di un processo (il
+\textit{termination status}), abbiamo già accennato infatti che è comunque
+possibile un processo possa essere terminato (da un segnale) prima che il
+programma in esecuzione si sia concluso. In caso di conclusione normale del
+programma però lo stato di uscita diventa parte dello stato di conclusione del
+processo (vedi \secref{sec:prochand_XXX}).
+
+
+\subsection{Le funzioni \texttt{exit} e \texttt{\_exit}}
+\label{sec:proc_exit}
 
-\subsection{}
-\label{sec:proc_}
+Come accennato funzioni per l'uscita ``normale'' da un programma sono due, la
+prima è la funzione \texttt{exit} che è definita dallo standard ANSI C, il
+prototipo della funzione è il seguente:
+\begin{prototype}{stdlib.h}{void exit(int status)}
+  Causa la conclusione ordinaria del programma restituendo il valore
+  \texttt{status} al processo padre.
+
+  La funzione non ritorna. Il processo viene terminato
+\end{prototype}
+
+La funzione \texttt{exit} è pensata per una conclusione pulita di un programma
+che usa le librerie standard del C; essa esegue tutte le funzioni che sono
+state registrate con \texttt{atexit} e \texttt{on\_exit} (vedi
+\secref{sec:proc_atexit}), e chiude tutti gli stream di I/O effettuando il
+salvataggio dei dati sospesi (chiamando \texttt{fclose}, vedi
+\secref{sec:filestd_close}), infine ripassa il controllo al kernel chiamando
+\texttt{\_exit} e passando il valore \texttt{status} come stato di uscita.
+
+La system call \texttt{\_exit} restituisce direttamente il controllo al
+kernel, concludendo immediatamente il processo, le eventuali funzioni
+registrate con \texttt{atexit} e \texttt{on\_exit} non vengono eseguite. Il
+prototipo della funzione è il seguente:
+\begin{prototype}{unistd.h}{void \_exit(int status)}
+  Causa la conclusione immediata del programma restituendo il valore
+  \texttt{status} al processo padre.
+
+  La funzione non ritorna. Il processo viene terminato.
+\end{prototype}
+
+La funzione chiude tutti i file descriptor appartenenti al processo (sui tenga
+presente che questo non comporta il salvataggio dei dati bufferizzati degli
+stream), fa si che ogni figlio del processo sia ereditato da \texttt{init}
+(vedi \secref{cha:process_handling}), manda un segnale \texttt{SIGCHLD} al
+processo padre (vedi \ref{sec:sig_sigchild}) ed infine ritorna lo stato di
+uscita specificato in \texttt{status} che può essere raccolto usando la
+funzione \texttt{wait} (vedi \secref{sec:prochand_wait}).
+
+
+\subsection{Le funzioni \texttt{atexit} e \texttt{on\_exit}}
+\label{sec:proc_atexit}
+
+Come accennato l'uso di \texttt{exit} al posto della \texttt{\_exit} è fatto
+principalmente per permettere una uscita pulita dalle funzioni delle librerie
+standard del C (in particolare per quel che riguarda la chiusura degli
+stream). 
+
+Quando si realizza una libreria da usare in varie applicazioni può essere
+perciò utile evitare di richiedere di chiamare esplicitamente un funzione di
+uscita che esegua tutte le operazioni di pulizia prima di uscire (come quella
+di salvare eventuali dati sospesi). È invece molto meno soggetto ad errori e
+completamente trasparente all'utente poter effettuare una chiamata automatica
+di una funzione che effettui tali operazioni all'uscita dal programma.
+
+A questo scopo lo standard ANSI C prevede la possibilità di registrare un
+certo numero funzioni che verranno eseguite all'uscita dal programma (sia per
+la chiamata ad \textit{exit} che per il ritorno di \texttt{main}). La prima
+funzione che si può utilizzare a tal fine è:
+\begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
+  Registra la funzione \texttt{function} per essere chiamata all'uscita dal
+  programma. 
+
+  La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
+  \texttt{errno} non viene settata.
+\end{prototype}
+
+La funzione richiede come argomento l'indirizzo della opportuna da chiamare
+all'uscita che non deve prendere argomenti e non deve ritornare niente. Una
+estensione di \texttt{atexit} è la funzione \texttt{on\_exit} (che la glibc
+include per compatibilità con SunOS e che non è detta sia definita su altri
+sistemi), il cui prototipo è:
+\begin{prototype}{stdlib.h}
+{void on\_exit(void (*function)(int status, void *arg), void *arg)}
+  Registra la funzione \texttt{function} per essere chiamata all'uscita dal
+  programma. Tutte le funzioni registrate vengono chiamate in ordine inverso
+  rispetto a quello di registrazione.
+
+  La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
+  \texttt{errno} non viene settata.
+\end{prototype}
+
+In questo caso la funzione da chiamare prende due parametri, il primo dei
+quali sarà inizializzato allo stato di uscita con cui è stata chiamata
+\texttt{exit} ed il secondo al puntatore generico specificato come secondo
+argomento nella chiamata di \texttt{on\_exit}.
+
+Tutte le funzioni registrate vengono chiamate in ordine inverso rispetto a
+quello di registrazione (ed una stessa funzione registrata più volte sarà
+chiamata più volte); poi vengono chiusi tutti gli stream aperti, infine viene
+chiamata \texttt{\_exit}.
+
+
+\subsection{Conclusioni}
+\label{sec:proc_term_conclusion}
+
+Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
+in un sistema unix l'unico modo in cui un programma può essere eseguito dal
+kernel è attraverso la chiamata alla system call \texttt{execve} (in genere
+attraveso una delle funzioni \texttt{exec} che vedremo in
+\secref{sec:prochand_exec}).
+
+Allo stesso modo l'unico modo in cui un programma può concludere
+volontariamente la sua esecuzione è attraverso una chiamata alla system call
+\texttt{\_exec} sia esplicitamnte o che in maniera indiretta attraverso l'uso
+di \texttt{exit} o il ritorno della funzione \texttt{main}.
+
+Lo schema delle modalità con cui si avvia e conclude normalmente un programma
+è riportato in \nfig.
+
+\begin{figure}[htb]
+  \centering
+  
+  \caption{Schema dell'avvio e della conclusione di un programma.}
+  \label{fig:proc_prog_start_stop}
+\end{figure}
 
+Si ricordi infine che un programma può anche essere interrotto dall'esterno
+attraverso l'uso di un segnale (modalità di conclusione non mostrata in
+\curfig); torneremo su questo aspetto in \secref{cha:signals}.
+
+
+
+\section{I processi e l'uso della memoria}
+\label{sec:proc_memory}
+
+Una delle risorse base che ciascun processo ha a disposizione è la memoria, ed
+uno degli aspetti più complessi di un sistema unix (ed in particolar modo di
+linux) è appunto la gestione della memoria. Qui ci occuperemo però di come la
+memoria viene vista dal punto di vista di un programma in esecuzione in un
+processo.
+
+
+\subsection{I concetti generali}
+\label{sec:proc_mem_gen}
+
+Ci sono vari modi in cui i vari sistemi organizzano la memoria (ed i dettagli
+di basso livello dipendono in maniera diretta dall'architettura
+dell'hardware), ma quello più tipico, usato da unix (e da linux) è quello di
+assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare in
+cui gli indirizzi vanno da zero ad un qualche valore massimo (nel caso di
+linux fino al kernel 2.2 detto massimo era per macchine a 32bit di 2Gb, con il
+kernel 2.4 il limite è stato esteso).
+
+Come accennato nell'introduzione questo spazio di indirizzi è virtuale e non
+corrisponde all'effettiva posizione dei dati nella ram del computer; in genere
+detto spazio non è neanche continuo (cioè non tutti gli indirizzi sono
+utilizzabili e/o utilizzati).
+
+La memoria virtuale viene divisa in pagine (che ad esempio sono di 4kb su
+macchine a 32 bit e 8kb sulle alpha, valori strettamente connessi all'hardware
+di gestione della memoria) di dimensione fissa, e ciascuna pagina della
+memoria virtuale è associata ad un supporto che può essere una pagina di
+memoria reale o ad un dipositivo di stoccaggio secondario (in genere lo spazio
+disco riservato alla swap, o i file che contengono il codice).
+
+Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a
+diverse pagine di memoria virtuale appartenenti a processi diversi (come
+accade in genere per le pagine che contengono il codice delle librerie
+condivise). Ad esempio il codice della fuzione \texttt{printf} starà su una
+sola pagina di memoria reale che farà da supporto a tutte le pagine di memoria
+virtuale di tutti i processi hanno detta funzione nel loro codice. 
+
+La corrispondenza fra le pagine della memoria virtuale e quelle della memoria
+fisica della macchina viene gestita in maniera trasparente dall'hardware di
+gestione della memoria (dalla \textit{Memory Management Unit} del processore),
+ma poiché in genere quest'ultima è solo una piccola frazione della memoria
+virtuale è necessario un meccanismo che permetta di trasferire le pagine
+virtuali che servono dal supporto su cui si trovano in memoria eliminando
+quelle che non servono. Questo meccanismo è detto \textit{paging}, ed è uno
+dei compiti principali del kernel.
+
+Quando un processo cerca di accedere ad una pagina che non è nella memoria
+reale avviene quello che viene chiamato un \textit{page fault}, l'hardware di
+gestione della memoria (la MMU del processore) genera una interruzione e passa
+il controllo al kernel il quale sospende il processo e si incarica di mettere
+in ram la pagina richiesta (effettuando tutte le operazioni necessarie per
+reperire lo spazio necessario), per poi restituire il controllo al
+processo. 
+
+Dal punto di vista di un processo questo meccanismo è completamente
+trasparente e tutto avviene come se tutte le pagine fossero sempre disponibili
+in memoria.  L'unica differenza avvertibile è quella dei tempi di esecuzione,
+che passano dai pochi nanosecondi necessari per l'accesso a tempi molto più
+lunghi, dovuti all'intervento del kernel. Normalemente questo è il prezzo da
+pagare per avere un multitasking reale, ed in genere il sistema è molto
+efficiente in questo lavoro; quando però ci siano esigenze specifiche di
+prestazioni è possibile usare delle funzioni che permettono di bloccare il
+meccanismo del paging e mantenere fisse delle pagine in memoria (vedi
+\ref{sec:proc_mem_lock}).
+
+
+\subsection{La struttura della memoria di un processo}
+\label{sec:proc_mem_layout}
+
+Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
+una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
+tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
+commette quando si è manipolato male un puntatore e genera quello che viene
+chiamato un \textit{segmentation fault}, si tenta cioè di leggere e scrivere
+da un indirizzo per il quale non esiste una associazione della pagina virtuale
+ed il kernel riponde al relativo \textit{page fault} mandando un segnale
+\texttt{SIGSEGV} al processo, che normalmente ne causa la terminazione
+immediata.
+
+È pertanto importante capire come viene strutturata la memoria virtuale di un
+processo; essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
+indirizzi virtuali ai quali il processo può accedere. Storicamente un
+programma C viene suddiviso nei seguenti segmenti:
+
+\begin{enumerate}
+\item Il segmento di testo (\textit{text segment}). Contiene il codice
+  macchina del programma e le costanti statiche. Normalente viene condiviso
+  così che più processi (anche diversi nel caso di librerie) possano
+  utilizzarlo e marcato in sola lettura per evitare sovrascritture accidentali
+  (o maliziose) che ne modifichino le istruzioni. 
+  
+  Viene allocato da \texttt{exec} all'avvio del programma e resta invariato
+  per tutto il tempo dell'esecuzione.
+  
+\item Il segmento dei dati (\textit{data segment}). Contiene le varibili
+  globali (cioè quelle definite al di fuori di tutte le funzioni). Di norma è
+  diviso in due parti.
+  
+  La prima è il segmento dei dati inizializzati, che contiene le variabili
+  globali il cui valore è stato assegnato esplicitamente. Ad esempio se si
+  definisce:
+\begin{verbatim}
+    double pi = 3.14;
+\end{verbatim}
+  questo valore sarà immagazzinato in questo segmento. La memoria di questo
+  segmento viene preallocato dalla \texttt{exec} e inizializzata ai valori
+  specificati.
+  
+  La seconda è il segmento dei dati non inizializzati, che contiene le
+  variabili globali il cui valore è stato non è assegnato esplicitamente. Ad
+  esempio se si definisce:
+\begin{verbatim}
+    int vect[100];
+\end{verbatim}
+  questo valore sarà immagazzinato in questo segmento. Anch'esso viene
+  allocato all'avvio, e tutte le varibili vengono inizializzate a
+  zero (ed i puntatori a \texttt{NULL}). 
+  
+  Storicamente questo segmento viene chiamato BBS (da \textit{block started by
+    symbol}. La sua dimensione è fissa.
+  
+\item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del
+  segmento dati, a cui di solito è posto giusto di seguito. È qui che avviene
+  l'allocazione dinamica della memoria; può essere ridimensionato allocando e
+  disallocando la memoria dinamica con le apposite funzioni (vedi
+  \secref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente
+  al segmento dati) ha una posizione fissa.
+  
+\item Il segmento di \textit{stack}, che contiene lo \textit{stack} del
+  programma.  Tutte le volte che si effettua una chiamata ad una funzione è
+  qui che viene salvato l'indirizzo di ritorno e le informazioni dello stato
+  del chiamante (tipo il contenuto di alcuni registri della CPU); poi la
+  funzione chiamata alloca qui lo spazio per le sue variabili locali, in
+  questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
+  della funzione lo spazio è automaticamente rilasciato.
+  
+  La dimensione di questo segmento aumenta seguendo la crescita dello stack
+  del programma, ma non viene ridotta quando quest'ultimo si restringe.
+\end{enumerate}
+
+\begin{figure}[htb]
+  \centering
+  
+  \caption{Disposizione tipica dei segmenti di memoria di un processo}
+  \label{fig:proc_mem_layout}
+\end{figure}
 
+Una disposizione tipica di questi segmenti è riportata in \nfig. Usando il
+comando \texttt{size} su un programma se ne può stampare le dimensioni dei
+segmenti di testo e di dati (inizializzati e BSS); il BSS però non è mai
+salvato sul file, in quanto viene inizializzato a zero al caricamento del
+programma.
+
+
+\subsection{La librerie condivise}
+\label{sec:proc_mem_shlib}
 
-\subsection{La funzione \texttt{exit}}
-\label{sec:proc_exit}
 
 
-\section{La gestione della memoria}
-\label{sec:proc_mem_manag}
 
+\subsection{Allocazione e disallocazione della memoria}
+\label{sec:proc_mem_alloc}
 
 
-\section{Gestione di parametri e opzioni}
+
+
+
+\section{La gestione di parametri e opzioni}
 \label{sec:parameter_options}
 
 Il passaggio dei parametri e delle variabili di ambiente dalla riga di comando
 al singolo programma quando viene lanciato è effettuato attraverso le
 variabili \texttt{argc}, \texttt{argv} che vengono passate al programma
-come argomenti della funzione principale:
+come argomenti della funzione principale.
 
 \subsection{Il formato dei parametri}
 \label{sec:proc_par_format}
@@ -171,6 +550,3 @@ versione estesa di \texttt{getopt}.
 \subsection{Le variabili di ambiente}
 \label{sec:proc_env_var}
 
-Questo va fatto.
-
-