%% process.tex
%%
-%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2003 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Prefazione",
all'utente, avere la possibilità di effettuare automaticamente la chiamata ad
una funzione che effettui tali operazioni all'uscita dal programma. A questo
scopo lo standard ANSI C prevede la possibilità di registrare un certo numero
-funzioni che verranno eseguite all'uscita dal programma (sia per la chiamata
-ad \func{exit} che per il ritorno di \func{main}). La prima funzione che si
-può utilizzare a tal fine è \funcd{atexit} il cui prototipo è:
+di funzioni che verranno eseguite all'uscita dal programma (sia per la
+chiamata ad \func{exit} che per il ritorno di \func{main}). La prima funzione
+che si può utilizzare a tal fine è \funcd{atexit} il cui prototipo è:
\begin{prototype}{stdlib.h}{void atexit(void (*function)(void))}
Registra la funzione \param{function} per la chiamata all'uscita dal
programma.
\end{prototype}
\noindent la funzione richiede come argomento l'indirizzo di una opportuna
funzione di pulizia da chiamare all'uscita del programma, che non deve
-prendere argomenti e non deve ritornare niente (deve essere essere cioè
-definita come \code{void function(void)}).
+prendere argomenti e non deve ritornare niente (deve essere cioè definita come
+\code{void function(void)}).
Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le
\acr{glibc} includono per compatibilità con SunOS, ma che non è detto sia
Per la gestione da parte del kernel la memoria virtuale viene divisa in pagine
di dimensione fissa (che ad esempio sono di 4kb su macchine a 32 bit e 8kb
sulle alpha, valori strettamente connessi all'hardware di gestione della
-memoria), e ciascuna pagina della memoria virtuale è associata ad un supporto
-che può essere una pagina di memoria reale o ad un dispositivo di stoccaggio
-secondario (in genere lo spazio disco riservato alla swap, o i file che
-contengono il codice).
+memoria),\footnote{con le versioni più recenti del kernel è possibile anche
+ utilizzare pagine di dimensioni maggiori, per sistemi con grandi
+ quantitativi di memoria in cui l'uso di pagine troppo piccole comporta una
+ perdita di prestazioni.} e ciascuna pagina della memoria virtuale è
+associata ad un supporto che può essere una pagina di memoria reale o ad un
+dispositivo di stoccaggio secondario (in genere lo spazio disco riservato alla
+swap, o i file che contengono il codice).
Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a
diverse pagine di memoria virtuale appartenenti a processi diversi (come
puntatori a \val{NULL}).\footnote{si ricordi che questo vale solo per le
variabili che vanno nel segmento dati, e non è affatto vero in generale.}
- Storicamente questo segmento viene chiamato BBS (da \textit{block started by
+ Storicamente questo segmento viene chiamato BSS (da \textit{block started by
symbol}). La sua dimensione è fissa.
\item Lo \textit{heap}. Tecnicamente lo si può considerare l'estensione del
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
+\textit{smartpointers}. Questo però va a scapito delle prestazioni
dell'applicazione in esecuzione.
In altri linguaggi come il java e recentemente il C\# il problema non si pone
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
+Anche questo va a scapito delle prestazioni 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
+di per sé delle prestazioni 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.
normale pensare di poter effettuare questa operazione.
In generale però possono esistere anche realizzazioni diverse, per questo
-motivo \macro{va\_list} è definito come \textsl{tipo opaco}\index{tipo opaco}
+motivo \macro{va\_list} è definito come \textsl{tipo opaco}\index{tipo!opaco}
e non può essere assegnato direttamente ad un'altra variabile dello stesso
tipo. Per risolvere questo problema lo standard ISO C99\footnote{alcuni
sistemi che non hanno questa macro provvedono al suo posto
salvare il contesto dello stack è \funcd{setjmp}, il cui prototipo è:
\begin{functions}
\headdecl{setjmp.h}
- \funcdecl{void setjmp(jmp\_buf env)}
+ \funcdecl{int setjmp(jmp\_buf env)}
Salva il contesto dello stack.
\func{longjmp}, ma quelli delle variabili automatiche (o di quelle dichiarate
\direct{register}\footnote{la direttiva \direct{register} del compilatore
chiede che la variabile dichiarata tale sia mantenuta, nei limiti del
- possibile, all'interno di un registro del processore. Questa direttiva
- origina dai primi compilatori, quando stava al programmatore scrivere codice
- ottimizzato, riservando esplicitamente alle variabili più usate l'uso dei
- registri del processore. Oggi questa direttiva oggi è in disuso dato che
- tutti i compilatori sono normalmente in grado di valutare con maggior
- efficacia degli stessi programmatori quando sia il caso di eseguire questa
- ottimizzazione.}) sono in genere indeterminati.
+ possibile, all'interno di un registro del processore. Questa direttiva è
+ originaria dell'epoca dai primi compilatori, quando stava al programmatore
+ scrivere codice ottimizzato, riservando esplicitamente alle variabili più
+ usate l'uso dei registri del processore. Oggi questa direttiva è in disuso
+ dato che tutti i compilatori sono normalmente in grado di valutare con
+ maggior efficacia degli stessi programmatori quando sia il caso di eseguire
+ questa ottimizzazione.}) sono in genere indeterminati.
Quello che succede infatti è che i valori delle variabili che sono tenute in
memoria manterranno il valore avuto al momento della chiamata di
projects / gapil.git / blobdiff