1 \chapter{L'interfaccia base con i processi}
2 \label{cha:process_interface}
4 Come accennato nell'introduzione il processo è l'unità di base con cui un
5 sistema unix alloca ed utilizza le risorse. Questo capitolo tratterà
6 l'interfaccia base fra il sistema e i processi, su come vengono passati i
7 parametri, come viene gestita e allocata la memoria, su come un processo può
8 richiedere servizi al sistema, su cosa deve fare quando ha finito la sua
11 In genere un programma viene eseguito quando un processo lo fa partire
12 eseguendo una funzione della famiglia \func{exec}; torneremo su questo e
13 sulla la creazione e gestione dei processi nel prossimo capitolo, in questo
14 affronteremo l'avvio e il funzionamento di un singolo processo partendo dal
15 punto di vista del programma posto in esecuzione.
19 \section{Esecuzione e conclusione di un programma}
21 Una delle concetti base relativi ai processi è che un processo esegue sempre
22 uno ed un solo programma: si possono avere più processi che eseguono lo stesso
23 programma ma ciascun processo vedrà la sua copia del codice (in realtà il
24 kernel fa si che tutte le parti uguali siano condivise) avrà un suo spazio di
25 indirizzi, variabili proprie e sarà eseguito in maniera completamente
26 indipendente da tutti gli altri.
28 Anche quando all'interno di un programma possono essere presenti più
29 \textsl{filoni} di esecuzione (i cosiddetti \textit{thread}), o questo possa
30 essere composto da moduli multipli completamente separati, quando questo sarà
31 posto in esecuzione esso apparirà al sistema come un solo processo (il
32 discorso dei \textit{thread} comunque in Linux necessita di una trattazione a
33 parte per la peculiarità dell'implementazione).
35 \subsection{La funzione \func{main}}
38 Quando un programma viene lanciato il kernel esegue una opportuna routine di
39 avvio, usando il programma \cmd{ld-linux.so}, è questo programma che prima
40 carica le librerie condivise che servono al programma, effettua il link
41 dinamico del codice e poi alla fine lo esegue. Infatti, a meno di non aver
42 specificato il flag \texttt{-static} durante la compilazione, tutti i
43 programmi in Linux sono incompleti e necessitano di essere linkati alle
44 librerie condivise quando vengono avviati. La procedura è controllata da
45 alcune variabili di ambiente e dal contenuto di \file{/etc/ld.so.conf}, i
46 dettagli sono riportati nella man page di \cmd{ld.so}.
48 Il sistema fa partire qualunque programma chiamando la funzione \func{main};
49 sta al programmatore chiamare così la funzione principale del programma da cui
50 si suppone iniziale l'esecuzione; in ogni caso senza questa funzione lo stesso
51 linker darebbe luogo ad errori.
53 Lo standard ISO C specifica che la funzione \func{main} può non avere
54 argomenti o prendere due argomenti che rappresentano gli argomenti passati da
55 linea di comando, in sostanza un prototipo che va sempre bene è il seguente:
56 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
57 int main (int argc, char *argv[])
60 In realtà nei sistemi unix esiste un'altro modo per definire la funzione
61 \func{main}, che prevede la presenza di un terzo parametro, \var{char
62 *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{sec:proc_environ})
63 del programma; questa forma però non è prevista dallo standard POSIX.1 per cui
64 se si vogliono scrivere programmi portabili è meglio evitarla.
67 \subsection{Come chiudere un programma}
68 \label{sec:proc_termination}
70 La via normale per la quale un programma finisce è quando la funzione
71 \func{main} ritorna, una modalità equivalente di conclusione è quella di
72 chiamare direttamente la funzione \func{exit} (che viene comunque chiamata
73 dalla routine di avvio del programma quando la funzione \func{main} ritorna).
74 Una forma alternativa è quella di chiamare direttamente la system call
75 \func{\_exit} che passa il controllo direttamente al kernel.
77 Oltre alla conclusione ``normale'' esiste anche la possibilità di una
78 conclusione ``anomala'' del programma a causa di segnali o della chiamata alla
79 funzione \func{abort} (che comunque genera un segnale che termina il
80 programma); torneremo su questo in \secref{sec:sig_prog_error}.
82 Il valore di ritorno della funzione main, o quello usato nelle chiamate ad
83 \func{exit} e \func{\_exit}, viene chiamato \textit{exit status} e passato
84 al processo padre che aveva lanciato il programma (in genere la shell). In
85 generale si usa questo valore per fornire un'informazione generica sulla
86 riuscita o il fallimento del programma; l'informazione è necessariamente
87 generica, ed il valore deve essere compreso fra 0 e 255.
89 In generale si usa la convenzione di restituire 0 in caso di successo e 1 in
90 caso di fallimento, i programmi che effettuano dei confronti (come
91 \cmd{diff}) usano invece una notazione leggermente diversa, usando 0 per
92 indicare la corrispondenza, 1 per indicare la non corrispondenza e 2 per
93 indicare l'incapacità di effettuare il confronto. È opportuno adottare una di
94 queste convenzioni a seconda dei casi. Si tenga presente che se si raggiunge
95 la fine della funzione \func{main} senza ritornare esplicitamente si ha un
96 valore di uscita indefinito, è pertanto consigliabile di concludere sempre in
97 maniera esplicita detta funzione.
99 Una altra convenzione riserva i valori da 128 in su per usi speciali, ad
100 esempio 128 viene usato per indicare l'incapacità di eseguire un altro
101 programma in un sottoprocesso. Benché anche questa convenzione non sia
102 universalmente seguita è una buona idea tenerne conto.
104 Si tenga presente inoltre che non è una buona idea usare il valore dell'errore
105 restituito dalla variabile \var{errno} come stato di uscita, in generale
106 una shell non si cura di tutto questo e comunque il valore dello stato di
107 uscita è sempre troncato ad 8 bit, per cui si potrebbe incorrere nel caso in
108 cui l'errore 256, diventando zero, verrebbe interpretato come un successo. In
109 \file{stdlib.h} sono definite due macro \macro{EXIT\_SUCCESS} e
110 \macro{EXIT\_FAILURE}, che in Linux sono poste rispettivamente ai valori 0 e
111 1 (di tipo \type{int}), seguendo lo standard POSIX.
113 Infine occorre distinguere fra lo stato di uscita di un programma
114 (l'\textit{exit status}) e lo stato di conclusione di un processo (il
115 \textit{termination status}), abbiamo già accennato infatti che è comunque
116 possibile un processo possa essere terminato (da un segnale) prima che il
117 programma in esecuzione si sia concluso. In caso di conclusione normale del
118 programma però lo stato di uscita diventa parte dello stato di conclusione del
119 processo (vedi \secref{sec:proc_xxx}).
122 \subsection{Le funzioni \func{exit} e \func{\_exit}}
123 \label{sec:proc_exit}
125 Come accennato funzioni per l'uscita ``normale'' da un programma sono due, la
126 prima è la funzione \func{exit} che è definita dallo standard ANSI C; il
127 prototipo della funzione è il seguente:
128 \begin{prototype}{stdlib.h}{void exit(int status)}
129 Causa la conclusione ordinaria del programma restituendo il valore
130 \var{status} al processo padre.
132 La funzione non ritorna. Il processo viene terminato
135 La funzione \func{exit} è pensata per una conclusione pulita di un programma
136 che usa le librerie standard del C; essa esegue tutte le funzioni che sono
137 state registrate con \func{atexit} e \func{on\_exit} (vedi
138 \secref{sec:proc_atexit}), e chiude tutti gli stream di I/O effettuando il
139 salvataggio dei dati sospesi (chiamando \func{fclose}, vedi
140 \secref{sec:file_fclose}), infine ripassa il controllo al kernel chiamando
141 \func{\_exit} e passando il valore \var{status} come stato di uscita.
143 La system call \func{\_exit} restituisce direttamente il controllo al
144 kernel, concludendo immediatamente il processo, le eventuali funzioni
145 registrate con \func{atexit} e \func{on\_exit} non vengono eseguite. Il
146 prototipo della funzione è il seguente:
147 \begin{prototype}{unistd.h}{void \_exit(int status)}
148 Causa la conclusione immediata del programma restituendo il valore
149 \var{status} al processo padre.
151 La funzione non ritorna. Il processo viene terminato.
154 La funzione chiude tutti i file descriptor appartenenti al processo (sui tenga
155 presente che questo non comporta il salvataggio dei dati bufferizzati degli
156 stream), fa si che ogni figlio del processo sia ereditato da \cmd{init}
157 (vedi \secref{cha:process_handling}), manda un segnale \macro{SIGCHLD} al
158 processo padre (vedi \ref{sec:sig_job_control}) ed infine ritorna lo stato di
159 uscita specificato in \var{status} che può essere raccolto usando la
160 funzione \func{wait} (vedi \secref{sec:proc_wait}).
163 \subsection{Le funzioni \func{atexit} e \func{on\_exit}}
164 \label{sec:proc_atexit}
166 Come accennato l'uso di \func{exit} al posto della \func{\_exit} è fatto
167 principalmente per permettere una uscita pulita dalle funzioni delle librerie
168 standard del C (in particolare per quel che riguarda la chiusura degli
171 Quando si realizza una libreria da usare in varie applicazioni può essere
172 perciò utile evitare di richiedere di chiamare esplicitamente un funzione di
173 uscita che esegua tutte le operazioni di pulizia prima di uscire (come quella
174 di salvare eventuali dati sospesi). È invece molto meno soggetto ad errori e
175 completamente trasparente all'utente poter effettuare una chiamata automatica
176 di una funzione che effettui tali operazioni all'uscita dal programma.
178 A questo scopo lo standard ANSI C prevede la possibilità di registrare un
179 certo numero funzioni che verranno eseguite all'uscita dal programma (sia per
180 la chiamata ad \func{exit} che per il ritorno di \func{main}). La prima
181 funzione che si può utilizzare a tal fine è:
182 \begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
183 Registra la funzione \var{function} per essere chiamata all'uscita dal
186 La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
187 \texttt{errno} non viene settata.
190 La funzione richiede come argomento l'indirizzo della opportuna da chiamare
191 all'uscita che non deve prendere argomenti e non deve ritornare niente. Una
192 estensione di \func{atexit} è la funzione \func{on\_exit} (che la glibc
193 include per compatibilità con SunOS e che non è detto sia definita su altri
194 sistemi), il cui prototipo è:
195 \begin{prototype}{stdlib.h}
196 {void on\_exit(void (*function)(int status, void *arg), void *arg)}
197 Registra la funzione \var{function} per essere chiamata all'uscita dal
198 programma. Tutte le funzioni registrate vengono chiamate in ordine inverso
199 rispetto a quello di registrazione.
201 La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
202 \var{errno} non viene settata.
205 In questo caso la funzione da chiamare prende due parametri, il primo dei
206 quali sarà inizializzato allo stato di uscita con cui è stata chiamata
207 \func{exit} ed il secondo al puntatore generico specificato come secondo
208 argomento nella chiamata di \func{on\_exit}.
210 Nella sequenza di chiusura tutte le funzioni registrate verranno chiamate in
211 ordine inverso rispetto a quello di registrazione (ed una stessa funzione
212 registrata più volte sarà chiamata più volte); poi verranno chiusi tutti gli
213 stream aperti, infine verrà chiamata \func{\_exit}.
216 \subsection{Conclusioni}
217 \label{sec:proc_term_conclusion}
219 Data l'importanza dell'argomento è opportuno sottolineare ancora una volta che
220 in un sistema unix l'unico modo in cui un programma può essere eseguito dal
221 kernel è attraverso la chiamata alla system call \func{execve} (in genere
222 attraverso una delle funzioni \func{exec} che vedremo in
223 \secref{sec:proc_exec}).
225 Allo stesso modo l'unico modo in cui un programma può concludere
226 volontariamente la sua esecuzione è attraverso una chiamata alla system call
227 \func{\_exit} sia esplicitamente o che in maniera indiretta attraverso l'uso
228 di \func{exit} o il ritorno della funzione \func{main}.
230 Lo schema delle modalità con cui si avvia e conclude normalmente un programma
231 è riportato in \nfig.
236 \caption{Schema dell'avvio e della conclusione di un programma.}
237 \label{fig:proc_prog_start_stop}
240 Si ricordi infine che un programma può anche essere interrotto dall'esterno
241 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
242 \curfig); torneremo su questo aspetto in \secref{cha:signals}.
246 \section{I processi e l'uso della memoria}
247 \label{sec:proc_memory}
249 Una delle risorse base che ciascun processo ha a disposizione è la memoria, ed
250 uno degli aspetti più complessi di un sistema unix (ed in particolar modo di
251 Linux) è appunto la gestione della memoria. Qui ci occuperemo però di come la
252 memoria viene vista dal punto di vista di un programma in esecuzione in un
256 \subsection{I concetti generali}
257 \label{sec:proc_mem_gen}
259 Ci sono vari modi in cui i vari sistemi organizzano la memoria (ed i dettagli
260 di basso livello dipendono in maniera diretta dall'architettura
261 dell'hardware), ma quello più tipico, usato da unix (e da Linux) è quello di
262 assegnare ad ogni processo uno spazio virtuale di indirizzamento lineare in
263 cui gli indirizzi vanno da zero ad un qualche valore massimo (nel caso di
264 Linux fino al kernel 2.2 detto massimo era per macchine a 32bit di 2Gb, con il
265 kernel 2.4 il limite è stato esteso).
267 Come accennato nell'introduzione questo spazio di indirizzi è virtuale e non
268 corrisponde all'effettiva posizione dei dati nella RAM del computer; in genere
269 detto spazio non è neanche continuo (cioè non tutti gli indirizzi sono
270 utilizzabili e/o utilizzati).
272 La memoria virtuale viene divisa in pagine di dimensione fissa (che ad esempio
273 sono di 4kb su macchine a 32 bit e 8kb sulle alpha, valori strettamente
274 connessi all'hardware di gestione della memoria), e ciascuna pagina della
275 memoria virtuale è associata ad un supporto che può essere una pagina di
276 memoria reale o ad un dispositivo di stoccaggio secondario (in genere lo
277 spazio disco riservato alla swap, o i file che contengono il codice).
279 Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a
280 diverse pagine di memoria virtuale appartenenti a processi diversi (come
281 accade in genere per le pagine che contengono il codice delle librerie
282 condivise). Ad esempio il codice della funzione \func{printf} starà su una
283 sola pagina di memoria reale che farà da supporto a tutte le pagine di memoria
284 virtuale di tutti i processi hanno detta funzione nel loro codice.
286 La corrispondenza fra le pagine della memoria virtuale e quelle della memoria
287 fisica della macchina viene gestita in maniera trasparente dall'hardware di
288 gestione della memoria (la \textit{Memory Management Unit} del processore),
289 ma poiché in genere quest'ultima è solo una piccola frazione della memoria
290 virtuale è necessario un meccanismo che permetta di trasferire le pagine
291 virtuali che servono dal supporto su cui si trovano in memoria, eliminando
292 quelle che non servono. Questo meccanismo è detto \textit{paging}, ed è uno
293 dei compiti principali del kernel.
295 Quando un processo cerca di accedere ad una pagina che non è nella memoria
296 reale, avviene quello che viene chiamato un \textit{page fault}; l'hardware di
297 gestione della memoria (la MMU del processore) genera una interruzione e passa
298 il controllo al kernel il quale sospende il processo e si incarica di mettere
299 in RAM la pagina richiesta (effettuando tutte le operazioni necessarie per
300 reperire lo spazio necessario), per poi restituire il controllo al
303 Dal punto di vista di un processo questo meccanismo è completamente
304 trasparente e tutto avviene come se tutte le pagine fossero sempre disponibili
305 in memoria. L'unica differenza avvertibile è quella dei tempi di esecuzione,
306 che passano dai pochi nanosecondi necessari per l'accesso a tempi molto più
307 lunghi, dovuti all'intervento del kernel. Normalmente questo è il prezzo da
308 pagare per avere un multitasking reale, ed in genere il sistema è molto
309 efficiente in questo lavoro; quando però ci siano esigenze specifiche di
310 prestazioni è possibile usare delle funzioni che permettono di bloccare il
311 meccanismo del paging e mantenere fisse delle pagine in memoria (vedi
312 \ref{sec:proc_mem_lock}).
315 \subsection{La struttura della memoria di un processo}
316 \label{sec:proc_mem_layout}
318 Benché lo spazio di indirizzi virtuali copra un intervallo molto ampio, solo
319 una parte di essi è effettivamente allocato ed utilizzabile dal processo; il
320 tentativo di accedere ad un indirizzo non allocato è un tipico errore che si
321 commette quando si è manipolato male un puntatore e genera quello che viene
322 chiamato un \textit{segmentation fault}. Se si tenta cioè di leggere o
323 scrivere da un indirizzo per il quale non esiste una associazione della pagina
324 virtuale il kernel risponde al relativo \textit{page fault}, mandando un
325 segnale \macro{SIGSEGV} al processo, che normalmente ne causa la terminazione
328 È pertanto importante capire come viene strutturata la memoria virtuale di un
329 processo; essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
330 indirizzi virtuali ai quali il processo può accedere. Solitamente un
331 programma C viene suddiviso nei seguenti segmenti:
334 \item Il segmento di testo (\textit{text segment}). Contiene il codice
335 macchina del programma e le costanti statiche. Normalmente viene condiviso,
336 in modo che più processi (anche diversi nel caso di librerie) possano
337 utilizzarlo, e viene marcato in sola lettura per evitare sovrascritture
338 accidentali (o maliziose) che ne modifichino le istruzioni.
340 Viene allocato da \func{exec} all'avvio del programma e resta invariato
341 per tutto il tempo dell'esecuzione.
343 \item Il segmento dei dati (\textit{data segment}). Contiene le variabili
344 globali (cioè quelle definite al di fuori di tutte le funzioni). Di norma è
347 La prima parte è il segmento dei dati inizializzati, che contiene le
348 variabili globali il cui valore è stato assegnato esplicitamente. Ad esempio
350 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
353 questo valore sarà immagazzinato in questo segmento. La memoria di questo
354 segmento viene preallocato dalla \func{exec} e inizializzata ai valori
357 La seconda parte è il segmento dei dati non inizializzati, che contiene le
358 variabili globali il cui valore è stato non è assegnato esplicitamente. Ad
359 esempio se si definisce:
360 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
363 questo valore sarà immagazzinato in questo segmento. Anch'esso viene
364 allocato all'avvio, e tutte le variabili vengono inizializzate a
365 zero (ed i puntatori a \macro{NULL}).
367 Storicamente questo segmento viene chiamato BBS (da \textit{block started by
368 symbol}. La sua dimensione è fissa.
370 \item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del
371 segmento dati, a cui di solito è posto giusto di seguito. È qui che avviene
372 l'allocazione dinamica della memoria; può essere ridimensionato allocando e
373 disallocando la memoria dinamica con le apposite funzioni (vedi
374 \secref{sec:proc_mem_alloc}), ma il suo limite inferiore (quello adiacente
375 al segmento dati) ha una posizione fissa.
377 \item Il segmento di \textit{stack}, che contiene lo \textit{stack} del
378 programma. Tutte le volte che si effettua una chiamata ad una funzione è
379 qui che viene salvato l'indirizzo di ritorno e le informazioni dello stato
380 del chiamante (tipo il contenuto di alcuni registri della CPU); poi la
381 funzione chiamata alloca qui lo spazio per le sue variabili locali, in
382 questo modo le funzioni possono essere chiamate ricorsivamente. Al ritorno
383 della funzione lo spazio è automaticamente rilasciato.
385 La dimensione di questo segmento aumenta seguendo la crescita dello stack
386 del programma, ma non viene ridotta quando quest'ultimo si restringe.
391 \includegraphics[width=5cm]{img/memory_layout.eps}
392 \caption{Disposizione tipica dei segmenti di memoria di un processo}
393 \label{fig:proc_mem_layout}
396 Una disposizione tipica di questi segmenti è riportata in \nfig. Usando il
397 comando \cmd{size} su un programma se ne può stampare le dimensioni dei
398 segmenti di testo e di dati (inizializzati e BSS); il BSS però non è mai
399 salvato sul file, in quanto viene inizializzato a zero al caricamento del
403 \subsection{Allocazione della memoria per i programmi C}
404 \label{sec:proc_mem_alloc}
406 Il C supporta due tipi di allocazione della memoria, l'allocazione statica è
407 quella in cui vanno le variabili globali e le variabili statiche (e viene
408 effettuata nel segmento dei dati), lo spazio per queste variabili viene
409 allocati all'avvio del programma (come parte delle operazioni svolte da
410 \func{exec}) e non viene liberato fino alla sua conclusione.
412 L'allocazione automatica è quella che avviene per le cosiddette variabili
413 automatiche, cioè gli argomenti delle funzioni o le variabili locali. Lo
414 spazio per queste variabili viene allocato nello stack quando viene eseguito
415 comando di invocazione della funzione e liberato quando si esce dalla
418 Esiste però un terzo tipo di allocazione, che non è prevista dal linguaggio C,
419 che è l'allocazione dinamica della memoria, necessaria quando il quantitativo
420 di memoria che serve è determinabile solo in corso di esecuzione del
423 Il C non consente di usare variabili allocate dinamicamente, non è possibile
424 cioè definire in fase di programmazione una variabile le cui dimensioni
425 possano essere modificate durante l'esecuzione del programma; però le librerie
426 del C forniscono una serie opportuna di funzioni per permettere l'allocazione
427 dinamica di spazio in memoria (in genere nello heap, usando la system call
428 \func{sbrk}), solo che a questo punto detto spazio sarà accessibile solo in
429 maniera indiretta attraverso dei puntatori.
432 \subsection{Le funzioni \func{malloc}, \func{calloc}, \func{realloc} e
434 \label{sec:proc_mem_malloc}
436 Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
437 quattro, i prototipi sono i seguenti:
440 \funcdecl{void *calloc(size\_t size)}
441 Alloca \var{size} bytes nello heap. La memoria viene inizializzata a 0.
443 La funzione restituisce il puntatore alla zona di memoria allocata in caso
444 di successo e \macro{NULL} in caso di fallimento, nel qual caso
445 \var{errno} viene settata a \macro{ENOMEM}.
446 \funcdecl{void *malloc(size\_t size)}
447 Alloca \var{size} bytes nello heap. La memoria non viene inizializzata.
449 La funzione restituisce il puntatore alla zona di memoria allocata in caso
450 di successo e \macro{NULL} in caso di fallimento, nel qual caso
451 \var{errno} viene settata a \macro{ENOMEM}.
452 \funcdecl{void *realloc(void *ptr, size\_t size)}
453 Cambia la dimensione del blocco allocato all'indirizzo \var{ptr}
454 portandola a \var{size}.
456 La funzione restituisce il puntatore alla zona di memoria allocata in caso
457 di successo e \macro{NULL} in caso di fallimento, nel qual caso
458 \var{errno} viene settata a \macro{ENOMEM}.
459 \funcdecl{void free(void *ptr)}
460 Disalloca lo spazio di memoria puntato da \var{ptr}.
462 La funzione non ritorna nulla.
464 Il puntatore che le funzioni di allocazione ritornano è garantito essere
465 sempre correttamente allineato per tutti i tipi di dati; ad esempio sulle
466 macchine a 32 bit in genere è allineato a multipli di 4 byte e sulle macchine
467 a 64 bit a multipli di 8 byte.
469 In genere su usano le funzioni \func{malloc} e \func{calloc} per allocare
470 dinamicamente la memoria necessaria al programma, siccome i puntatori
471 ritornati sono di tipo generico non è necessario effettuare un cast per
472 assegnarli a puntatori al tipo di variabile per la quale si effettua la
475 La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando
476 \func{free}\footnote{le glibc provvedono anche una funzione \func{cfree}
477 defininita per compatibilità con SunOS, che è deprecata} una volta che non
478 sia più necessaria. Questa funzione vuole come parametro un puntatore
479 restituito da una precedente chiamata a una qualunque delle funzioni di
480 allocazione e che non sia già stato liberato da un'altra chiamata a
481 \func{free}, in caso contrario il comportamento della funzione è indefinito.
483 La funzione \func{realloc} si usa invece per cambiare (in genere aumentare)
484 la dimensione di un'area di memoria precedentemente allocata, la funzione
485 vuole in ingresso il puntatore restituito dalla precedente chiamata ad una
486 \func{malloc} (se è passato un valore \macro{NULL} allora la funzione si
487 comporta come \func{malloc}\footnote{questo è vero per linux e
488 l'implementazione secondo lo standard ANSI C, ma non è vero per alcune
489 vecchie implementazioni, inoltre alcune versioni delle librerie del C
490 consentivano di usare \func{realloc} anche per un puntatore liberato con
491 \func{free} purché non ci fossero state altre chiamate a funzioni di
492 allocazione, questa funzionalità è totalmente deprecata e non è consentita
493 sotto linux}), ad esempio quando si deve far crescere la dimensione di un
494 vettore; in questo caso se è disponibile dello spazio adiacente al precedente
495 la funzione lo utilizza, altrimenti rialloca altrove un blocco della dimensione
496 voluta copiandoci automaticamente il contenuto, lo spazio in più non viene
499 Il fatto che il blocco di memoria restituito da \func{realloc} possa
500 cambiare comporta che si deve sempre riassegnare al puntatore passato per il
501 ridimensionamento il valore di ritorno della funzione, e che non ci devono
502 essere altri puntatori che puntino all'interno di un'area che si vuole
505 Uno degli errori più comuni (specie se si ha a che fare con array di
506 puntatori) è infatti quello di chiamare \func{free} più di una volta sullo
507 stesso puntatore; per evitare questo problema una soluzione di ripiego è
508 quella di assegnare sempre a \macro{NULL} ogni puntatore liberato con
509 \func{free}, dato che, quando il parametro è un puntatore nullo,
510 \func{free} non esegue nessuna operazione.
512 Linux e le glibc hanno una implementazione delle routine di allocazione che è
513 controllabile dall'utente attraverso alcune variabili di ambiente, in
514 particolare diventa possibile tracciare questo tipo di errori usando la
515 variabile \macro{MALLOC\_CHECK\_} che quando viene settata mette in uso una
516 versione meno efficiente delle funzioni, che però è più tollerante nei
517 confronti di piccoli errori come quello di chiamate doppie a \func{free}; in
520 \item se la variabile è posta a zero gli errori vengono ignorati.
521 \item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
522 (vedi \secref{sec:file_stdfiles}).
523 \item se è posta a 2 viene chiamata \func{abort}, che in genere causa
524 l'immediata conclusione del programma.
527 Il problema più comune e più difficile da tracciare che si incontra con
528 l'allocazione della memoria è però quando la memoria non più utilizzata non
529 viene opportunamente liberata (quello che in inglese viene chiamato
530 \textit{memory-leak}, traducibile come \textsl{perdita di memoria}).
532 Un caso tipico è quando l'allocazione viene fatta da una subroutine per un uso
533 locale, ma la memoria non viene liberata una volta usata; chiamate ripetute
534 alla stessa subroutine causeranno a lungo andare un esaurimento della memoria
535 disponibile, con un conseguente crash dell'applicazione che può avvenire in
536 qualunque momento, e senza nessuna relazione con la subroutine che contiene
539 Per questo motivo l'implementazione delle routine di allocazione delle glibc
540 mette a disposizione una serie di funzionalità (su cui torneremo in
541 \secref{sec:xxx_advanced}) che permettono di tracciare le allocazioni e
542 le disallocazione, e definisce anche una serie di possibili agganci che
543 permettono di sostituire alle funzioni di libreria una propria versione (che
544 può essere più o meno specializzata per il debugging).
547 \subsection{La funzione \texttt{alloca}}
548 \label{sec:proc_mem_alloca}
550 Una alternativa possibile all'uso di \texttt{malloc}, che non soffre del tipo
551 di problemi di memory leak descritti in precedenza è la funzione
552 \texttt{alloca} che invece che allocare la memoria nello heap usa lo il
553 segmento di stack della funzione corrente. La sintassi è identica:
554 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
555 Alloca \texttt{size} bytes nel segmento di stack della funzione chiamante.
556 La memoria non viene inizializzata.
558 La funzione restituisce il puntatore alla zona di memoria allocata in caso
559 di successo e \texttt{NULL} in caso di fallimento, nel qual caso
560 \texttt{errno} viene settata a \texttt{ENOMEM}.
562 ma in questo caso non è più necessario liberare la memoria in quanto questa
563 viene rilasciata automaticamente al ritorno della funzione.
565 Come è evidente questa funzione ha molti vantaggi, e permette di evitare i
566 problemi di memory leak non essendo più necessaria la deallocazione esplicita;
567 una delle ragioni principali per usarla è però che funziona anche quando si
568 usa \func{longjump} per uscire con un salto non locale da una funzione (vedi
569 \secref{sec:proc_longjmp}),
571 Un altro vantaggio e che in Linux la funzione è molto veloce e non viene
572 sprecato spazio, infatti non è necessario gestire un pool di memoria da
573 riservare e si evitano anche problemi di frammentazione.
575 Gli svantaggi sono che la funzione non è disponibile su tutti gli unix, quando
576 non è possibile aumentare le dimensioni dello stack una volta chiamata una
577 funzione e quindi l'uso limita la portabilità dei programmi, inoltre se si
578 cerca di allocare troppa memoria non si ottiene un messaggio di errore, ma un
579 segnale di \textit{segmentation violation} analogo a quello che si avrebbe da
580 una ricorsione infinita.
582 Inoltre non è chiaramente possibile usare questa funzione per allocare memoria
583 che deve poi essere usata anche al di fuori della funzione in cui questa viene
584 chiamata, in quanto all'uscita dalla funzione lo spazio allocato diventerebbe
585 libero, e potrebbe essere sovrascritto all'invocazione di nuove funzioni con
586 conseguenze imprevedibili.
588 Questo è lo stesso problema potenziale che si può avere con le variabili
589 automatiche; un errore comune infatti è quello di restituire al chiamante un
590 puntatore ad una di queste variabili, che sarà automaticamente distrutta
591 all'uscita della funzione, con gli stessi problemi appena citati per
594 \subsection{Le funzioni \texttt{brk} e \texttt{sbrk}}
595 \label{sec:proc_mem_sbrk}
597 L'uso di queste funzioni è necessario solo quando si voglia accedere alle
598 analoghe system call a cui fanno da interfaccia (ad esempio per implementare
599 una propria versione di \texttt{malloc}. Le funzione sono:
600 \begin{prototype}{unistd.h}{int *brk(void end\_data\_segment)}
601 Sposta la fine del segmento dei dati all'indirizzo specificato da
602 \texttt{end\_data\_segment}.
604 La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
605 nel qual caso \texttt{errno} viene settata a \texttt{ENOMEM}.
607 \begin{prototype}{unistd.h}{int *sbrk(ptrdiff\_t increment)}
608 Incrementa lo spazio dati di un programma di \texttt{increment}. Un valore
609 zero restituisce l'attuale posizione della fine del segmento dati.
611 La funzione restituisce il puntatore all'inizio della nuova zona di memoria
612 allocata in caso di successo e \texttt{NULL} in caso di fallimento, nel qual
613 caso \texttt{errno} viene settata a \texttt{ENOMEM}.
616 Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
617 per i programmi normali è opportuno usare le funzioni di allocazione standard
618 descritte in precedenza, che sono costruite su di esse. In genere si usa
619 \texttt{sbrk} con un valore zero per ottenere l'attuale posizione della fine
623 % \subsection{La personalizzazione delle funzioni di allocazione}
624 % \label{sec:proc_mem_malloc_custom}
627 \subsection{Il controllo della memoria virtuale}
628 \label{sec:proc_mem_lock}
630 Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria in
631 maniera trasparente ai processi, decidendo quando rimuovere pagine dalla
632 memoria per metterle nello swap sulla base dell'utilizzo corrente da parte dei
635 Nell'uso comune un processo non deve preoccuparsi di tutto ciò in quanto il
636 meccanismo della paginazione riporta in RAM, ed in maniera trasparente, tutte
637 le pagine che gli occorrono; esistono però esigenze particolari in cui non si
638 vuole che il meccanismo dello \textit{swapping}, in generale i motivi per cui
639 si possono avere queste necessità sono sostanzialmente due:
641 \item La velocità. Il processo della paginazione è trasparente solo se il
642 programma in esecuzione se non è sensibile al tempo che occorre a riportare
643 la pagina in memoria; per questo motivi processi critici che hanno esigenze
644 di tempo reale o tolleranze critiche nella risposte (ad esempio processi che
645 trattano campionamenti sonori) possono non essere in grado di sopportare
646 le variazioni della velocità di accesso dovuta alla paginazione.
648 In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
649 allocazione delle pagine le esigenze specifiche del suo programma e decidere
650 quali pagine di memoria è opportuno che restino in memoria per un aumento
651 delle prestazioni. In genere queste sono esigenze particolari e richiedono
652 anche un aumento delle priorità in esecuzione (vedi \secref{sec:xxx_xxx}).
654 \item La sicurezza. Se si tengono password o chiavi in memoria queste possono
655 essere portate su disco dal meccanismo della paginazione, questo rende più
656 lungo il periodo di tempo in cui i segreti sono presenti in chiaro, e
657 complessa la loro cancellazione (in genere è possibile cancellare della RAM
658 ma altrettanto non vale per il disco su cui la pagina contenente i segreti
659 può essere stata salvata). Per questo motivo programmi di crittografia
660 richiedono il blocco di alcune pagine di memoria.
663 Il meccanismo che previene la paginazione di parte della memoria virtuale di
664 un processo è chiamato \textit{memory locking} (blocco della memoria), il
665 blocco è sempre associato alle pagine della memoria virtuale del processo, non
666 con il segmento reale di RAM su cui essa viene mantenuta.
668 La regola è che se un segmento di RAM fa da supporto ad almeno una pagina
669 bloccata allora esso viene escluso dal meccanismo della paginazione. I blocchi
670 non si accumulano, se si blocca due volte la stessa pagina non è necessario
671 sbloccarla due volte, una pagina o è bloccata o no.
673 Il blocco di memoria persiste fintanto che il processo che lo detiene la
674 memoria bloccata non la sblocca. Chiaramente la terminazione del processo
675 comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
676 tutti i blocchi di memoria.
678 I memory lock non sono ereditati dai processi figli\footnote{ma siccome Linux
679 usa il copy on write gli indirizzi virtuali del figlio sono mantenuti sullo
680 stesso segmento di RAM del padre, quindi usufruiscono dei memory lock di
681 questo}. Siccome la presenza di memory lock ha un impatto sugli altri
682 processi solo root ha la capacità di bloccare una pagina, ogni processo può
683 però sbloccare le sue pagine. Il sistema pone dei limiti all'ammontare di
684 memoria di un processo che può essere bloccata e al totale di memoria fisica
685 che può dedicare a questo.
688 \section{Il controllo di flusso non locale}
689 \label{sec:proc_longjmp}
691 Il controllo del flusso di un programma in genere viene effettuato con le
692 varie istruzioni del linguaggio C, la più bistrattata delle quali è il
693 \texttt{goto}, ampiamente deprecato in favore di costrutti più puliti; esiste
694 però un caso in l'uso di questa istruzione porta all'implementazione più
695 efficiente, quello dell'uscita in caso di errore.
697 Il C però non consente di effettuare un salto ad una label definita in
698 un'altra funzione, per cui se l'errore avviene in funzioni profondamente
699 annidate occorre usare la funzione \func{longjump}.
702 \section{La gestione di parametri e opzioni}
703 \label{sec:proc_options}
705 Il passaggio dei parametri e delle variabili di ambiente dalla riga di comando
706 al singolo programma quando viene lanciato è effettuato attraverso le
707 variabili \var{argc}, \var{argv} che vengono passate al programma
708 come argomenti della funzione principale.
710 \subsection{Il formato dei parametri}
711 \label{sec:proc_par_format}
712 In genere passaggio dei parametri al programma viene effettuato dalla shell,
713 che si incarica di leggere la linea di comando e di effettuarne la scansione
714 (il cosiddetto \textit{parsing}) per individuare le parole che la compongono,
715 ciascuna delle quali viene considerata un parametro; di default per
716 individuare le parole viene usato come separatore lo spazio (comportamento
717 modificabile attraverso il settaggio della variabile di ambiente IFS).
719 Nella scansione viene costruito il vettore di puntatori \var{argv} inserendo
720 in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
721 variabile \var{argc} viene inizializzata al numero di parametri trovati, in
722 questo modo il primo parametro è sempre il nome del programma (vedi \nfig).
724 \subsection{La gestione delle opzioni}
725 \label{sec:proc_opt_handling}
727 In generale un programma unix riceve da linea di comando sia i parametri che
728 le opzioni, queste ultime sono standardizzate per essere riconosciute come
729 tali: un elemento di \var{argv} che inizia con \texttt{-} e che non sia un
730 singolo \texttt{-} o \texttt{--} viene considerato un'opzione. In in genere
731 le opzioni sono costituite da una lettera preceduta dal meno e possono avere o
732 no un parametro associato; un comando tipico può essere cioè qualcosa del
735 touch -r riferimento.txt -m questofile.txt
737 ed in questo caso le opzioni sono \texttt{m} ed \texttt{r}.
739 Per gestire le opzioni all'interno dei parametri passati in \func{argv} le
740 librerie standard del C forniscono la funzione \func{getopt} che ha il
742 \begin{prototype}{unistd.h}
743 {int getopt(int argc, char * const argv[], const char * optstring)}
744 La funzione esegue il parsing degli argomenti passati da linea di comando
745 riconoscendo le possibili opzioni segnalate con \var{optstring}.
747 Ritorna il carattere che segue l'opzione, \cmd{:} se manca un paramatro
748 all'opzione, \cmd{?} se l'opzione è sconosciuta, e -1 se non esistono altre
752 Questa funzione prende come argomenti le due variabili \var{argc} e
753 \var{argv} ed una stringa che indica quali sono le opzioni valide; la
754 funzione effettua la scansione della lista dei parametri ricercando ogni
755 stringa che comincia con \cmd{-} e ritorna ogni volta che trova una opzione
758 La stringa \var{optstring} indica quali sono le opzioni riconosciute ed è
759 costituita da tutti i caratteri usati per identificare le singole opzioni, se
760 l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
761 due punti \texttt{:} nel caso appena accennato ad esempio la stringa di
762 opzioni sarebbe \texttt{"r:m"}.
764 La modalità di uso è pertanto quella di chiamare più volte la funzione
765 all'interno di un ciclo di while fintanto che essa non ritorna il valore
766 \texttt{-1} che indica che non ci sono più opzioni. Nel caso si incontri
767 un'opzione non dichiarata in \texttt{optstring} viene ritornato un \texttt{?}
768 mentre se l'opzione non è seguita da un parametro viene ritornato un
769 \texttt{:} infine se viene incontrato il valore \texttt{--} la scansione viene
770 considerata conclusa, anche se vi sono altri parametri che cominciano con
773 Quando la funzione trova un'opzione essa ritorna il valore numerico del
774 carattere, in questo modo si possono prendere le azioni relative usando un
775 case; la funzione inizializza inoltre alcune variabili globali:
777 \item \texttt{char * optarg} contiene il puntatore alla stringa argomento
779 \item \texttt{int optind} alla fine della scansione restituisce l'indice del
780 primo argomento che non è un'opzione.
781 \item \texttt{int opterr} previene, se posto a zero, la stampa di un messaggio
782 di errore in caso di riconoscimento di opzioni non definite.
783 \item \texttt{int optopt} contiene il carattere dell'opzione non riconosciuta.
786 In \nfig\ è mostrato un programma di esempio:
790 opterr = 0; /* don't want writing to stderr */
791 while ( (i = getopt(argc, argv, "o:a:i:hve")) != -1) {
793 case 'i': /* input file */
794 in_file=open(optarg,O_RDONLY);
796 perror("Cannot open input file");
800 case 'o': /* output file (overwrite) */
801 out_file=open(optarg,O_WRONLY|O_CREAT);
803 perror("Cannot open output file");
808 case 'a': /* output file (append) */
809 out_file=open(optarg,O_WRONLY|O_CREAT|O_APPEND);
811 case 'h': /* print help usage */
814 case 'v': /* set verbose mode */
815 debug("Option -v active\n");
818 case '?': /* unrecognized options */
819 printf("Unrecognized options -%c\n",optopt);
821 default: /* should not reached */
822 debug("default option\n");
826 debug("Optind %d, argc %d\n",optind,argc);
828 \caption{Esempio di codice per la gestione delle opzioni.}
829 \label{fig:proc_options_code}
832 \subsection{Opzioni in formato esteso}
833 \label{sec:proc_opt_extended}
835 Un'estensione di questo schema è costituito dalle cosiddette
836 \textit{long-options} espresse nella forma \texttt{--option=parameter}, anche
837 la gestione di queste ultime è stata standardizzata attraverso l'uso di una
838 versione estesa di \func{getopt}.
842 \subsection{Le variabili di ambiente}
843 \label{sec:proc_environ}
845 Oltre ai parametri passati da linea di comando ogni processo riceve dal
846 sistema un \textsl{ambiente}, nella forma di una lista di variabili
847 (\textit{environment list}) messa a disposizione dal processo costruita nella
848 chiamata ad \func{exec} che lo ha lanciato.
850 Come per la lista dei parametri anche questa lista è un array di puntatori a
851 caratteri, ciascuno dei quali punta ad una stringa (terminata da un null). A
852 differenza di \var{argv[]} però in questo caso non si ha la lunghezza
853 dell'array dato da un equivalente di \var{argc}, ma la lista è terminata da un
856 L'indirizzo della lista delle variabili di ambiente è passato attraverso la
857 variabile globale \var{environ}, a cui si può accedere attraverso una semplice
858 dichiarazione del tipo:
859 \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
860 extern char ** environ;
862 un esempio del contenuto dell'ambiente, in si è riportato un estratto delle
863 variabili che normalmente sono definite dal sistema, è riportato in \nfig.
866 \includegraphics[width=11cm]{img/environ_var.eps}
867 \caption{Esempio di lista delle variabili di ambiente.}
868 \label{fig:proc_envirno_list}
871 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
872 \textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate
873 in \curfig, sono definite dal sistema per queste c'è la convezione di usare
874 nomi espressi in caratteri maiuscoli.
876 Il kernel non usa mai queste variabili, il loro uso e la loro intepretazione è
877 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
878 costituiscono un modo comodo per definire un comportamento specifico senza
879 dover ricorrere all'uso di opzioni a linea di comando o di file di
882 La shell ad esempio ne usa molte per il suo funzionamento (come \var{PATH} per
883 la ricerca dei comandi), e alcune di esse (come \var{HOME}, \var{USER}, etc.)
884 sono definite al login. In genere è cura dell'amministratore definire le
885 opportune variabili di ambiente in uno script di avvio. Alcune servono poi
886 come riferimento generico per molti programmi (come \var{EDITOR} che indica
887 l'editor preferito da invocare in caso di necessità).
889 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
890 comuni), come riportato in \ntab. GNU/Linux le supporta tutte e ne definisce
891 anche altre per una lista parziale si può controllare \cmd{man environ}