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}}
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
\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}).
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
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}; l'hardware di
-gestione della memoria genera un'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.
+reale, avviene quello che viene chiamato un \textit{page fault}\index{page
+ fault}; l'hardware di gestione della memoria genera un'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
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}
commette quando si è manipolato male un puntatore e genera quello che viene
chiamato un \textit{segmentation fault}. Se si tenta cioè di leggere o
scrivere da un indirizzo per il quale non esiste un'associazione della pagina
-virtuale, il kernel risponde al relativo \textit{page fault} mandando un
-segnale \macro{SIGSEGV} al processo, che normalmente ne causa la terminazione
-immediata.
+virtuale, il kernel risponde al relativo \textit{page fault}
+mandando un segnale \macro{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
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
\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
attraverso il valore di ritorno. È buona norma seguire questa pratica anche
nella programmazione normale.
-
Talvolta però è necessario che la funzione possa restituire indietro alla
funzione chiamante un valore relativo ad uno dei suoi parametri. Per far
questo si usa il cosiddetto \textit{value result argument}, si passa cioè,
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}.
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
variabile di argomenti è che non esiste un modo generico che permetta di
stabilire quanti sono i parametri passati effettivamente in una chiamata.
in maniera statica (usando variabili di tipo \ctyp{static} o \ctyp{extern}), o
dinamicamente con una delle funzioni della famiglia \func{malloc}.
+
\subsection{Il controllo di flusso non locale}
\label{sec:proc_longjmp}
\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 chiara anche dal punto di vista della struttura del programma,
+efficiente e chiara anche dal punto di vista della struttura del programma:
quello dell'uscita in caso di errore.
Il C però non consente di effettuare un salto ad una label definita in
-un'altra funzione, per cui se l'errore avviene in funzioni profondamente
-annidate occorre usare quello che viene chiamato un salto \textsl{non-locale};
-questo viene fatto usando salvando il contesto dello stack nel punto in cui si
-vuole tornare in caso di errore, e ripristinandolo quando l'occorrenza capita.
-
-La funzione che permette di salvare il contesto dello stack è \func{setjmp},
-il cui prototipo è:
-
+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
+ottenere le indicazioni per l'esecuzione di opportune operazioni.
+
+Dato che l'analisi può risultare molto complessa, ed opportunamente suddivisa
+in fasi diverse, la rilevazione di un errore nell'input può accadere
+all'interno di funzioni profondamente annidate l'una nell'altra. In questo
+caso si dovrebbe per ciascuna fase dover gestire tutta la casistica del
+passaggio all'indietro di tutti gli errori rilevabili dalle funzioni usate
+nelle fasi successive, mentre sarebbe molto più comodo poter tornare
+direttamente al ciclo di lettura principale, scartando l'input come
+errato.\footnote{a meno che, come precisa \cite{glibc}, alla chiusura di
+ ciascuna fase non siano associate operazioni di pulizia specifiche (come
+ deallocazioni, chiusure di file, ecc.), che non potrebbero essere eseguite
+ con un salto non-locale.}
+
+Tutto ciò può essere realizzato salvando il contesto dello stack nel punto in
+cui si vuole tornare in caso di errore, e ripristinandolo quando l'occorrenza
+capita. La funzione che permette di salvare il contesto dello stack è
+\func{setjmp}, il cui prototipo è:
\begin{functions}
\headdecl{setjmp.h}
\funcdecl{void setjmp(jmp\_buf env)}
Salva il contesto dello stack in \param{env} per un successivo uso da parte
- di \func{longjmp}. Il contesto viene invalidato se la routine che ha
- chiamato \func{setjmp} ritorna.
-
+ di \func{longjmp}.
+
\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}
-
-Per poter effettuare un salto non locale si usa la funzione \func{longjmp}; il
-suo prototipo è:
+Quando si esegue la funzione il contesto viene salvato in appositi oggetti (di
+tipo \type{jmp\_buf}), passati come primo argomento alla funzione, in genere
+questi vengono definiti come variabili globali in modo da poter essere visti
+in tutte le funzioni del programma.
+
+Quando viene eseguita direttamente la funzione ritorna sempre zero, un valore
+diverso da zero viene restituito solo quando il ritorno è dovuto ad una
+chiamata di \func{longjmp} in un'altra parte del programma. Si tenga conto che
+il contesto salvato in \param{env} viene invalidato se la routine che ha
+chiamato \func{setjmp} ritorna, nel qual caso l'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 \func{longjmp}; il suo
+prototipo è:
\begin{functions}
\headdecl{setjmp.h}
\funcdecl{void longjmp(jmp\_buf env, int val)}
- Ripristina il contesto dello stack salvato dall'ultima chiamata di
- \func{setjmp} con l'argomento \param{env}. Il programma prosegue dal ritorno
- di \func{setjmp} con un valore \param{val}. Il valore di \param{val} deve
- essere diverso da zero, se viene specificato 0 sarà usato 1 al suo posto.
-
+ Ripristina il contesto dello stack salvato nell'ultima chiamata di
+ \func{setjmp} con l'argomento \param{env}.
+
\bodydesc{La funzione non ritorna.}
\end{functions}
+Dopo l'esecuzione della funzione programma prosegue dal 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}, ed 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 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 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 operando per un operatore di uguaglianza o confronto in una
+ espressione di controllo di un comando condizionale, di selezione o di
+ iterazione.
+\item come operando per l'operatore di negazione (\code{!}) in una espressione
+ di controllo di un comando condizionale, di selezione o di iterazione.
+\item come espressione a sé stante.
+\end{itemize}
+
+In generale, dato che l'unica differenza fra la chiamata diretta e quella
+ottenuta da un \func{longjmp}, è il valore di ritorno di \func{setjmp}, essa è
+usualmente chiamata all'interno di un comando \code{if}.
+
+Uno dei punti critici dei salti non-locali è quello del valore delle
+variabili, ed in particolare quello delle variabili automatiche della funzione
+a cui si ritorna. In generale le variabili globali e statiche mantengono i
+valori che avevano al momento della chiamata di \func{longjmp}, ma quelli
+delle variabili automatiche (o di quelle dichiarate \code{register}) sono in
+genere indeterminati.
+
+Quello che succede infatti è che i valori delle variabili che sono tenute in
+memoria manterranno il valore avuto al momento della chiamata di
+\func{longjmp}, mentre quelli tenuti nei registri del processore (che nella
+chiamata ad un'altra funzioni vengono salvati nel contesto nello stack)
+torneranno al valore avuto al momento della chiamata di \func{setjmp}; per
+questo quando si vuole avere un comportamento coerente si può bloccare
+l'ottimizzazione che porta le variabili nei registri dichiarandole tutte come
+\code{volatile}.
+
+
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff