process.tex

   1 \chapter{L'interfaccia base con i processi}
   2 \label{cha:process_interface}
   3
   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
   9 esecuzione.
  10
  11 In genere un programma viene eseguito quando un processo lo fa partire
  12 eseguendo una funzione della famiglia \texttt{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.
  16
  17
  18
  19 \section{Esecuzione e conclusione di un programma}
  20
  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.
  27
  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).
  34
  35 \section{La funzione \texttt{main}}
  36 \label{sec:proc_main}
  37
  38 Quando un programma viene lanciato il kernel esegue una opportuna routine di
  39 avvio, usando il programma \texttt{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 \texttt{/etc/ld.so.conf}, i
  46 dettagli sono riportati nella man page di \texttt{ld.so}.
  47
  48 Il sistema fa partire qualunque programma chiamando la funzione \texttt{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.
  52
  53 Lo standard ISO C specifica che la funzione \texttt{main} può o 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{verbatim}
  57      int main (int argc, char *argv[])
  58 \end{verbatim}
  59
  60 In realtà nei sistemi unix esiste un'altro modo per definire la funzione
  61 \texttt{main}, che prevede la presenza di un terzo parametro, \texttt{char
  62   *envp[]}, che fornisce l'\textsl{ambiente} (vedi \secref{proc_environ}) del
  63 programma; questa forma però non è prevista dallo standard POSIX.1 per cui se
  64 si vogliono scrivere programmi portabili è meglio evitarla.
  65
  66
  67 \subsection{Come chiudere un programma}
  68 \label{sec:proc_termination}
  69
  70 La via normale per la quale un programma finisce è quando la funzione main
  71 ritorna, una modalità equivalente di conclusione è quella di chiamare
  72 direttamente la funzione \texttt{exit} (che viene comunque chiamata dalla
  73 routine di avvio del programma quando la funzione main ritorna). Una forma
  74 alternativa è quella di chiamare direttamente la system call \texttt{\_exit}
  75 che passa il controllo direttamente al kernel.
  76
  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 \texttt{abort} (che comunque genera un segnale che termina il
  80 programma); torneremo su questo in \secref{sec:sig_abort}.
  81
  82 Il valore di ritorno della funzione main, o quello usato nelle chiamate ad
  83 \texttt{exit} e \texttt{\_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.
  88
  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 \texttt{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 \texttt{main} senza ritornare esplicitamente si ha un
  96 valore di uscita indefinito, è pertanto consigliabile di concludere sempre in
  97 maniera esplicita detta funzione.
  98
  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.
 103
 104 Si tenga presente inoltre che non è una buona idea usare il valore dell'errore
 105 restituito dalla variabile \texttt{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 \texttt{stdlib.h} sono definite due macro \texttt{EXIT\_SUCCESS} e
 110 \texttt{EXIT\_FAILURE}, che in Linux sono poste rispettivamente ai valori 0 e
 111 1 (di tipo \texttt{int}), seguendo lo standard POSIX.
 112
 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:prochand_XXX}).
 120
 121
 122 \subsection{Le funzioni \texttt{exit} e \texttt{\_exit}}
 123 \label{sec:proc_exit}
 124
 125 Come accennato funzioni per l'uscita ``normale'' da un programma sono due, la
 126 prima è la funzione \texttt{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   \texttt{status} al processo padre.
 131
 132   La funzione non ritorna. Il processo viene terminato
 133 \end{prototype}
 134
 135 La funzione \texttt{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 \texttt{atexit} e \texttt{on\_exit} (vedi
 138 \secref{sec:proc_atexit}), e chiude tutti gli stream di I/O effettuando il
 139 salvataggio dei dati sospesi (chiamando \texttt{fclose}, vedi
 140 \secref{sec:filestd_close}), infine ripassa il controllo al kernel chiamando
 141 \texttt{\_exit} e passando il valore \texttt{status} come stato di uscita.
 142
 143 La system call \texttt{\_exit} restituisce direttamente il controllo al
 144 kernel, concludendo immediatamente il processo, le eventuali funzioni
 145 registrate con \texttt{atexit} e \texttt{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   \texttt{status} al processo padre.
 150
 151   La funzione non ritorna. Il processo viene terminato.
 152 \end{prototype}
 153
 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 \texttt{init}
 157 (vedi \secref{cha:process_handling}), manda un segnale \texttt{SIGCHLD} al
 158 processo padre (vedi \ref{sec:sig_sigchild}) ed infine ritorna lo stato di
 159 uscita specificato in \texttt{status} che può essere raccolto usando la
 160 funzione \texttt{wait} (vedi \secref{sec:prochand_wait}).
 161
 162
 163 \subsection{Le funzioni \texttt{atexit} e \texttt{on\_exit}}
 164 \label{sec:proc_atexit}
 165
 166 Come accennato l'uso di \texttt{exit} al posto della \texttt{\_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
 169 stream).
 170
 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.
 177
 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 \textit{exit} che per il ritorno di \texttt{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 \texttt{function} per essere chiamata all'uscita dal
 184   programma.
 185
 186   La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
 187   \texttt{errno} non viene settata.
 188 \end{prototype}
 189
 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 \texttt{atexit} è la funzione \texttt{on\_exit} (che la glibc
 193 include per compatibilità con SunOS e che non è detta 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 \texttt{function} per essere chiamata all'uscita dal
 198   programma. Tutte le funzioni registrate vengono chiamate in ordine inverso
 199   rispetto a quello di registrazione.
 200
 201   La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
 202   \texttt{errno} non viene settata.
 203 \end{prototype}
 204
 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 \texttt{exit} ed il secondo al puntatore generico specificato come secondo
 208 argomento nella chiamata di \texttt{on\_exit}.
 209
 210 Tutte le funzioni registrate vengono chiamate in ordine inverso rispetto a
 211 quello di registrazione (ed una stessa funzione registrata più volte sarà
 212 chiamata più volte); poi vengono chiusi tutti gli stream aperti, infine viene
 213 chiamata \texttt{\_exit}.
 214
 215
 216 \subsection{Conclusioni}
 217 \label{sec:proc_term_conclusion}
 218
 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 \texttt{execve} (in genere
 222 attraveso una delle funzioni \texttt{exec} che vedremo in
 223 \secref{sec:prochand_exec}).
 224
 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 \texttt{\_exec} sia esplicitamente o che in maniera indiretta attraverso l'uso
 228 di \texttt{exit} o il ritorno della funzione \texttt{main}.
 229
 230 Lo schema delle modalità con cui si avvia e conclude normalmente un programma
 231 è riportato in \nfig.
 232
 233 \begin{figure}[htb]
 234   \centering
 235
 236   \caption{Schema dell'avvio e della conclusione di un programma.}
 237   \label{fig:proc_prog_start_stop}
 238 \end{figure}
 239
 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}.
 243
 244
 245
 246 \section{I processi e l'uso della memoria}
 247 \label{sec:proc_memory}
 248
 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
 253 processo.
 254
 255
 256 \subsection{I concetti generali}
 257 \label{sec:proc_mem_gen}
 258
 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).
 266
 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).
 271
 272 La memoria virtuale viene divisa in pagine (che ad esempio sono di 4kb su
 273 macchine a 32 bit e 8kb sulle alpha, valori strettamente connessi all'hardware
 274 di gestione della memoria) di dimensione fissa, 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 spazio
 277 disco riservato alla swap, o i file che contengono il codice).
 278
 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 \texttt{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.
 285
 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 (dalla \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.
 294
 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
 301 processo.
 302
 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}).
 313
 314
 315 \subsection{La struttura della memoria di un processo}
 316 \label{sec:proc_mem_layout}
 317
 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}, si tenta cioè di leggere e scrivere
 323 da un indirizzo per il quale non esiste una associazione della pagina virtuale
 324 ed il kernel risponde al relativo \textit{page fault} mandando un segnale
 325 \texttt{SIGSEGV} al processo, che normalmente ne causa la terminazione
 326 immediata.
 327
 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:
 332
 333 \begin{enumerate}
 334 \item Il segmento di testo (\textit{text segment}). Contiene il codice
 335   macchina del programma e le costanti statiche. Normalmente viene condiviso
 336   così 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.
 339
 340   Viene allocato da \texttt{exec} all'avvio del programma e resta invariato
 341   per tutto il tempo dell'esecuzione.
 342
 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 è
 345   diviso in due parti.
 346
 347   La prima parte è il segmento dei dati inizializzati, che contiene le
 348   variabili globali il cui valore è stato assegnato esplicitamente. Ad esempio
 349   se si definisce:
 350 \begin{verbatim}
 351     double pi = 3.14;
 352 \end{verbatim}
 353   questo valore sarà immagazzinato in questo segmento. La memoria di questo
 354   segmento viene preallocato dalla \texttt{exec} e inizializzata ai valori
 355   specificati.
 356
 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{verbatim}
 361     int vect[100];
 362 \end{verbatim}
 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 \texttt{NULL}).
 366
 367   Storicamente questo segmento viene chiamato BBS (da \textit{block started by
 368     symbol}. La sua dimensione è fissa.
 369
 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.
 376
 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.
 384
 385   La dimensione di questo segmento aumenta seguendo la crescita dello stack
 386   del programma, ma non viene ridotta quando quest'ultimo si restringe.
 387 \end{enumerate}
 388
 389 \begin{figure}[htb]
 390   \centering
 391
 392   \caption{Disposizione tipica dei segmenti di memoria di un processo}
 393   \label{fig:proc_mem_layout}
 394 \end{figure}
 395
 396 Una disposizione tipica di questi segmenti è riportata in \nfig. Usando il
 397 comando \texttt{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
 400 programma.
 401
 402
 403 \subsection{Allocazione della memoria per i programmi C}
 404 \label{sec:proc_mem_alloc}
 405
 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 \texttt{exec}) e non viene liberato fino alla sua conclusione.
 411
 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
 416 medesima.
 417
 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
 421 programma.
 422
 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 \texttt{sbrk}), solo che a questo punto detto spazio sarà accessibile solo in
 429 maniera indiretta attraverso dei puntatori.
 430
 431
 432 \subsection{Le funzioni \texttt{malloc}, \texttt{calloc}, \texttt{realloc} e
 433   \texttt{free}}
 434 \label{sec:proc_mem_malloc}
 435
 436 Le funzioni previste dallo standard ANSI C per la gestione della memoria sono
 437 quattro, i prototipi sono i seguenti:
 438 \begin{functions}
 439 \headdecl{stdlib.h}
 440 \funcdecl{void *calloc(size\_t size)}
 441   Alloca \texttt{size} bytes nello heap. La memoria viene inizializzata a 0.
 442
 443   La funzione restituisce il puntatore alla zona di memoria allocata in caso
 444   di successo e \texttt{NULL} in caso di fallimento, nel qual caso
 445   \texttt{errno} viene settata a \texttt{ENOMEM}.
 446 \funcdecl{void *malloc(size\_t size)}
 447   Alloca \texttt{size} bytes nello heap. La memoria non viene inizializzata.
 448
 449   La funzione restituisce il puntatore alla zona di memoria allocata in caso
 450   di successo e \texttt{NULL} in caso di fallimento, nel qual caso
 451   \texttt{errno} viene settata a \texttt{ENOMEM}.
 452 \funcdecl{void *realloc(void *ptr, size\_t size)}
 453   Cambia la dimensione del blocco allocato all'indirizzo \texttt{ptr}
 454   portandola a \texttt{size}.
 455
 456   La funzione restituisce il puntatore alla zona di memoria allocata in caso
 457   di successo e \texttt{NULL} in caso di fallimento, nel qual caso
 458   \texttt{errno} viene settata a \texttt{ENOMEM}.
 459 \funcdecl{void free(void *ptr)}
 460   Disalloca lo spazio di memoria puntato da \texttt{ptr}.
 461
 462   La funzione non ritorna nulla.
 463 \end{functions}
 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 bytes e sulle macchine
 467 a 64 bit a multipli di 8 bytes.
 468
 469 In genere su usano le funzioni \texttt{malloc} e \texttt{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
 473 allocazione.
 474
 475 La memoria allocata dinamicamente deve essere esplicitamente rilasciata usando
 476 \texttt{free}\footnote{le glibc provvedono anche una funzione \texttt{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 \texttt{free}, in caso contrario il comportamento della funzione è indefinito.
 482
 483 La funzione \texttt{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 \texttt{malloc} (se è passato un valore \texttt{NULL} allora la funzione si
 487 comporta come \texttt{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 \texttt{realloc} anche per un puntatore liberato con
 491   \texttt{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 utilzza, altrimenti rialloca altrove un blocco della dimensione
 496 voluta copiandoci automaticamente il contenuto, lo spazio in più non viene
 497 inizializzato.
 498
 499 Il fatto che il blocco di memoria restituito da \texttt{realloc} possa
 500 camabiare 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
 503 ridimensionare.
 504
 505
 506 Uno degli errori più comuni (specie se si ha a che fare con array di
 507 puntatori) è infatti quello di chiamare \texttt{free} più di una volta sullo
 508 stesso puntatore; per evitare questo problema una soluzione di ripiego è
 509 quella di assegnare sempre a \texttt{NULL} ogni puntatore liberato con
 510 \texttt{free}, dato che, quando il parametro è un puntatore nullo,
 511 \texttt{free} non esegue nessuna operazione.
 512
 513 Linux e le glibc hanno una implementazione delle routine di allocazione che è
 514 controllabile dall'utente attraverso alcune variabili di ambiente, in
 515 particolare diventa possibile tracciare questo tipo di errori usando la
 516 variabile \texttt{MALLOC\_CHECK\_} che quando viene settata mette in uso una
 517 versione meno efficiente delle funzioni, che però è più tollerante nei
 518 confronti di piccoli errori come quello di chiamate doppie a \texttt{free}; in
 519 pparticolare se la variabile è posta a zero gli errori vengono ignorati, se è
 520 posta ad 1 viene stampato un avviso sullo standard error e se
 521
 522 Il problema più comune e più difficile da tracciare che si incontra con
 523 l'allocazione della memoria è però quando la memoria non più utilizzata non
 524 viene opportunamente liberata (quello che in inglese viene chiamato
 525 \textit{memory-leak}, traducibile come \textsl{perdita di memoria}).
 526
 527 Un caso tipico è quando l'allocazione viene fatta da una subroutine per un uso
 528 locale, ma la memoria non viene liberata una volta usata; chiamate ripetute
 529 alla stessa suubroutine causeranno a lungo andare un esaurimento della memoria
 530 disponibile, con un conseguente crash dell'applicazione che può avvenire in
 531 qualunque momento senza nessuna relazione con la subroutine che contiene
 532 l'errore.
 533
 534 Per questo motivo l'implementazione delle routine di allocazione delle glibc
 535 mette a disposizione una serie di funzionalità (su cui torneremo in
 536 \secref{sec:proc_mem_advanced}) che permettono di tracciare le allocazioni e
 537 le disallocazione, e definisce anche una serie di possibili agganci che
 538 permettono di sostituire alle funzioni di libreria una propria versione (che
 539 può essere più o meno specializzata per il debugging).
 540
 541 \subsection{La funzione \texttt{alloca}}
 542 \label{sec:proc_mem_alloca}
 543
 544 Una alternativa possibile all'uso di \texttt{malloc}, che non soffre del tipo
 545 di problemi di memomry leak descritti in precedenza è la funzione
 546 \texttt{alloca} che invece che allocare la memoria nello heap usa lo il
 547 segmento di stack della funzione corrente. La sintassi è identica:
 548 \begin{prototype}{stdlib.h}{void *alloca(size\_t size)}
 549   Alloca \texttt{size} bytes nel segmento di stack della funzione chiamante.
 550   La memoria non viene inizializzata.
 551
 552   La funzione restituisce il puntatore alla zona di memoria allocata in caso
 553   di successo e \texttt{NULL} in caso di fallimento, nel qual caso
 554   \texttt{errno} viene settata a \texttt{ENOMEM}.
 555 \end{prototype}
 556 ma in questo caso non è più necessario liberare la memoria in quanto questa
 557 viene rilasciata automaticamente al ritorno della funzione.
 558
 559 Come è evidente questa funzione ha molti vantaggi, e permette di evitare i
 560 problemi di memory leak non essendo più necessaria la deallocazione esplicita;
 561 una delle ragioni principali per usarla è però che funziona anche quando si
 562 usa \texttt{longjump} per uscire con un salto non locale da una funzione (vedi
 563 \secref{sec:proc_longjmp}),
 564
 565 Un altro vantaggio e che in Linux la funzione è molto veloce e non viene
 566 sprecato spazio, infatti non è necessario gestire un pool di memoria da
 567 riservare e si evitano anche problemi di frammentazione.
 568
 569 Gli svantaggi sono che la funzione non è disponibile su tutti gli unix quando
 570 non è possibile aumentare le dimensioni dello stack una volta chiamata una
 571 funzione e quindi l'uso limita la portabilità dei programmi, inoltre se si
 572 cerca di allocare troppa memoria non si ottiene un messaggio di errore, ma un
 573 segnale di \textit{segmentation violation} analogo a quello che si avrebbe da
 574 una ricorsione infinita.
 575
 576
 577 \subsection{Le funzioni \texttt{brk} e \texttt{sbrk}}
 578 \label{sec:proc_mem_sbrk}
 579
 580 L'uso di queste funzioni è necessario solo quando si voglia accedere alle
 581 analoghe system call a cui fanno da interfaccia (ad esempio per implementare
 582 una propria versione di \texttt{malloc}. Le  funzione sono:
 583 \begin{prototype}{unistd.h}{int *brk(void end\_data\_segment)}
 584   Sposta la fine del segmento dei dati all'indirizzo specificato da
 585   \texttt{end\_data\_segment}.
 586
 587   La funzione restituisce 0 in caso di successo e -1 in caso di fallimento,
 588   nel qual caso \texttt{errno} viene settata a \texttt{ENOMEM}.
 589 \end{prototype}
 590 \begin{prototype}{unistd.h}{int *sbrk(ptrdiff\_t increment)}
 591   Incrementa lo spazio dati di un programma di \texttt{increment}. Un valore
 592   zero restituisce l'attuale posizione della fine del segmento dati.
 593
 594   La funzione restituisce il puntatore all'inzio della nuova zona di memoria
 595   allocata in caso di successo e \texttt{NULL} in caso di fallimento, nel qual
 596   caso \texttt{errno} viene settata a \texttt{ENOMEM}.
 597 \end{prototype}
 598
 599 Queste funzioni sono state deliberatamente escluse dallo standard POSIX.1 e
 600 per i programmi normali è opportuno usare le funzioni di allocazione standard
 601 descritte in precedenza, che sono costruite su di esse.  In genere si usa
 602 \texttt{sbrk} con un valore zero per ottenere l'attuale posizione della fine
 603 del segmento dati.
 604
 605
 606 % \subsection{La personalizzazione delle funzioni di allocazione}
 607 % \label{sec:proc_mem_malloc_custom}
 608
 609
 610 \subsection{Il controllo della memoria virtuale}
 611 \label{sec:proc_mem_mlock}
 612
 613 Come spiegato in \secref{sec:proc_mem_gen} il kernel gestisce la memoria in
 614 maniera trasparente ai processi, decidendo quando rimuovere pagine dalla
 615 memoria per metterle nello swap sulla base dell'utilizzo corrente da parte dei
 616 vari processi.
 617
 618 Nell'uso comune un processo non deve preoccuparsi di tutto ciò in quanto il
 619 meccanismo della paginazione riporta in RAM, ed in maniera trasparente, tutte
 620 le pagine che gli occorrono; esistono però esigenze particolari in cui non si
 621 vuole che il meccanismo dello \textit{swapping}, in generale i motivi per cui
 622 si possono avere queste necessità sono sostanzialmente due:
 623 \begin{itemize}
 624 \item La velocità. Il processo della paginazione è trasparente solo se il
 625   programma in esecuzione se non è sensibile al tempo che occorre a riportare
 626   la pagina in memoria; per questo motivi processi critici che hanno esigenze
 627   di tempo reale o tolleranze critiche nella risposte (ad esempio processi che
 628   trattano campionamenti sonori) possono non essere in grado di sopportare
 629   le variazioni della velocità di accesso dovuta alla paginazione.
 630
 631   In certi casi poi un programmatore può conoscere meglio dell'algoritmo di
 632   allocazione delle pagine le esigenze specifiche del suo programma e decidere
 633   quali pagine di memoria è opportuno che restino in memoria per un aumento
 634   delle prestazioni. In genere queste sono esigenze particolari e richiedono
 635   anche un aumento delle priorità in esecuzione (vedi \secref{sec:xxx_xxx}).
 636
 637 \item La sicurezza. Se si tengono password o chiavi in memoria queste possono
 638   essere portate su disco dal meccanismo della paginazione, questo rende più
 639   lungo il periodo di tempo in cui i segreti sono presenti in chiaro, e
 640   complessa la loro cancellazione (in genere è possibile cancellare della ram
 641   ma altrettanto non vale per il disco su cui la pagina contenente i segreti
 642   può essere stata salvata). Per questo motivo programmi di crittografia
 643   richiedono il blocco di alcune pagine di memoria.
 644 \end{itemize}
 645
 646 \section{Il controllo di flusso non locale}
 647 \label{sec:proc_longjmp}
 648
 649 Il controllo del flusso di un programma in genere viene effettuato con le
 650 varie istruzioni del linguaggio C, la più bistrattata delle quali è il
 651 \texttt{goto} ampiamente deprecato in favore di costrutti più puliti; esiste
 652 però un caso in l'uso di questa istruzione porta all'implementazione più
 653 efficiente, quello dell'uscita in caso di errore.
 654
 655 Il C però non consente di effettuare un salto ad una label definita in
 656 un'altra funzione, per cui se l'errore avviene in funzioni profondamente
 657 annidate occorre usare la funzione \func{longjump}.
 658
 659
 660 \section{La gestione di parametri e opzioni}
 661 \label{sec:proc_options}
 662
 663 Il passaggio dei parametri e delle variabili di ambiente dalla riga di comando
 664 al singolo programma quando viene lanciato è effettuato attraverso le
 665 variabili \texttt{argc}, \texttt{argv} che vengono passate al programma
 666 come argomenti della funzione principale.
 667
 668 \subsection{Il formato dei parametri}
 669 \label{sec:proc_par_format}
 670 In genere passaggio dei parametri al programma viene effettuato dalla shell,
 671 che si incarica di leggere la linea di comando e di effettuarne la scansione
 672 (il cosiddetto \textit{parsing}) per individuare le parole che la compongono,
 673 ciascuna delle quali viene considerata un parametro; di default per
 674 individuare le parole viene usato come separatore lo spazio (comportamento
 675 modificabile attraverso il settaggio della variabile di ambiente IFS).
 676
 677 Nella scansione viene costruito il vettore di puntatori \texttt{argv} inserendo
 678 in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
 679 variabile \texttt{argc} viene inizializzata al numero di parametri trovati, in
 680 questo modo il primo parametro è sempre il nome del programma (vedi \nfig).
 681
 682 \subsection{La gestione delle opzioni}
 683 \label{sec:proc_opt_handling}
 684
 685 In generale un programma unix riceve da linea di comando sia i parametri che
 686 le opzioni, queste ultime sono standardizzate per essere riconosciute come
 687 tali: un elemento di \texttt{argv} che inizia con \texttt{-} e che non sia un
 688 singolo \texttt{-} o \texttt{--} viene considerato un'opzione.  In in genere
 689 le opzioni sono costituite da una lettera preceduta dal meno e possono avere o
 690 no un parametro associato; un comando tipico può essere cioè qualcosa del
 691 tipo:
 692 \begin{verbatim}
 693 touch -r riferimento.txt -m questofile.txt
 694 \end{verbatim}
 695 ed in questo caso le opzioni sono \texttt{m} ed \texttt{r}.
 696
 697 Per gestire le opzioni all'interno dei parametri passati in \texttt{argv} le
 698 librerie standard del C forniscono la funzione \texttt{getopt} (accessibile
 699 includendo \texttt{unistd.h}), che ha il prototipo:
 700 \begin{verbatim}
 701 int getopt(int argc, char * const argv[], const char * optstring);
 702 \end{verbatim}
 703
 704 Questa funzione prende come argomenti le due variabili \texttt{argc} e
 705 \texttt{argv} ed una stringa che indica quali sono le opzioni valide; la
 706 funzione effettua la scansione della lista dei parametri ricercando ogni
 707 stringa che comincia con \texttt{-} e ritorna ogni volta che trova una opzione
 708 valida.
 709
 710 La stringa \texttt{optstring} indica quali sono le opzioni riconosciute ed è
 711 costituita da tutti i caratteri usati per identificare le singole opzioni, se
 712 l'opzione ha un parametro al carattere deve essere fatto seguire un segno di
 713 due punti \texttt{:} nel caso appena accennato ad esempio la stringa di
 714 opzioni sarebbe \texttt{"r:m"}.
 715
 716 La modalità di uso è pertanto quella di chiamare più volte la funzione
 717 all'interno di un ciclo di while fintanto che essa non ritorna il valore
 718 \texttt{-1} che indica che non ci sono più opzioni. Nel caso si incontri
 719 un'opzione non dichiarata in \texttt{optstring} viene ritornato un \texttt{?}
 720 mentre se l'opzione non è seguita da un parametro viene ritornato un
 721 \texttt{:} infine se viene incontrato il valore \texttt{--} la scansione viene
 722 considerata conclusa.
 723
 724 Quando la funzione trova un'opzione essa ritorna il valore numerico del
 725 carattere, in questo modo si possono prendere le azioni relative usando un
 726 case; la funzione inizializza inoltre alcune variabili globali:
 727 \begin{itemize}
 728 \item \texttt{char * optarg} contiene il puntatore alla stringa argomento
 729   dell'opzione.
 730 \item \texttt{int optind} alla fine della scansione restituisce l'indice del
 731   primo argomento che non è un'opzione.
 732 \item \texttt{int opterr} previene, se posto a zero, la stampa di un messaggio
 733   di errore in caso di riconoscimento di opzioni non definite.
 734 \item \texttt{int optopt} contiene il carattere dell'opzione non riconosciuta.
 735 \end{itemize}
 736
 737 In \nfig\ è mostrato un programma di esempio,
 738
 739 \begin{figure}[htbp]
 740   \footnotesize
 741     \begin{lstlisting}{}
 742     opterr = 0;  /* don't want writing to stderr */
 743     while ( (i = getopt(argc, argv, "o:a:i:hve")) != -1) {
 744         switch (i) {
 745         case 'i':   /* input file */
 746             in_file=open(optarg,O_RDONLY);
 747             if (in_file<0) {
 748                 perror("Cannot open input file");
 749                 exit(1);
 750             }
 751             break;
 752         case 'o':   /* output file (overwrite) */
 753             out_file=open(optarg,O_WRONLY|O_CREAT);
 754             if (out_file<0) {
 755                 perror("Cannot open output file");
 756                 exit(1);
 757             }
 758             break;
 759             break;
 760         case 'a':   /* output file (append) */
 761             out_file=open(optarg,O_WRONLY|O_CREAT|O_APPEND);
 762             break;
 763         case 'h':   /* print help usage */
 764             usage();
 765             break;
 766         case 'v':   /* set verbose mode */
 767             debug("Option -v active\n");
 768             verbose=1;
 769             break;
 770         case '?':   /* unrecognized options */
 771             printf("Unrecognized options -%c\n",optopt);
 772             usage();
 773         default:    /* should not reached */
 774             debug("default option\n");
 775             usage();
 776         }
 777     }
 778     debug("Optind %d, argc %d\n",optind,argc);
 779   \end{lstlisting}
 780   \caption{Esempio di codice per la gestione delle opzioni.}
 781   \label{fig:proc_options_code}
 782 \end{figure}
 783
 784 \subsection{Opzioni in formato esteso}
 785 \label{sec:proc_opt_extended}
 786
 787 Un'estensione di questo schema è costituito dalle cosiddette
 788 \textit{long-options} espresse nella forma \texttt{--option=parameter}, anche
 789 la gestione di queste ultime è stata standardizzata attraverso l'uso di una
 790 versione estesa di \texttt{getopt}.
 791
 792
 793 \subsection{Le variabili di ambiente}
 794 \label{sec:proc_env_var}
 795