X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=process.tex;h=67cb4f5ccf1da431546545983e53a4624880529f;hp=e5e4b50ab66464dd828c8eead3a339c6d7a263ee;hb=3498a6fc0fd13e07cacdea210cb99126d5052fbc;hpb=477c80ba90e4571eb046af49b64dba15eb5a08bf diff --git a/process.tex b/process.tex index e5e4b50..67cb4f5 100644 --- a/process.tex +++ b/process.tex @@ -222,7 +222,7 @@ volontariamente la sua esecuzione \func{exit} o il ritorno di \func{main}. Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude -normalmente un programma è riportato in \nfig. +normalmente un programma è riportato in \figref{fig:proc_prog_start_stop}. \begin{figure}[htb] \centering @@ -233,7 +233,8 @@ normalmente un programma 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 \capref{cha:signals}. +\figref{fig:proc_prog_start_stop}); torneremo su questo aspetto in +\capref{cha:signals}. @@ -480,7 +481,7 @@ allineato correttamente per tutti i tipi di dati; ad esempio sulle macchine a 32 bit in genere è allineato a multipli di 4 byte e sulle macchine a 64 bit a multipli di 8 byte. -In genere su usano le funzioni \func{malloc} e \func{calloc} per allocare +In genere si usano le funzioni \func{malloc} e \func{calloc} per allocare dinamicamente la memoria necessaria al programma, e siccome i puntatori ritornati sono di tipo generico non è necessario effettuare un cast per assegnarli a puntatori al tipo di variabile per la quale si effettua @@ -531,18 +532,18 @@ variabile \macro{MALLOC\_CHECK\_} che quando viene definita mette in uso una versione meno efficiente delle funzioni suddette, che però è più tollerante nei confronti di piccoli errori come quello di chiamate doppie a \func{free}. In particolare: -\begin{itemize*} +\begin{itemize} \item se la variabile è posta a zero gli errori vengono ignorati. \item se è posta ad 1 viene stampato un avviso sullo \textit{standard error} (vedi \secref{sec:file_std_stream}). \item se è posta a 2 viene chiamata \func{abort}, che in genere causa l'immediata conclusione del programma. -\end{itemize*} +\end{itemize} Il problema più comune e più difficile da risolvere che si incontra con le routine di allocazione è quando non viene opportunamente liberata la memoria non più utilizzata, quello che in inglese viene chiamato \textit{memory-leak}, -cioè \textsl{perdita di memoria}. +cioè una \textsl{perdita di memoria}. Un caso tipico che illustra il problema è quello in cui in una subroutine si alloca della memoria per uso locale senza liberarla prima di uscire. La @@ -557,22 +558,54 @@ essere in una sezione del codice che non ha alcuna relazione con la subroutine che contiene l'errore. Per questo motivo è sempre molto difficile trovare un \textit{memory leak}. -Per ovviare a questi problemi l'implementazione delle routine di allocazione -delle \acr{glibc} mette a disposizione una serie di funzionalità che -permettono di tracciare le allocazioni e le disallocazione, e definisce anche -una serie di possibili \textit{hook} (\textsl{ganci}) che permettono di -sostituire alle funzioni di libreria una propria versione (che può essere più -o meno specializzata per il debugging). +In C e C++ il problema è particolarmente sentito. In C++, per mezzo della +programmazione ad oggetti, il problema dei \textit{memory leak} è notevolmente +ridimensionato attraverso l'uso accurato di appositi oggetti come gli +\textit{smartpointers}. Questo però va a scapito delle performance +dell'applicazione in esecuzione. + +In altri linguaggi come il java e recentemente il C\# il problema non si pone +nemmeno perché la gestione della memoria viene fatta totalmente in maniera +automatica, ovvero il programmatore non deve minimamente preoccuparsi di +liberare la memoria allocata precedentemente quando non serve più, poiché il +framework gestisce automaticamente la cosiddetta \textit{garbage collection}. +In tal caso, attraverso meccanismi simili a quelli del \textit{reference + counting}, quando una zona di memoria precedentemente allocata non è più +riferita da nessuna parte del codice in esecuzione, può essere deallocata +automaticamente in qualunque momento dall'infrastruttura. + +Anche questo va a scapito delle performance dell'applicazione in esecuzione +(inoltre le applicazioni sviluppate con tali linguaggi di solito non sono +eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria +la presenza di una infrastruttura per la loro interpretazione e pertanto hanno +di per sé delle performance più scadenti rispetto alle stesse applicazioni +compilate direttamente). Questo comporta però il problema della non +predicibilità del momento in cui viene deallocata la memoria precedentemente +allocata da un oggetto. + +Per limitare l'impatto di questi problemi, e semplificare la ricerca di +eventuali errori, l'implementazione delle routine di allocazione delle +\acr{glibc} mette a disposizione una serie di funzionalità che permettono di +tracciare le allocazioni e le disallocazione, e definisce anche una serie di +possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle +funzioni di libreria una propria versione (che può essere più o meno +specializzata per il debugging). Esistono varie librerie che forniscono dei +sostituti opportuni delle routine di allocazione in grado, senza neanche +ricompilare il programma,\footnote{esempi sono \textit{Dmalloc} + \href{http://dmalloc.com/}{http://dmalloc.com/} di Gray Watson ed + \textit{Electric Fence} di Bruce Perens.} di eseguire diagnostiche anche +molto complesse riguardo l'allocazione della memoria. + \subsection{La funzione \func{alloca}} \label{sec:proc_mem_alloca} Una possibile alternativa all'uso di \func{malloc}, che non soffre dei -problemi di memory leak descritti in precedenza, è la funzione \func{alloca}, -che invece di allocare la memoria nello heap usa il segmento di stack della -funzione corrente. La sintassi è identica a quella di \func{malloc}, il suo -prototipo è: +problemi di \textit{memory leak} descritti in precedenza, è la funzione +\func{alloca}, che invece di allocare la memoria nello heap usa il segmento di +stack della funzione corrente. La sintassi è identica a quella di +\func{malloc}, il suo prototipo è: \begin{prototype}{stdlib.h}{void *alloca(size\_t size)} Alloca \var{size} byte nel segmento di stack della funzione chiamante. La memoria non viene inizializzata. @@ -842,7 +875,7 @@ Nella scansione viene costruito il vettore di puntatori \var{argv} inserendo in successione il puntatore alla stringa costituente l'$n$-simo parametro; la variabile \var{argc} viene inizializzata al numero di parametri trovati, in questo modo il primo parametro è sempre il nome del programma; un esempio di -questo meccanismo è mostrato in \curfig. +questo meccanismo è mostrato in \figref{fig:proc_argv_argc}. \subsection{La gestione delle opzioni} @@ -1015,9 +1048,9 @@ pi Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo \textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate -in \curfig, sono definite dal sistema per essere usate da diversi programmi e -funzioni: per queste c'è l'ulteriore convenzione di usare nomi espressi in -caratteri maiuscoli. +in \figref{fig:proc_envirno_list}, sono definite dal sistema per essere usate +da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di +usare nomi espressi in caratteri maiuscoli. Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse @@ -1027,18 +1060,21 @@ configurazione. La shell ad esempio ne usa molte per il suo funzionamento (come \var{PATH} per la ricerca dei comandi, o \cmd{IFS} per la scansione degli argomenti), e -alcune di esse (come \var{HOME}, \var{USER}, etc.) sono definite al login. In -genere è cura dell'amministratore definire le opportune variabili di ambiente -in uno script di avvio. Alcune servono poi come riferimento generico per molti -programmi (come \var{EDITOR} che indica l'editor preferito da invocare in caso -di necessità). +alcune di esse (come \var{HOME}, \var{USER}, etc.) sono definite al login (per +i dettagli si veda \secref{sec:sess_login}). In genere è cura +dell'amministratore definire le opportune variabili di ambiente in uno script +di avvio. Alcune servono poi come riferimento generico per molti programmi +(come \var{EDITOR} che indica l'editor preferito da invocare in caso di +necessità). Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più -comuni), come riportato in \ntab. GNU/Linux le supporta tutte e ne definisce -anche altre: per una lista più completa si può controllare \cmd{man environ}. +comuni), come riportato in \tabref{tab:proc_env_var}. GNU/Linux le supporta +tutte e ne definisce anche altre: per una lista più completa si può +controllare \cmd{man environ}. \begin{table}[htb] \centering + \footnotesize \begin{tabular}[c]{|l|c|c|c|p{7cm}|} \hline \textbf{Variabile} & \textbf{POSIX} & \textbf{XPG3} @@ -1082,10 +1118,11 @@ Oltre a questa funzione di lettura, che C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema delle funzioni previste nei vari standard e disponibili in Linux è riportato -in \ntab. +in \tabref{tab:proc_env_func}. \begin{table}[htb] \centering + \footnotesize \begin{tabular}[c]{|l|c|c|c|c|c|c|} \hline \textbf{Funzione} & \textbf{ANSI C} & \textbf{POSIX.1} & \textbf{XPG3} & @@ -1108,9 +1145,9 @@ in \ntab. \label{tab:proc_env_func} \end{table} -In Linux solo le prime quattro funzioni di \curtab\ sono definite, -\func{getenv} l'abbiamo già esaminata; delle tre restanti le prime due, -\func{putenv} e \func{setenv}, servono per assegnare nuove variabili di +In Linux solo le prime quattro funzioni di \tabref{tab:proc_env_func} sono +definite, \func{getenv} l'abbiamo già esaminata; delle tre restanti le prime +due, \func{putenv} e \func{setenv}, servono per assegnare nuove variabili di ambiente, i loro prototipi sono i seguenti: \begin{functions} \headdecl{stdlib.h}