X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=52d06cefd48b5ee54b6acb5378aef151d4e7cffa;hp=19f7dabdf8f371337bc8bec1b4f235d2cddc37f4;hb=062e1036f07efd623e11b5bb194bcf2684dd7866;hpb=0c3c06a023684951f7f1e189d270cf322c0dfe31 diff --git a/fileadv.tex b/fileadv.tex index 19f7dab..52d06ce 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -32,18 +32,18 @@ ed analizzeremo le varie funzioni usate per implementare questa modalit I/O. -\subsection{La problematica dell'\textit{I/O multiplexing} e l'uso - dell'\textsl{I/O non-bloccante}} +\subsection{La problematica dell'\textit{I/O multiplexing}} \label{sec:file_noblocking} Abbiamo visto in \secref{sec:sig_gen_beha}, affrontando la suddivisione fra -\textit{fast} e \textit{slow} system call, che in certi casi le funzioni di -I/O possono bloccarsi indefinitamente.\footnote{si ricordi però che questo può - accadere solo per le pipe, i socket\index{socket} ed alcuni file di - dispositivo\index{file!di dispositivo}; sui file normali le funzioni di - lettura e scrittura ritornano sempre subito.} Ad esempio le operazioni di -lettura possono bloccarsi quando non ci sono dati disponibili sul descrittore -su cui si sta operando. +\textit{fast} e \textit{slow} system call,\index{system call lente} che in +certi casi le funzioni di I/O possono bloccarsi indefinitamente.\footnote{si + ricordi però che questo può accadere solo per le pipe, i + socket\index{socket} ed alcuni file di dispositivo\index{file!di + dispositivo}; sui file normali le funzioni di lettura e scrittura + ritornano sempre subito.} Ad esempio le operazioni di lettura possono +bloccarsi quando non ci sono dati disponibili sul descrittore su cui si sta +operando. Questo comportamento causa uno dei problemi più comuni che ci si trova ad affrontare nelle operazioni di I/O, che si verifica quando si deve operare con @@ -286,8 +286,8 @@ sotto controllo anche dei file descriptor con \func{select}, in questo caso si può fare conto sul fatto che all'arrivo di un segnale essa verrebbe interrotta e si potrebbero eseguire di conseguenza le operazioni relative al segnale e alla gestione dati con un ciclo del tipo: -\includecodesnip{listati/select_race.c} -qui però emerge una race condition, perché se il segnale arriva prima della +\includecodesnip{listati/select_race.c} qui però emerge una race +condition,\index{race condition} perché se il segnale arriva prima della chiamata a \func{select}, questa non verrà interrotta, e la ricezione del segnale non sarà rilevata. @@ -306,12 +306,12 @@ interruzione si potranno eseguire le relative operazioni. \subsection{La funzione \func{poll}} \label{sec:file_poll} -System V, invece di utilizzare l'interfaccia di \func{select}, che è una -estensione creata nello sviluppo di BSD, ha introdotto una sua interfaccia per -gestire l'\textit{I/O multiplexing}, basata sulla funzione -\funcd{poll},\footnote{la funzione è prevista dallo standard XPG4, ed è stata - introdotta in Linux come system call a partire dal kernel 2.1.23 ed inserita - nelle \acr{libc} 5.4.28.} il cui prototipo è: +Nello sviluppo di System V, invece di utilizzare l'interfaccia di +\func{select}, che è una estensione tipica di BSD, è stata introdotta un'altra +interfaccia, basata sulla funzione \funcd{poll},\footnote{la funzione è + prevista dallo standard XPG4, ed è stata introdotta in Linux come system + call a partire dal kernel 2.1.23 ed inserita nelle \acr{libc} 5.4.28.} il +cui prototipo è: \begin{prototype}{sys/poll.h} {int poll(struct pollfd *ufds, unsigned int nfds, int timeout)} @@ -331,13 +331,14 @@ gestire l'\textit{I/O multiplexing}, basata sulla funzione ed inoltre \errval{EFAULT} e \errval{ENOMEM}.} \end{prototype} -La funzione permette di tenere sotto controllo un certo numero \param{ndfs} di -file descriptor, specificati attraverso un vettore di puntatori a strutture -\struct{pollfd}. Come \func{select} anche \func{poll} permette di -interrompere l'attesa dopo un certo tempo, che va specificato attraverso +La funzione permette di tenere sotto controllo contemporaneamente \param{ndfs} +file descriptor, specificati attraverso il puntatore \param{ufds} ad un +vettore di strutture \struct{pollfd}. Come con \func{select} si può +interrompere l'attesa dopo un certo tempo, questo deve essere specificato con l'argomento \param{timeout} in numero di millisecondi: un valore negativo -indica un'attesa indefinita mentre si può usare un valore nullo per eseguire -la funzione in modalità \textsl{non-bloccante}. +indica un'attesa indefinita, mentre un valore comporta il ritorno immediato (e +può essere utilizzato per impiegare \func{poll} in modalità +\textsl{non-bloccante}). \begin{figure}[!htb] \footnotesize \centering @@ -350,14 +351,18 @@ la funzione in modalit \label{fig:file_pollfd} \end{figure} -Per ciascun file da controllare deve essere opportunamente predisposta una -struttura \struct{pollfd}, la cui definizione è riportata in -\figref{fig:file_pollfd}. La struttura prevede tre campi: il campo \var{fd} -viene utilizzato per specificare il file descriptor relativo al file da -controllare, mentre nel campo \var{events} deve essere specificata una -maschera binaria data in ingresso che indichi il tipo di evento che si vuole -controllare, il kernel restituirà il relativo risultato nel campo -\var{revents}. +Per ciascun file da controllare deve essere inizializzata una struttura +\struct{pollfd} nel vettore indicato dall'argomento \param{ufds}. La +struttura, la cui definizione è riportata in \figref{fig:file_pollfd}, prevede +tre campi: in \var{fd} deve essere indicato il numero del file descriptor da +controllare, in \var{events} deve essere specificata una maschera binaria di +flag che indichino il tipo di evento che si vuole controllare, mentre in +\var{revents} il kernel restituirà il relativo risultato. Usando un valore +negativo per \param{fd} la corrispondente struttura sarà ignorata da +\func{poll}. Dato che i dati in ingresso sono del tutto indipendenti da quelli +in uscita (che vengono restituiti in \var{revents}) non è necessario +reinizializzare tutte le volte il valore delle strutture \struct{pollfd} a +meno di non voler cambiare qualche condizione. Le costanti che definiscono i valori relativi ai bit usati nelle maschere binarie dei campi \var{events} e \var{revents} sono riportati in @@ -388,7 +393,7 @@ nel campo \var{revents} per notificare delle condizioni di errore. \const{POLLHUP} & Si è verificato un hung-up.\\ \const{POLLNVAL} & Il file descriptor non è aperto.\\ \hline - \const{POLLMSG} & Definito per compatobilità con SysV.\\ + \const{POLLMSG} & Definito per compatibilità con SysV.\\ \hline \end{tabular} \caption{Costanti per l'identificazione dei vari bit dei campi @@ -396,18 +401,22 @@ nel campo \var{revents} per notificare delle condizioni di errore. \label{tab:file_pollfd_flags} \end{table} -Infine il valore \const{POLLMSG} non viene utilizzato ed è definito solo per -compatibilità con l'implementazione di SysV, dove indica segnale -\const{SIGPOLL} è arrivato alla cima dello \textit{stream}. Gli -\textit{stream} sono una interfaccia specifica di SysV non presente in Linux, -e non hanno nulla a che fare con i file \textit{stream} delle librerie -standard del C, è da questi che derivano i nomi delle costanti, in quanto per -essi sono definite tre classi di dati: \textsl{normali}, \textit{prioritari} -ed \textit{urgenti}. Nel caso di Linux la distinzione ha senso solo nel caso -per i dati \textit{out-of-band} dei socket (vedi +Il valore \const{POLLMSG} non viene utilizzato ed è definito solo per +compatibilità con l'implementazione di SysV che usa gli +\textit{stream};\footnote{essi sono una interfaccia specifica di SysV non + presente in Linux, e non hanno nulla a che fare con i file \textit{stream} + delle librerie standard del C.} è da questi che derivano i nomi di alcune +costanti, in quanto per essi sono definite tre classi di dati: +\textsl{normali}, \textit{prioritari} ed \textit{urgenti}. In Linux la +distinzione ha senso solo per i dati \textit{out-of-band} dei socket (vedi \secref{sec:TCP_urgent_data}), ma su questo e su come \func{poll} reagisce alle varie condizioni dei socket torneremo in \secref{sec:TCP_serv_poll}, dove -vedremo anche un esempio del suo utilizzo. +vedremo anche un esempio del suo utilizzo. Si tenga conto comunque che le +costanti relative ai diversi tipi di dati (come \macro{POLLRDNORM} e +\macro{POLLRDBAND}) sono utilizzabili soltanto qualora si sia definita la +macro \macro{\_XOPEN\_SOURCE}.\footnote{e ci si ricordi di farlo sempre in + testa al file, definirla soltanto prima di includere \file{sys/poll.h} non è + sufficiente.} In caso di successo funzione ritorna restituendo il numero di file (un valore positivo) per i quali si è verificata una delle condizioni di attesa richieste @@ -422,30 +431,25 @@ tramite \var{errno}. %\label{sec:file_epoll} % placeholder ... +%da fare - - -\section{Altre modalità e funzioni di I/O avanzato} -\label{sec:file_advanced_io} +\section{L'accesso \textsl{asincrono} ai file} +\label{sec:file_asyncronous_access} Benché l'\textit{I/O multiplexing} sia stata la prima, e sia tutt'ora una fra -le più diffuse modalità di gestire l'I/O in situazioni complesse che -coivolgono molti file, esistono altre modalità di gestione delle stesse -problematiche, oltre che differenti interfacce per la gestione di altre -problematiche avanzate riguardanti l'I/O su file, tratteremo tutto ciò in -questa sezione. - +le più diffuse modalità di gestire l'I/O in situazioni complesse in cui si +debba operare su più file contemporaneamente, esistono altre modalità di +gestione delle stesse problematiche. In particolare sono importanti in questo +contesto le modalità di accesso ai file eseguibili in maniera +\textsl{asincrona}, quelle cioè in cui un processo non deve bloccarsi in +attesa della disponibilità dell'accesso al file, ma può proseguire +nell'esecuzione utilizzando invece un meccanismo di notifica asincrono (di +norma un segnale), per essere avvisato della possibilità di eseguire le +operazioni di I/O volute. -\subsection{L'I/O asincrono} -\label{sec:file_asyncronous_io} -Una modalità alternativa all'uso dell'\textit{I/O multiplexing} è quella di -fare ricorso al cosiddetto \textsl{I/O asincrono}. Il concetto base -dell'\textsl{I/O asincrono} è che le funzioni di I/O non attendono il -completamento delle operazioni prima di ritornare, così che il processo non -viene bloccato. In questo modo diventa ad esempio possibile effettuare una -richiesta preventiva di dati, in modo da poter effettuare in contemporanea le -operazioni di calcolo e quelle di I/O. +\subsection{Operazioni asincrone sui file} +\label{sec:file_asyncronous_operation} Abbiamo accennato in \secref{sec:file_open} che è possibile, attraverso l'uso del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e dei @@ -453,63 +457,92 @@ del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e dei di Linux e BSD.} aprire un file in modalità asincrona, così come è possibile attivare in un secondo tempo questa modalità impostando questo flag attraverso l'uso di \func{fcntl} con il comando \const{F\_SETFL} (vedi -\secref{sec:file_fcntl}). - -In realtà in questo caso non si tratta di I/O asincrono vero e proprio, quanto -di un meccanismo asincrono di notifica delle variazione dello stato del file -descriptor; quello che succede è che il sistema genera un segnale (normalmente -\const{SIGIO}, ma è possibile usarne altri) tutte le volte che diventa -possibile leggere o scrivere dal file descriptor che si è posto in questa -modalità. Si può inoltre selezionare, con il comando \const{F\_SETOWN} di -\func{fcntl}, quale processo (o gruppo di processi) riceverà il segnale. +\secref{sec:file_fcntl}). + +In realtà in questo caso non si tratta di eseguire delle operazioni di lettura +o scrittura del file in modo asincrono (tratteremo questo, che più +propriamente è detto \textsl{I/O asincrono} in +\secref{sec:file_asyncronous_io}), quanto di un meccanismo asincrono di +notifica delle variazione dello stato del file descriptor aperto in questo +modo. + +Quello che succede in questo caso è che il sistema genera un segnale +(normalmente \const{SIGIO}, ma è possibile usarne altri con il comando +\const{F\_SETSIG} di \func{fcntl}) tutte le volte che diventa possibile +leggere o scrivere dal file descriptor che si è posto in questa modalità. Si +può inoltre selezionare, con il comando \const{F\_SETOWN} di \func{fcntl}, +quale processo (o gruppo di processi) riceverà il segnale. Se pertanto si +effettuano le operazioni di I/O in risposta alla ricezione del segnale non ci +sarà più la necessità di restare bloccati in attesa della disponibilità di +accesso ai file; per questo motivo Stevens chiama questa modalità +\textit{signal driven I/O}. In questo modo si può evitare l'uso delle funzioni \func{poll} o \func{select} che, quando vengono usate con un numero molto grande di file descriptor, non -hanno buone prestazioni. In tal caso infatti la maggior parte del loro tempo +hanno buone prestazioni. % aggiungere cenno a epoll quando l'avrò scritta + In tal caso infatti la maggior parte del loro tempo di esecuzione è impegnato ad eseguire una scansione su tutti i file descriptor tenuti sotto controllo per determinare quali di essi (in genere una piccola percentuale) sono diventati attivi. Tuttavia con l'implementazione classica dei segnali questa modalità di I/O -presenta notevoli problemi, dato che non è possibile determinare, quando sono -più di uno, qual'è il file descriptor responsabile dell'emissione del segnale. -Linux però supporta le estensioni POSIX.1b dei segnali che permettono di -superare il problema facendo ricorso alle informazioni aggiuntive restituite -attraverso la struttura \struct{siginfo\_t}, utilizzando la forma estesa -\var{sa\_sigaction} del gestore (si riveda quanto illustrato in -\secref{sec:sig_sigaction}). +presenta notevoli problemi, dato che non è possibile determinare, quando i +file descriptor sono più di uno, qual'è quello responsabile dell'emissione del +segnale. Inoltre dato che i segnali normali non si accodano (si ricordi quanto +illustrato in sez.~\ref{sec:sig_notification}), in presenza di più file +descriptor attivi contemporaneamente, più segnali emessi nello stesso momento +verrebbero notificati una volta sola. Linux però supporta le estensioni +POSIX.1b dei segnali real-time, che vengono accodati e che permettono di +riconoscere il file descriptor che li ha emessi. In questo caso infatti si può +fare ricorso alle informazioni aggiuntive restituite attraverso la struttura +\struct{siginfo\_t}, utilizzando la forma estesa \var{sa\_sigaction} del +gestore (si riveda quanto illustrato in \secref{sec:sig_sigaction}). Per far questo però occorre utilizzare le funzionalità dei segnali real-time (vedi \secref{sec:sig_real_time}) impostando esplicitamente con il comando \const{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di I/O asincrono (il segnale predefinito è \const{SIGIO}). In questo caso il -gestore tutte le volte che riceverà \const{SI\_SIGIO} come valore del +gestore, tutte le volte che riceverà \const{SI\_SIGIO} come valore del campo \var{si\_code}\footnote{il valore resta \const{SI\_SIGIO} qualunque sia il segnale che si è associato all'I/O asincrono, ed indica appunto che il segnale è stato generato a causa di attività nell'I/O asincrono.} di \struct{siginfo\_t}, troverà nel campo \var{si\_fd} il valore del file descriptor che ha generato il segnale. -Un secondo vantaggio dell'uso dei segnali real-time è che essendo dotati di -una coda di consegna ogni segnale sarà associato ad uno solo file descriptor; -inoltre sarà possibile stabilire delle priorità nella risposta a seconda del -segnale usato. In questo modo si può identificare immediatamente un file su -cui l'accesso è diventato possibile evitando completamente l'uso di funzioni -come \func{poll} e \func{select}, almeno fintanto che non si satura la coda; -si eccedono le dimensioni di quest'ultima; in tal caso infatti il kernel, non +Un secondo vantaggio dell'uso dei segnali real-time è che essendo questi +ultimi dotati di una coda di consegna ogni segnale sarà associato ad uno solo +file descriptor; inoltre sarà possibile stabilire delle priorità nella +risposta a seconda del segnale usato, dato che i segnali real-time supportano +anche questa funzionalità. In questo modo si può identificare immediatamente +un file su cui l'accesso è diventato possibile evitando completamente l'uso di +funzioni come \func{poll} e \func{select}, almeno fintanto che non si satura +la coda. Se infatti si eccedono le dimensioni di quest'ultima, il kernel, non potendo più assicurare il comportamento corretto per un segnale real-time, -invierà al suo posto un \const{SIGIO}, su cui si accumuleranno tutti i segnali -in eccesso, e si dovrà determinare al solito modo quali sono i file diventati -attivi. +invierà al suo posto un solo \const{SIGIO}, su cui si saranno accumulati tutti +i segnali in eccesso, e si dovrà allora determinare con un ciclo quali sono i +file diventati attivi. + + +\subsection{L'interfaccia POSIX per l'I/O asincrono} +\label{sec:file_asyncronous_io} + +Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione +dell'I/O simultaneo su molti file è costituita dal cosiddetto \textsl{I/O + asincrono}. Il concetto base dell'\textsl{I/O asincrono} è che le funzioni +di I/O non attendono il completamento delle operazioni prima di ritornare, +così che il processo non viene bloccato. In questo modo diventa ad esempio +possibile effettuare una richiesta preventiva di dati, in modo da poter +effettuare in contemporanea le operazioni di calcolo e quelle di I/O. Benché la modalità di apertura asincrona di un file possa risultare utile in varie occasioni (in particolar modo con i socket\index{socket} e gli altri -file per i quali le funzioni di I/O sono system call lente), essa è comunque -limitata alla notifica della disponibilità del file descriptor per le -operazioni di I/O, e non ad uno svolgimento asincrono delle medesime. Lo -standard POSIX.1b definisce anche una interfaccia apposita per l'I/O -asincrono, che prevede un insieme di funzioni dedicate, completamente separate -rispetto a quelle usate normalmente. +file per i quali le funzioni di I/O sono \index{system call lente}system call +lente), essa è comunque limitata alla notifica della disponibilità del file +descriptor per le operazioni di I/O, e non ad uno svolgimento asincrono delle +medesime. Lo standard POSIX.1b definisce una interfaccia apposita per l'I/O +asincrono vero e proprio, che prevede un insieme di funzioni dedicate per la +lettura e la scrittura dei file, completamente separate rispetto a quelle +usate normalmente. In generale questa interfaccia è completamente astratta e può essere implementata sia direttamente nel kernel, che in user space attraverso l'uso @@ -579,7 +612,7 @@ che serve a specificare il modo in cui si vuole che venga effettuata la notifica del completamento delle operazioni richieste. La struttura è riportata in \secref{fig:file_sigevent}; il campo \var{sigev\_notify} è quello che indica le modalità della notifica, esso può assumere i tre valori: -\begin{basedescript}{\desclabelwidth{3.0cm}} +\begin{basedescript}{\desclabelwidth{2.6cm}} \item[\const{SIGEV\_NONE}] Non viene inviata nessuna notifica. \item[\const{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo chiamante il segnale specificato da \var{sigev\_signo}; se il gestore di @@ -849,6 +882,16 @@ la notifica del completamento di tutte le richieste, impostando l'argomento di \struct{aiocb}. +\section{Altre modalità di I/O avanzato} +\label{sec:file_advanced_io} + +Oltre alle precedenti modalità di \textit{I/O multiplexing} e \textsl{I/O + asincrono}, esistono altre funzioni che implementano delle modalità di +accesso ai file più evolute rispetto alle normali funzioni di lettura e +scrittura che abbiamo esaminato in \secref{sec:file_base_func}. In questa +sezione allora prenderemo in esame le interfacce per l'\textsl{I/O + vettorizzato} e per l'\textsl{I/O mappato in memoria}. + \subsection{I/O vettorizzato} \label{sec:file_multiple_io} @@ -935,9 +978,9 @@ file in una sezione dello spazio di indirizzi del processo. Il meccanismo illustrato in \figref{fig:file_mmap_layout}, una sezione del file viene riportata direttamente nello spazio degli indirizzi del programma. Tutte le operazioni su questa zona verranno riportate indietro sul file dal meccanismo -della memoria virtuale che trasferirà il contenuto di quel segmento sul file -invece che nella swap, per cui si può parlare tanto di file mappato in -memoria, quanto di memoria mappata su file. +della memoria virtuale\index{memoria virtuale} che trasferirà il contenuto di +quel segmento sul file invece che nella swap, per cui si può parlare tanto di +file mappato in memoria, quanto di memoria mappata su file. \begin{figure}[htb] \centering @@ -956,16 +999,16 @@ memoria solo le parti del file che sono effettivamente usate ad un dato istante. Infatti, dato che l'accesso è fatto direttamente attraverso la memoria -virtuale, la sezione di memoria mappata su cui si opera sarà a sua volta letta -o scritta sul file una pagina alla volta e solo per le parti effettivamente -usate, il tutto in maniera completamente trasparente al processo; l'accesso -alle pagine non ancora caricate avverrà allo stesso modo con cui vengono -caricate in memoria le pagine che sono state salvate sullo swap. Infine in -situazioni in cui la memoria è scarsa, le pagine che mappano un file vengono -salvate automaticamente, così come le pagine dei programmi vengono scritte -sulla swap; questo consente di accedere ai file su dimensioni il cui solo -limite è quello dello spazio di indirizzi disponibile, e non della memoria su -cui possono esserne lette delle porzioni. +virtuale,\index{memoria virtuale} la sezione di memoria mappata su cui si +opera sarà a sua volta letta o scritta sul file una pagina alla volta e solo +per le parti effettivamente usate, il tutto in maniera completamente +trasparente al processo; l'accesso alle pagine non ancora caricate avverrà +allo stesso modo con cui vengono caricate in memoria le pagine che sono state +salvate sullo swap. Infine in situazioni in cui la memoria è scarsa, le +pagine che mappano un file vengono salvate automaticamente, così come le +pagine dei programmi vengono scritte sulla swap; questo consente di accedere +ai file su dimensioni il cui solo limite è quello dello spazio di indirizzi +disponibile, e non della memoria su cui possono esserne lette delle porzioni. L'interfaccia prevede varie funzioni per la gestione del \textit{memory mapped I/O}, la prima di queste è \funcd{mmap}, che serve ad eseguire la mappatura @@ -1118,11 +1161,19 @@ come maschera binaria ottenuta dall'OR di uno o pi Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere piuttosto complessi, essi si possono comprendere solo tenendo presente che tutto quanto è comunque basato sul basato sul meccanismo della memoria -virtuale. Questo comporta allora una serie di conseguenze. La più ovvia è che -se si cerca di scrivere su una zona mappata in sola lettura si avrà -l'emissione di un segnale di violazione di accesso (\const{SIGSEGV}), dato che -i permessi sul segmento di memoria relativo non consentono questo tipo di -accesso. +virtuale.\index{memoria virtuale} Questo comporta allora una serie di +conseguenze. La più ovvia è che se si cerca di scrivere su una zona mappata in +sola lettura si avrà l'emissione di un segnale di violazione di accesso +(\const{SIGSEGV}), dato che i permessi sul segmento di memoria relativo non +consentono questo tipo di accesso. + +\begin{figure}[!htb] + \centering + \includegraphics[width=10cm]{img/mmap_boundary} + \caption{Schema della mappatura in memoria di una sezione di file di + dimensioni non corrispondenti al bordo di una pagina.} + \label{fig:file_mmap_boundary} +\end{figure} È invece assai diversa la questione relativa agli accessi al di fuori della regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe @@ -1137,15 +1188,6 @@ file non rientra nei confini di una pagina: in tal caso verr mappato su un segmento di memoria che si estende fino al bordo della pagina successiva. -\begin{figure}[htb] - \centering - \includegraphics[width=10cm]{img/mmap_boundary} - \caption{Schema della mappatura in memoria di una sezione di file di - dimensioni non corrispondenti al bordo di una pagina.} - \label{fig:file_mmap_boundary} -\end{figure} - - In questo caso è possibile accedere a quella zona di memoria che eccede le dimensioni specificate da \param{lenght}, senza ottenere un \const{SIGSEGV} poiché essa è presente nello spazio di indirizzi del processo, anche se non è