X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=process.tex;h=e3a4774786115eb7561fadeb0e0d914856dc4385;hp=79cf7ae06bf9fab4683fbd074990342a87fb43d6;hb=d7305d300866c1e6909dd23743060632b3718178;hpb=9ed5353304ae9ef478fce673c5e0dbe873ee2ba8 diff --git a/process.tex b/process.tex index 79cf7ae..e3a4774 100644 --- a/process.tex +++ b/process.tex @@ -24,8 +24,8 @@ ciascun processo vedr 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.\footnote{questo non è del tutto vero nel caso di un programma - \textit{multi-thread}, ma sulla gestione dei \textit{thread} in Linux - torneremo più avanti.} + \textit{multi-thread}, ma la gestione dei \textit{thread} in Linux sarà + trattata a parte.} \subsection{La funzione \func{main}} @@ -50,10 +50,10 @@ Lo standard ISO C specifica che la funzione \func{main} pu 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{lstlisting}[labelstep=0,frame=,indent=1cm]{} - int main (int argc, char *argv[]) + int main (int argc, char *argv[]) \end{lstlisting} -In realtà nei sistemi unix esiste un'altro modo per definire la funzione +In realtà nei sistemi Unix esiste un'altro modo per definire la funzione \func{main}, che prevede la presenza di un terzo parametro, \var{char *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{sec:proc_environ}) del programma; questa forma però non è prevista dallo standard POSIX.1 per cui @@ -211,7 +211,7 @@ stream aperti, infine verr \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 +in un sistema Unix l'unico modo in cui un programma può essere eseguito dal kernel è attraverso la chiamata alla system call \func{execve} (o attraverso una delle funzioni della famiglia \func{exec} che vedremo in \secref{sec:proc_exec}). @@ -253,11 +253,12 @@ esecuzione, e le varie funzioni utilizzabili per la sua gestione. Ci sono vari modi in cui i vari sistemi organizzano la memoria (ed i dettagli di basso livello dipendono spesso in maniera diretta dall'architettura dell'hardware), ma quello più tipico, usato dai sistemi unix-like come Linux è -la cosiddetta \textsl{memoria virtuale} che consiste nell'assegnare ad ogni -processo uno spazio virtuale di indirizzamento lineare, in cui gli indirizzi -vanno da zero ad un qualche valore massimo.\footnote{nel caso di Linux fino al - kernel 2.2 detto massimo era, per macchine a 32bit, di 2Gb, con il kernel - 2.4 ed il supporto per la \textit{high-memory} il limite è stato esteso.} +la cosiddetta \textsl{memoria virtuale}\index{memoria virtuale} che consiste +nell'assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare, +in cui gli indirizzi vanno da zero ad un qualche valore massimo.\footnote{nel + caso di Linux fino al kernel 2.2 detto massimo era, per macchine a 32bit, di + 2Gb, con il kernel 2.4 ed il supporto per la \textit{high-memory} il limite + è stato esteso.} Come accennato in \capref{cha:intro_unix} questo spazio di indirizzi è virtuale e non corrisponde all'effettiva posizione dei dati nella RAM del @@ -286,8 +287,8 @@ gestione della memoria (la \textit{Memory Management Unit} del processore). Poiché in genere la memoria fisica è solo una piccola frazione della memoria virtuale, è necessario un meccanismo che permetta di trasferire le pagine 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. +servono. Questo meccanismo è detto \textsl{paginazione}\index{paginazione} (o +\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}\index{page @@ -305,8 +306,8 @@ a tempi molto pi Normalmente 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}). +permettono di bloccare il meccanismo della paginazione e mantenere fisse delle +pagine in memoria (vedi \ref{sec:proc_mem_lock}). \subsection{La struttura della memoria di un processo} @@ -662,10 +663,10 @@ memoria per metterle nello swap, sulla base dell'utilizzo corrente da parte dei vari processi. Nell'uso comune un processo non deve preoccuparsi di tutto ciò, in quanto il -meccanismo della paginazione riporta in RAM, ed in maniera trasparente, tutte -le pagine che gli occorrono; esistono però esigenze particolari in cui non si -vuole che questo meccanismo si attivi. In generale i motivi per cui si possono -avere di queste necessità sono due: +meccanismo della paginazione\index{paginazione} riporta in RAM, ed in maniera +trasparente, tutte le pagine che gli occorrono; esistono però esigenze +particolari in cui non si vuole che questo meccanismo si attivi. In generale i +motivi per cui si possono avere di queste necessità sono due: \begin{itemize} \item \textsl{La velocità}. Il processo della paginazione è trasparente solo se il programma in esecuzione non è sensibile al tempo che occorre a @@ -845,7 +846,7 @@ questo meccanismo \subsection{La gestione delle opzioni} \label{sec:proc_opt_handling} -In generale un programma unix riceve da linea di comando sia gli argomenti che +In generale un programma Unix riceve da linea di comando sia gli argomenti che le opzioni, queste ultime sono standardizzate per essere riconosciute come tali: un elemento di \var{argv} che inizia con \texttt{-} e che non sia un singolo \texttt{-} o un \texttt{--} viene considerato un'opzione. In genere @@ -1335,12 +1336,12 @@ stack all'indirizzo dove sono stati salvati i parametri, normale pensare di poter effettuare questa operazione. In generale però possono esistere anche realizzazioni diverse, per questo -motivo \macro{va\_list} è definito come tipo opaco e non può essere assegnato -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 un puntatore alla lista degli argomenti: +motivo \macro{va\_list} è definito come \textsl{tipo opaco} e non può essere +assegnato 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 un puntatore alla lista degli argomenti: \begin{prototype}{stdarg.h}{void va\_copy(va\_list dest, va\_list src)} Copia l'attuale valore \param{src} del puntatore alla lista degli argomenti su \param{dest}. @@ -1412,8 +1413,8 @@ un'altra funzione, per cui se l'errore avviene in una funzione e la sua gestione ordinaria è in un'altra occorre usare quello che viene chiamato un \textsl{salto non-locale}. Il caso classico in cui si ha questa necessità, citato sia da \cite{APUE} che da da \cite{glibc}, è quello di un programma nel -cui corpo principale in cui viene letto un input del quale viene eseguita -attraverso una serie di funzioni di analisi una scansione dei contenuti da cui +cui corpo principale in cui viene letto un input del quale viene eseguita, +attraverso una serie di funzioni di analisi, una scansione dei contenuti da cui ottenere le indicazioni per l'esecuzione di opportune operazioni. Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa