X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=349d1573bc11750f46e04bef05be284bfbc8c180;hp=40dc7a50fe7f6b7dba6cdea07f6ed4699de324ea;hb=52f9927779abf41607e5f7741a9aa978ac23d6e1;hpb=486c2be2a052783e6dec09bc288c76ecaa4f21e6 diff --git a/fileadv.tex b/fileadv.tex index 40dc7a5..349d157 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -78,7 +78,7 @@ con la funzione \func{select}, il cui prototipo \bodydesc{La funzione in caso di successo restituisce il numero di file descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual - caso \var{errno} viene settata ai valori: + caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno degli insiemi. @@ -141,9 +141,9 @@ pi Infine l'argomento \param{timeout}, specifica un tempo massimo di attesa\footnote{il tempo è valutato come \textit{elapsed time}.} prima che la -funzione ritorni; se settato a \macro{NULL} la funzione attende +funzione ritorni; se impostato a \macro{NULL} la funzione attende indefinitamente. Si può specificare anche un tempo nullo (cioè una \var{struct - timeval} con i campi settati a zero), qualora si voglia semplicemente + timeval} con i campi impostati a zero), qualora si voglia semplicemente controllare lo stato corrente dei file descriptor. La funzione restituisce il totale dei file descriptor pronti nei tre insiemi, @@ -153,22 +153,24 @@ operazioni ad esso relative, in modo da poterlo controllare con la macro \macro{FD\_ISSET}. In caso di errore la funzione restituisce -1 e gli insiemi non vengono toccati. -In Linux \func{select} modifica anche il valore di \param{timeout}, settandolo -al tempo restante; questo è utile quando la funzione viene interrotta da un -segnale, in tal caso infatti si ha un errore di \macro{EINTR}, ed occorre -rilanciare la funzione; in questo modo non è necessario ricalcolare tutte le -volte il tempo rimanente.\footnote{questo può causare problemi di portabilità - sia quando si trasporta codice scritto su Linux che legge questo valore, sia - quando si usano programmi scritti per altri sistemi che non dispongono di - questa caratteristica e ricalcolano \param{timeout} tutte le volte. In - genere la caratteristica è disponibile nei sistemi che derivano da System V - e non disponibile per quelli che derivano da BSD.} +In Linux \func{select} modifica anche il valore di \param{timeout}, +impostandolo al tempo restante; questo è utile quando la funzione viene +interrotta da un segnale, in tal caso infatti si ha un errore di +\macro{EINTR}, ed occorre rilanciare la funzione; in questo modo non è +necessario ricalcolare tutte le volte il tempo rimanente.\footnote{questo può + causare problemi di portabilità sia quando si trasporta codice scritto su + Linux che legge questo valore, sia quando si usano programmi scritti per + altri sistemi che non dispongono di questa caratteristica e ricalcolano + \param{timeout} tutte le volte. In genere la caratteristica è disponibile + nei sistemi che derivano da System V e non disponibile per quelli che + derivano da BSD.} Come accennato l'interfaccia di \func{select} è una estensione di BSD; anche System V ha introdotto una sua interfaccia per gestire l'\textit{I/O multiplexing}, basata sulla funzione \func{poll},\footnote{la funzione è prevista dallo standard XPG4, ed è stata introdotta in Linux come system - call a partire dal kernel 2.1.23 e dalle \acr{libc} 5.4.28.} il cui prototipo è: + call a partire dal kernel 2.1.23 e dalle \acr{libc} 5.4.28.} il cui +prototipo è: \begin{prototype}{sys/poll.h} {int poll(struct pollfd *ufds, unsigned int nfds, int timeout)} @@ -177,7 +179,7 @@ specificati da \param{ufds}. \bodydesc{La funzione restituisce il numero di file descriptor con attività in caso di successo, o 0 se c'è stato un timeout; in caso di errore viene - restituito -1 ed \var{errno} viene settata ai valori: + restituito -1 ed \var{errno} assumerà uno dei valori: \begin{errlist} \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno degli insiemi. @@ -248,10 +250,10 @@ vengono utilizzati solo per \var{revents} come valori in uscita). \end{table} La funzione ritorna, restituendo il numero di file per i quali si è verificata -una delle condizioni di attesa richieste o un errore. Lo stato dei file +una delle condizioni di attesa richieste od un errore. Lo stato dei file all'uscita della funzione viene restituito nel campo \var{revents} della -relativa struttura \type{pollfd}, che viene settato alla maschera binaria dei -valori riportati in \tabref{tab:file_pollfd_flags}, ed oltre alle tre +relativa struttura \type{pollfd}, che viene impostato alla maschera binaria +dei valori riportati in \tabref{tab:file_pollfd_flags}, ed oltre alle tre condizioni specificate tramite \var{events} può riportare anche l'occorrere di una condizione di errore. @@ -277,7 +279,7 @@ sostituisce i precedenti, ed aggiunge a \func{select} una nuova funzione \bodydesc{La funzione in caso di successo restituisce il numero di file descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual - caso \var{errno} viene settata ai valori: + caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato in uno degli insiemi. @@ -299,7 +301,7 @@ L'uso di \param{sigmask} race condition\footnote{in Linux però, non esistendo una system call apposita, la funzione è implementata nelle \acr{glibc} usando \func{select}, e la possibilità di una race condition resta.} quando si deve eseguire un test su -una variabile settata da un manipolatore sulla base dell'occorrenza di un +una variabile assegnata da un manipolatore sulla base dell'occorrenza di un segnale per decidere se lanciare \func{select}. Fra il test e l'esecuzione è presente una finestra in cui potrebbe arrivare il segnale che non sarebbe rilevato; la race condition diventa superabile disabilitando il segnale prima @@ -307,7 +309,7 @@ del test e riabilitandolo poi grazie all'uso di \param{sigmask}. -\subsection{L'\textsl{I/O asincrono}} +\subsection{L'I/O asincrono} \label{sec:file_asyncronous_io} Una modalità alternativa all'uso dell'\textit{I/O multiplexing} è quella di @@ -322,9 +324,9 @@ Abbiamo accennato in \secref{sec:file_open} che del flag \macro{O\_ASYNC},\footnote{l'uso del flag di \macro{O\_ASYNC} e dei comandi \macro{F\_SETOWN} e \macro{F\_GETOWN} per \func{fcntl} è specifico di Linux e BSD.} aprire un file in modalità asincrona, così come è possibile -attivare in un secondo tempo questa modalità settando questo flag attraverso +attivare in un secondo tempo questa modalità impostando questo flag attraverso l'uso di \func{fcntl} con il comando \macro{F\_SETFL} (vedi -\secref{sec:file_fcntl}). +\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 @@ -351,9 +353,9 @@ attraverso la struttura \type{siginfo\_t}, utilizzando la forma estesa \secref{sec:sig_sigaction}). Per far questo però occorre utilizzare le funzionalità dei segnali real-time -(vedi \secref{sec:sig_real_time}) settando esplicitamente con il comando +(vedi \secref{sec:sig_real_time}) impostando esplicitamente con il comando \macro{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di -I/O asincrono (il segnale di default è \macro{SIGIO}). In questo caso il +I/O asincrono (il segnale predefinito è \macro{SIGIO}). In questo caso il manipolatore tutte le volte che riceverà \macro{SI\_SIGIO} come valore del campo \var{si\_code}\footnote{il valore resta \macro{SI\_SIGIO} qualunque sia il segnale che si è associato all'I/O asincrono, ed indica appunto che il @@ -387,10 +389,11 @@ implementata sia direttamente nel kernel, che in user space attraverso l'uso di thread. Al momento\footnote{fino ai kernel della serie 2.4.x, nella serie 2.5.x è però iniziato un lavoro completo di riscrittura di tutto il sistema di I/O, che prevede anche l'introduzione di un nuovo layer per l'I/O - asincrono.} esiste una sola versione stabile di questa interfaccia, quella -delle \acr{glibc}, che è realizzata completamente in user space. Esistono -comunque vari progetti sperimentali (come il KAIO della SGI, o i patch di -Benjamin La Haise) che prevedono un supporto diretto da parte del kernel. + asincrono (effettuato a partire dal 2.5.32).} esiste una sola versione +stabile di questa interfaccia, quella delle \acr{glibc}, che è realizzata +completamente in user space. Esistono comunque vari progetti sperimentali +(come il KAIO della SGI, o i patch di Benjamin La Haise) che prevedono un +supporto diretto da parte del kernel. Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate attraverso l'uso di una apposita struttura \type{aiocb} (il cui nome sta per @@ -436,13 +439,13 @@ sul file da cui i dati saranno letti o scritti. Nel campo \var{aio\_buf} deve essere specificato l'indirizzo del buffer usato per l'I/O, ed in \var{aio\_nbytes} la lunghezza del blocco di dati da trasferire. -Il campo \var{aio\_reqprio} permette di settare la priorità delle operazioni +Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni di I/O.\footnote{in generale perché ciò sia possibile occorre che la piattaforma supporti questa caratteristica, questo viene indicato definendo le macro \macro{\_POSIX\_PRIORITIZED\_IO}, e - \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene settata a partire -da quella del processo chiamante (vedi \secref{sec:proc_priority}), cui viene -sottratto il valore di questo campo. + \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene impostata a +partire da quella del processo chiamante (vedi \secref{sec:proc_priority}), +cui viene sottratto il valore di questo campo. Il campo \var{aio\_lio\_opcode} è usato soltanto dalla funzione \func{lio\_listio}, che, come vedremo più avanti, permette di eseguire con una @@ -502,7 +505,7 @@ appena descritta; i rispettivi prototipi sono: \param{aiocbp}. \bodydesc{Le funzioni restituiscono 0 in caso di successo, e -1 in caso di - errore, nel qual caso \var{errno} viene settata ai valori: + errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato. \item[\macro{ENOSYS}] La funzione non è implementata. @@ -545,25 +548,16 @@ errore; il suo prototipo \param{aiocbp}. \bodydesc{La funzione restituisce 0 se le operazioni si sono concluse con - successo, altrimenti restituisce il codice di errore.} -% }, che viene salvato -% anche in \var{errno}, i valori possibili sono: -% \begin{errlist} -% \item[\macro{ENOSYS}] La funzione non è implementata. -% \item[\macro{EINPROGRESS}] L'operazione è ancora in corso. -% \item[\macro{EINVAL}] Si è specificato un valore non valido per i campi -% \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}. -% \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato. -% \end{errlist} -% più tutti quelli possibili per le sottostanti operazioni, .} + successo, altrimenti restituisce il codice di errore relativo al loro + fallimento.} \end{prototype} Se l'operazione non si è ancora completata viene restituito l'errore di \macro{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è conclusa con successo, altrimenti restituisce il codice dell'errore -verificatosi, ed esegue il corrispondente settaggio di \var{errno}. Il codice -può essere sia \macro{EINVAL} ed \macro{EBADF}, dovuti ad un valore errato per -\param{aiocbp}, che uno degli errori possibili durante l'esecuzione +verificatosi, ed esegue la corrispondente impostazione di \var{errno}. Il +codice può essere sia \macro{EINVAL} ed \macro{EBADF}, dovuti ad un valore +errato per \param{aiocbp}, che uno degli errori possibili durante l'esecuzione dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda del caso, i codici di errore delle system call \func{read}, \func{write} e \func{fsync}. @@ -639,7 +633,7 @@ da \param{aiocbp}. \bodydesc{La funzione restituisce il risultato dell'operazione con un codice di positivo, e -1 in caso di errore, che avviene qualora si sia specificato - un valore non valido di \param{fildes}, setta \var{errno} al valore + un valore non valido di \param{fildes}, imposta \var{errno} al valore \macro{EBADF}.} \end{prototype} @@ -682,8 +676,8 @@ specifica operazione; il suo prototipo operazioni specificate da \param{list}. \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state - completate, e -1 in caso di errore nel qual caso \var{errno} viene - settata ai valori: + completate, e -1 in caso di errore nel qual caso \var{errno} assumerà uno + dei valori: \begin{errlist} \item[\macro{EAGAIN}] Nessuna operazione è stata completata entro \param{timeout}. @@ -714,7 +708,7 @@ lettura o scrittura; il suo prototipo secondo la modalità \param{mode}. \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di - errore, nel qual caso \var{errno} viene settata ai valori: + errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\macro{EAGAIN}] Nessuna operazione è stata completata entro \param{timeout}. @@ -744,7 +738,7 @@ funzione, se viene specificato il valore \macro{LIO\_WAIT} la funzione si blocca fino al completamento di tutte le operazioni richieste; se invece si specifica \macro{LIO\_NOWAIT} la funzione ritorna immediatamente dopo aver messo in coda tutte le richieste. In questo caso il chiamante può richiedere -la notifica del completamento di tutte le richieste, settando l'argomento +la notifica del completamento di tutte le richieste, impostando l'argomento \param{sig} in maniera analoga a come si fa per il campo \var{aio\_sigevent} di \type{aiocb}. @@ -764,11 +758,11 @@ operazioni. Per questo motivo BSD 4.2\footnote{Le due funzioni sono riprese da BSD4.4 ed integrate anche dallo standard Unix 98; fino alle libc5 Linux usava \type{size\_t} come tipo dell'argomento \param{count}, una scelta logica, - che è stata dismessa per restare aderenti allo standard.} ha introdotto due -nuove system call, \func{readv} e \func{writev}, che permettono di effettuare -con una sola chiamata una lettura o una scrittura su una serie di buffer -(quello che viene chiamato \textsl{I/O vettorizzato}. I relativi prototipi -sono: + che però è stata dismessa per restare aderenti allo standard.} ha introdotto +due nuove system call, \func{readv} e \func{writev}, che permettono di +effettuare con una sola chiamata una lettura o una scrittura su una serie di +buffer (quello che viene chiamato \textsl{I/O vettorizzato}. I relativi +prototipi sono: \begin{functions} \headdecl{sys/uio.h} @@ -781,8 +775,8 @@ sono: specificati da \param{vector}. \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti in - caso di successo, e -1 in caso di errore, nel qual caso \var{errno} viene - settata ai valori: + caso di successo, e -1 in caso di errore, nel qual caso \var{errno} + assumerà uno dei valori: \begin{errlist} \item[\macro{EBADF}] si è specificato un file descriptor sbagliato. \item[\macro{EINVAL}] si è specificato un valore non valido per uno degli @@ -820,10 +814,12 @@ struct iovec { \label{fig:file_iovec} \end{figure} -I buffer da utilizzare sono specificati attraverso l'argomento \var{vector} che -è un vettore di tale strutture, la cui lunghezza è specificata da \param{count}. -Essi verranno letti (o scritti) nell'ordine in cui li si sono specificati. - +I buffer da utilizzare sono indicati attraverso l'argomento \param{vector} che +è un vettore di strutture \var{iovec}, la cui lunghezza è specificata da +\param{count}. Ciascuna struttura dovrà essere inizializzata per +opportunamente per indicare i vari buffer da/verso i quali verrà eseguito il +trasferimento dei dati. Essi verranno letti (o scritti) nell'ordine in cui li +si sono specificati nel vettore \var{vector}. \subsection{File mappati in memoria} @@ -831,23 +827,37 @@ Essi verranno letti (o scritti) nell'ordine in cui li si sono specificati. Una modalità alternativa di I/O, che usa una interfaccia completamente diversa rispetto a quella classica vista in \capref{cha:file_unix_interface}, è il -cosiddetto \textit{memory-mapped I/O}, che attraverso il meccanismo della +cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della \textsl{paginazione}\index{paginazione} usato dalla memoria virtuale (vedi -\secref{sec:proc_mem_gen}) permette di \textsl{mappare} il contenuto di un -file in una sezione dello spazio di indirizzi del processo. +\secref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un +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. + +\begin{figure}[htb] + \centering + \includegraphics[width=9.5cm]{img/mmap_layout} + \caption{Disposizione della memoria di un processo quando si esegue la + mappatura in memoria di un file.} + \label{fig:file_mmap_layout} +\end{figure} Tutto questo comporta una notevole semplificazione delle operazioni di I/O, in quanto non sarà più necessario utilizzare dei buffer intermedi su cui appoggiare i dati da traferire, ma questi potranno essere acceduti -direttamente dalla sezione di memoria; inoltre questa interfaccia -è più efficiente delle usuali funzioni di I/O, in quanto permette di caricare -in memoria solo le parti del file che sono effettivamente usate ad un dato +direttamente nella sezione di memoria mappata; inoltre questa interfaccia è +più efficiente delle usuali funzioni di I/O, in quanto permette di caricare in +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'acceso +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. @@ -857,40 +867,40 @@ 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 - mapping}, la prima di queste è \func{mmap}, che esegue la mappatura in -memoria un file; il suo prototipo è: +L'interfaccia prevede varie funzioni per la gestione del \textit{memory mapped + I/O}, la prima di queste è \func{mmap}, che serve ad eseguire la mappatura +in memoria di un file; il suo prototipo è: \begin{functions} \headdecl{unistd.h} \headdecl{sys/mman.h} - \funcdecl{void * mmap(void *start, size\_t length, int prot, int flags, int + \funcdecl{void * mmap(void * start, size\_t length, int prot, int flags, int fd, off\_t offset)} Esegue la mappatura in memoria del file \param{fd}. \bodydesc{La funzione restituisce il puntatore alla zona di memoria mappata in caso di successo, e \macro{MAP\_FAILED} (-1) in caso di errore, nel - qual caso \var{errno} viene settata ai valori: + qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\macro{EBADF}] Il file descriptor non è valido, e non si è usato \macro{MAP\_ANONYMOUS}. \item[\macro{EACCES}] Il file descriptor non si riferisce ad un file - normale, o si è richiesto \macro{MAP\_PRIVATE} ma \param{fd} non è - aperto in lettura, o si è richiesto \macro{MAP\_SHARED} e settato + regolare, o si è richiesto \macro{MAP\_PRIVATE} ma \param{fd} non è + aperto in lettura, o si è richiesto \macro{MAP\_SHARED} e impostato \macro{PROT\_WRITE} ed \param{fd} non è aperto in lettura/scrittura, o - si è settato \macro{PROT\_WRITE} ed \param{fd} è in + si è impostato \macro{PROT\_WRITE} ed \param{fd} è in \textit{append-only}. \item[\macro{EINVAL}] I valori di \param{start}, \param{length} o \param{offset} non sono validi (o troppo grandi o non allineati sulla dimensione delle pagine). - \item[\macro{ETXTBSY}] Si è settato \macro{MAP\_DENYWRITE} ma \param{fd} è - aperto in scrittura. + \item[\macro{ETXTBSY}] Si è impostato \macro{MAP\_DENYWRITE} ma \param{fd} + è aperto in scrittura. \item[\macro{EAGAIN}] Il file è bloccato, o si è bloccata troppa memoria. \item[\macro{ENOMEM}] Non c'è memoria o si è superato il limite sul numero di mappature possibili. - \item[\macro{ENODEV}] Il filesystem di \param{fd} no supporta il memory + \item[\macro{ENODEV}] Il filesystem di \param{fd} non supporta il memory mapping. \end{errlist} } @@ -899,18 +909,8 @@ memoria un file; il suo prototipo La funzione richiede di mappare in memoria la sezione del file \param{fd} a partire da \param{offset} per \param{lenght} byte, preferibilmente all'indirizzo \param{start}. Il valore di \param{offset} deve essere un -multiplo della dimensione di una pagina di memoria. Il valore dell'argomento -\param{prot} indica la protezione\footnote{in Linux la memoria reale è divisa - in pagine: ogni processo vede la sua memoria attraverso uno o più segmenti - lineari di memoria virtuale. Per ciascuno di questi segmenti il kernel - mantiene nella \textit{page table} la mappatura sulle pagine di memoria - reale, ed le modalità di accesso (lettura, esecuzione, scrittura); una loro - violazione causa quella che si chiama una \textit{segment violation}, e la - relativa emissione del segnale \macro{SIGSEGV}.} da applicare al segmento di -memoria e deve essere specificato come maschera binaria ottenuta dall'OR di -uno o più dei valori riportati in \tabref{tab:file_mmap_flag}; il valore -specificato deve essere compatibile con la modalità con cui si è aperto il -file. +multiplo della dimensione di una pagina di memoria. + \begin{table}[htb] \centering @@ -931,8 +931,21 @@ file. \label{tab:file_mmap_prot} \end{table} -L'argomento \param{flags} specifica qual'è il tipo di oggetto mappato, le -opzioni relative alle modalità con cui è effettuata la mappatura e alle + +Il valore dell'argomento \param{prot} indica la protezione\footnote{in Linux + la memoria reale è divisa in pagine: ogni processo vede la sua memoria + attraverso uno o più segmenti lineari di memoria virtuale. Per ciascuno di + questi segmenti il kernel mantiene nella \textit{page table} la mappatura + sulle pagine di memoria reale, ed le modalità di accesso (lettura, + esecuzione, scrittura); una loro violazione causa quella che si chiama una + \textit{segment violation}, e la relativa emissione del segnale + \macro{SIGSEGV}.} da applicare al segmento di memoria e deve essere +specificato come maschera binaria ottenuta dall'OR di uno o più dei valori +riportati in \tabref{tab:file_mmap_flag}; il valore specificato deve essere +compatibile con la modalità di accesso con cui si è aperto il file. + +L'argomento \param{flags} specifica infine qual'è il tipo di oggetto mappato, +le opzioni relative alle modalità con cui è effettuata la mappatura e alle modalità con cui le modifiche alla memoria mappata vengono condivise o mantenute private al processo che le ha effettuate. Deve essere specificato come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in @@ -948,7 +961,7 @@ come maschera binaria ottenuta dall'OR di uno o pi \hline \macro{MAP\_FIXED} & Non permette di restituire un indirizzo diverso da \param{start}, se questo non può essere usato - \func{mmap} fallisce. Se si setta questo flag il + \func{mmap} fallisce. Se si imposta questo flag il valore di \param{start} deve essere allineato alle dimensioni di una pagina. \\ \macro{MAP\_SHARED} & I cambiamenti sulla memoria mappata vengono @@ -975,12 +988,12 @@ come maschera binaria ottenuta dall'OR di uno o pi \macro{MAP\_EXECUTABLE}& Ignorato. \\ \macro{MAP\_NORESERVE} & Si usa con \macro{MAP\_PRIVATE}. Non riserva delle pagine di swap ad uso del meccanismo di - \textit{copy on write} per mantenere le modifiche - fatte alla regione mappata, in + \textit{copy on write} per mantenere le + modifiche fatte alla regione mappata, in questo caso dopo una scrittura, se non c'è più memoria disponibile, si ha l'emissione di un \macro{SIGSEGV}. \\ - \macro{MAP\_LOCKED} & Se settato impedisce lo swapping delle pagine + \macro{MAP\_LOCKED} & Se impostato impedisce lo swapping delle pagine mappate. \\ \macro{MAP\_GROWSDOWN} & Usato per gli stack. Indica che la mappatura deve essere effettuata con gli @@ -989,7 +1002,7 @@ come maschera binaria ottenuta dall'OR di uno o pi argomenti \param{fd} e \param{offset} sono ignorati.\footnotemark\\ \macro{MAP\_ANON} & Sinonimo di \macro{MAP\_ANONYMOUS}, deprecato.\\ - \macro{MAP\_FILE} & Valore di compatibiità, deprecato.\\ + \macro{MAP\_FILE} & Valore di compatibilità, deprecato.\\ \hline \end{tabular} \caption{Valori possibili dell'argomento \param{flag} di \func{mmap}.} @@ -1001,35 +1014,85 @@ come maschera binaria ottenuta dall'OR di uno o pi \footnotetext{L'uso di questo flag con \macro{MAP\_SHARED} è stato implementato in Linux a partire dai kernel della serie 2.4.x.} -Un file viene sempre mappato su multipli delle dimensioni di una pagina, -qualora esso sia più corto la parte restante è riempita con zeri; eventuali -scritture in quella zona di memoria non vengono riportate sul file. Se le -dimensioni del file cambiano (esso viene esteso o troncato), non è specificato -quale effetto viene a aversi sulle pagine di memoria che corrispondono alle -regioni aggiunte o tolte. - -Si tenga presente che non tutti i file possono venire mappati in memoria, la -mappatura infatti introduce una corrispondenza biunivoca fra una sezione di un -file ed una sezione di memoria, pertanto si può parlare tanto di file mappato -in memoria, quanto di memoria mappata su file. Questo comporta che ad esempio -non è possibile mappare in memoria pipe, socket e fifo, per le quali non ha -senso parlare di \textsl{sezione}. Lo stesso vale anche per alcuni file di -dispositivo, che non dispongono della relativa operazione \var{mmap} (si -ricordi quanto esposto in \secref{sec:file_vfs_work}), ma esistono anche casi -(un esempio è l'interfaccia ponte PCI-VME del chip Universe) di dispositivi -che sono utilizzabili praticamente solo con questa interfaccia. - -Passando attraverso una \func{fork} i file mappati in memoria vengono -ereditati in maniera trasparente dal processo figlio, mantenendo gli stessi -attributi avuti nel padre; così se si è usato \macro{MAP\_SHARED} padre e -figlio accederanno allo stesso file in maniera condivisa, mentre se si è usato -\macro{MAP\_PRIVATE} ciascuno di essi manterrà una sua versione privata -indipendente. Non c'è invece nessun passaggio attraverso una \func{exec}, dato -che quest'ultima sostituisce tutto lo spazio degli indirizzi di un processo -con quello di un nuovo programma. +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 (\macro{SIGSEGV}), dato che +i permessi sul segmento di memoria relativo non consentono questo tipo di +accesso. + +È 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 +ritenere che anch'essi debbano generare un segnale di violazione di accesso; +questo però non tiene conto del fatto che, essendo basata sul meccanismo della +paginazione, la mappatura in memoria non può che essere eseguita su un +segmento di dimensioni rigorosamente multiple di quelle di una pagina, ed in +generale queste potranno non corrispondere alle dimensioni effettive del file +o della sezione che si vuole mappare. Il caso più comune è quello illustrato +in \figref{fig:file_mmap_boundary}, in cui la sezione di file non rientra nei +confini di una pagina: in tal caso verrà il file sarà 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 \macro{SIGSEGV} +poiché essa è presente nello spazio di indirizzi del processo, anche se non è +mappata sul file. Il comportamento del sistema è quello di restituire un +valore nullo per quanto viene letto, e di non riportare su file quanto viene +scritto. + +Un caso più complesso è quello che si viene a creare quando le dimensioni del +file mappato sono più corte delle dimensioni della mappatura, oppure quando il +file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a +quella della mappatura in memoria. + +\begin{figure}[htb] + \centering + \includegraphics[width=13cm]{img/mmap_exceed} + \caption{Schema della mappatura in memoria di file di dimensioni inferiori + alla lunghezza richiesta.} + \label{fig:file_mmap_exceed} +\end{figure} + +In questa situazione, per la sezione di pagina parzialmente coperta dal +contenuto del file, vale esattamente quanto visto in precedenza; invece per la +parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non +sarà più possibile, ma il segnale emesso non sarà \macro{SIGSEGV}, ma +\macro{SIGBUS}, come illustrato in \figref{fig:file_mmap_exceed}. + +Non tutti i file possono venire mappati in memoria, dato che, come illustrato +in \figref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza +biunivoca fra una sezione di un file ed una sezione di memoria. Questo +comporta che ad esempio non è possibile mappare in memoria file descriptor +relativi a pipe, socket e fifo, per i quali non ha senso parlare di +\textsl{sezione}. Lo stesso vale anche per alcuni file di dispositivo, che non +dispongono della relativa operazione \var{mmap} (si ricordi quanto esposto in +\secref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi di +dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe) +che sono utilizzabili solo con questa interfaccia. + +Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene +copiato integralmente, i file mappati in memoria verranno ereditati in maniera +trasparente dal processo figlio, mantenendo gli stessi attributi avuti nel +padre; così se si è usato \macro{MAP\_SHARED} padre e figlio accederanno allo +stesso file in maniera condivisa, mentre se si è usato \macro{MAP\_PRIVATE} +ciascuno di essi manterrà una sua versione privata indipendente. Non c'è +invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima +sostituisce tutto lo spazio degli indirizzi di un processo con quello di un +nuovo programma. Quando si effettua la mappatura di un file vengono pure modificati i tempi ad -esso associati (si ricordi quanto esposto in \secref{sec:file_file_times}). Il +esso associati (di cui si è trattato in \secref{sec:file_file_times}). Il valore di \var{st\_atime} può venir cambiato in qualunque istante a partire dal momento in cui la mappatura è stata effettuata: il primo riferimento ad una pagina mappata su un file aggiorna questo tempo. I valori di @@ -1041,19 +1104,19 @@ o in corrispondenza di una eventuale \func{msync}. Dato per i file mappati in memoria le operazioni di I/O sono gestite direttamente dalla memoria virtuale, occorre essere consapevoli delle interazioni che possono esserci con operazioni effettuate con l'interfaccia -standard dei file di \capref{sec:file_unix_interface}. Il problema è che una +standard dei file di \capref{cha:file_unix_interface}. Il problema è che una volta che si è mappato un file, le operazioni di lettura e scrittura saranno eseguite sulla memoria, e riportate su disco in maniera autonoma dal sistema della memoria virtuale. Pertanto se si modifica un file con l'interfaccia standard queste modifiche potranno essere visibili o meno a seconda del momento in cui la memoria -virtuale leggerà dal disco in memoria quella sezione del file, perciò è del -tutto indefinito il risultato della modifica nei confronti del contenuto della -memoria mappata. +virtuale trasporterà dal disco in memoria quella sezione del file, perciò è +del tutto imprevedibile il risultato della modifica di un file nei confronti +del contenuto della memoria mappata su cui è mappato. -Se è, per quanto appena visto, sconsigliabile eseguire scritture su file -attraverso l'interfaccia standard quando lo si è mappato in memoria, è invece +Per quanto appena visto, è sempre sconsigliabile eseguire scritture su file +attraverso l'interfaccia standard, quando lo si è mappato in memoria, è invece possibile usare l'interfaccia standard per leggere un file mappato in memoria, purché si abbia una certa cura; infatti l'interfaccia dell'I/O mappato in memoria mette a disposizione la funzione \func{msync} per sincronizzare il @@ -1067,7 +1130,7 @@ contenuto della memoria mappata con il file su disco; il suo prototipo Sincronizza i contenuti di una sezione di un file mappato in memoria. \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di - errore nel qual caso \var{errno} viene settata ai valori: + errore nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\macro{EINVAL}] O \param{start} non è multiplo di \macro{PAGESIZE}, o si è specificato un valore non valido per \param{flags}. @@ -1084,16 +1147,6 @@ relativi tempi di modifica. In questo modo si di \func{msync} le funzioni dell'interfaccia standard troveranno un contenuto del file aggiornato. -L'argomento \param{flag} è specificato come maschera binaria composta da un OR -dei valori riportati in \tabref{tab:file_mmap_rsync}, di questi però -\macro{MS\_ASYNC} e \macro{MS\_SYNC} sono incompatibili; con il primo valore -infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al -meccanismo della memoria virtuale, ritornando subito, mentre con il secondo -attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo -flag fa invalidare le pagine di cui si richiede la sincronizzazione per tutte -le mappature dello stesso file, così che esse possano essere immediatamente -aggiornate ai nuovi valori. - \begin{table}[htb] \centering \footnotesize @@ -1112,6 +1165,16 @@ aggiornate ai nuovi valori. \label{tab:file_mmap_rsync} \end{table} +L'argomento \param{flag} è specificato come maschera binaria composta da un OR +dei valori riportati in \tabref{tab:file_mmap_rsync}, di questi però +\macro{MS\_ASYNC} e \macro{MS\_SYNC} sono incompatibili; con il primo valore +infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al +meccanismo della memoria virtuale, ritornando subito, mentre con il secondo +attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo +flag fa invalidare le pagine di cui si richiede la sincronizzazione per tutte +le mappature dello stesso file, così che esse possano essere immediatamente +aggiornate ai nuovi valori. + Una volta che si sono completate le operazioni di I/O si può eliminare la mappatura della memoria usando la funzione \func{munmap}, il suo prototipo è: \begin{functions} @@ -1123,7 +1186,7 @@ mappatura della memoria usando la funzione \func{munmap}, il suo prototipo Rilascia la mappatura sulla sezione di memoria specificata. \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di - errore nel qual caso \var{errno} viene settata ai valori: + errore nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\macro{EINVAL}] L'intervallo specificato non ricade in una zona precedentemente mappata. @@ -1139,8 +1202,8 @@ pagine contenute (anche parzialmente) nell'intervallo indicato, verr Indicare un intervallo che non contiene pagine mappate non è un errore. Alla conclusione del processo, ogni pagina mappata verrà automaticamente -rilasciata, mentre la chiusura del file descriptor non ha alcun effetto sulla -mappatura della memoria. +rilasciata, mentre la chiusura del file descriptor usato per effettuare la +mappatura in memoria non ha alcun effetto sulla stessa. \section{Il file locking} @@ -1165,23 +1228,275 @@ bloccare l'accesso al file da parte di altri processi, cos sovrapposizioni, e garantire la atomicità delle operazioni di scrittura. + \subsection{L'\textit{advisory locking}} \label{sec:file_record_locking} La prima modalità di file locking che è stata implementata nei sistemi -unix-like è quella che viene usualmente chiamata \textit{advisory locking}, in -quanto è il processo, e non il sistema, che si incarica di verificare se -esiste una condizione di blocco per l'accesso ai file. +unix-like è quella che viene usualmente chiamata \textit{advisory + locking},\footnote{Stevens in APUE fa riferimento a questo argomento come al + \textit{record locking}, dizione utilizzata anche dal manuale delle + \acr{glibc}; nelle pagine di manuale si parla di \textit{discretionary file + lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock}, + mentre questo nome viene usato anche da Stevens per riferirsi al + \textit{file locking} di POSIX. Dato che la dizione \textit{record locking} + è quantomeno ambigua in quanto non esiste niente che possa fare riferimento + al concetto di \textit{record}, alla fine si è scelto di mantenere il nome + \textit{advisory locking}.} in quanto sono i singoli processi, e non il +sistema, che si incaricano di asserire e verificare se esistono delle +condizioni di blocco per l'accesso ai file. Questo significa che le funzioni +\func{read} o \func{write} non risentono affatto della presenza di un +eventuale blocco, e che sta ai vari processi controllare esplicitamente lo +stato dei file condivisi prima di accedervi, implementando un opportuno +protocollo. + +In generale si distinguono due tipologie di blocco per un file: la prima è il +cosiddetto \textit{shared lock}, detto anche \textit{read lock} in quanto +serve a bloccare l'accesso in scrittura su un file affinché non venga +modificato mentre lo si legge. Si parla di \textsl{blocco condiviso} in quanto +più processi possono richiedere contemporaneamente uno \textit{shared lock} +su un file per proteggere il loro accesso in lettura. + +La seconda tipologia è il cosiddetto \textit{exclusive lock}, detto anche +\textit{write lock} in quanto serve a bloccare l'accesso su un file (sia in +lettura che in scrittura) da parte di altri processi mentre lo si sta +scrivendo. Si parla di \textsl{blocco esclusivo} appunto perché un solo +processo alla volta può richiedere un \textit{exclusive lock} su un file per +proteggere il suo accesso in scrittura. + +In Linux sono disponibili due interfacce per utilizzare l'\textit{advisory + locking}, la prima è quella derivata da BSD, che è basata sulla funzione +\func{flock}, la seconda è quella standardizzata da POSIX.1 (derivata da +System V), che è basata sulla funzione \func{fcntl}. I \textit{file lock} +sono implementati in maniera completamente indipendente nelle due interfacce, +che pertanto possono coesistere senza interferenze. + +Entrambe le interfacce prevedono la stessa procedura di funzionamento: si +inizia sempre con il richiere l'opportuno \textit{file lock} (un +\textit{exclusive lock} per una scrittura, uno \textit{shared lock} per una +lettura) prima di eseguire l'accesso ad un file. Se il lock viene acquisito +il processo prosegue l'esecuzione, altrimenti (a meno di non aver richiesto un +comportamento non bloccante) viene posto in stato di sleep. Una volta finite +le operazioni sul file si deve provvedere a rimuovere il lock. Si ricordi che +la condizione per acquisire uno \textit{shared lock} è che il file non abbia +già un \textit{exclusive lock} attivo, mentre per acquisire un +\textit{exclusive lock} non deve essere presente nessun tipo di blocco. + + +\subsection{La funzione \func{flock}} +\label{sec:file_flock} + + +La prima interfaccia per il file locking, quella derivata da BSD, permette di +eseguire un blocco solo su un intero file; la funzione usata per richiedere e +rimuovere un \textit{file lock} è \func{flock}, ed il suo prototipo è: +\begin{prototype}{sys/file.h}{int flock(int fd, int operation)} + + Applica o rimuove un \textit{file lock} sul file \param{fd}. + + \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di + errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EWOULDBLOCK}] Il file ha già un blocco attivo, e si è + specificato \macro{LOCK\_NB}. + \end{errlist} + } +\end{prototype} +La funzione può essere usata per acquisire o rilasciare un blocco a seconda di +quanto specificato tramite il valore dell'argomento \param{operation}, questo +viene interpretato come maschera binaria, e deve essere passato utilizzando le +costanti riportate in \tabref{tab:file_flock_operation}. +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|l|} + \hline + \textbf{Valore} & \textbf{Significato} \\ + \hline + \hline + \macro{LOCK\_SH} & Asserisce uno \textit{shared lock} sul file.\\ + \macro{LOCK\_EX} & Asserisce un \textit{esclusive lock} sul file.\\ + \macro{LOCK\_UN} & Sblocca il file.\\ + \macro{LOCK\_NB} & Impedisce che la funzione si blocchi nella + richiesta di un \textit{file lock}.\\ + \hline + \end{tabular} + \caption{Valori dell'argomento \param{operation} di \func{flock}.} + \label{tab:file_flock_operation} +\end{table} + +I primi due valori, \macro{LOCK\_SH} e \macro{LOCK\_EX} permettono di +richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera +alternativa. Se si specifica anche \macro{LOCK\_NB} la funzione non si +bloccherà qualora il lock non possa essere aqcuisito, ma ritornerà subito con +un errore di \macro{EWOULDBLOCK}. Per rilasciare un lock si dovrà invece usare +\macro{LOCK\_NB}. + +La semantica del file locking di BSD è diversa da quella del file locking +POSIX, in particolare per quanto riguarda il comportamento dei lock nei +confronti delle due funzioni \func{dup} e \func{fork}. Per capire queste +differenze occore prima descrivere con maggiore dettaglio come viene +realizzato il file locking nel kernel. + +In \figref{fig:file_flock_struct} si è riportato uno schema essenziale +dell'implementazione del file locking in Linux; il punto fondamentale da +capire è che un lock, qualunque sia l'interfaccia che si usa, anche se +richiesto attraverso un file descriptor, agisce sempre su un file; perciò le +informazioni relative agli eventuali \textit{file lock} sono mantenute a +livello di inode,\footnote{in particolare, come accennato in + \figref{fig:file_flock_struct}, i \textit{file lock} sono mantenuti un una + \textit{linked list}\index{linked list} di strutture \var{file\_lock}. La + lista è referenziata dall'indirizzo di partenza mantenuto dal campo + \var{i\_flock} della struttura \var{inode} (per le definizioni esatte si + faccia riferimento al file \file{fs.h} nei sorgenti del kernel). Un bit del + campo \var{fl\_flags} di specifica se si tratta di un lock in semantica BSD + (\macro{FL\_FLOCK}) o POSIX (\macro{FL\_POSIX}).} dato che questo è l'unico +riferimento in comune che possono avere due processi diversi che aprono lo +stesso file. + +\begin{figure}[htb] + \centering + \includegraphics[width=13cm]{img/file_flock} + \caption{Schema dell'architettura del file locking, nel caso particolare + del suo utilizzo da parte dalla funzione \func{flock}.} + \label{fig:file_flock_struct} +\end{figure} + +La richiesta di un file lock prevede una scansione della lista per determinare +se l'acquisizione è possibile, ed in caso positivo l'aggiunta di un nuovo +elemento.\footnote{cioè una nuova struttura \var{file\_lock}.} Nel caso dei +lock creati con \func{flock} la semantica della funzione prevede che sia +\func{dup} che \func{fork} non creino ulteriori istanze di un \textit{file + lock} quanto piuttosto degli ulteriori riferimenti allo stesso. Questo viene +realizzato dal kernel associando ad ogni nuovo \textit{file lock} un +puntatore\footnote{il puntatore è mantenuto nel campo \var{fl\_file} di + \var{file\_lock}, e viene utilizzato solo per i lock creati con la semantica + BSD.} alla voce nella \textit{file table} da cui si è richiesto il blocco, +che così ne identifica il titolare. + +Questa struttura comporta che, quando si richiede la rimozione di un file +lock, il kernel acconsenta solo se la richiesta proviene da un file descriptor +che fa riferimento ad una voce nella file table corrispondente a quella +registrata nel blocco. Allora se ricordiamo quanto visto in +\secref{sec:file_dup} e \secref{sec:file_sharing}, e cioè che i file +descriptor duplicati e quelli ereditati in un processo figlio puntano sempre +alla stessa voce nella file table, si può capire immediatamente quali sono le +conseguenze nei confronti delle funzioni \func{dup} e \func{fork}. + +Sarà cioè possibile rimuovere un file lock attraverso uno qualunque dei file +descriptor che fanno riferimento alla stessa voce nella file table, quindi +anche se questo è diverso da quello con cui lo si è +creato,\footnote{attenzione, questo non vale se il file descriptor fa + riferimento allo stesso file, ma attraverso una voce diversa della file + table, come accade tutte le volte che si apre più volte lo stesso file.} o +se si esegue la rimozione in un processo figlio; inoltre una volta tolto un +file lock, la rimozione avrà effetto su tutti i file descriptor che +condividono la stessa voce nella file table, e quindi, nel caso di file +descriptor ereditati attraverso una \func{fork}, anche su processi diversi. + +Infine, per evitare che la terminazione imprevista di un processo lasci attivi +dei file lock, è previsto che quando un file viene chiuso il kernel provveda +anche a rimuovere tutti i lock ad esso associati. Anche in questo caso occorre +tenere presente cosa succede quando si hanno file descriptor duplicati; in tal +caso infatti il file non verrà effettivamente chiuso (ed il lock rimosso) +fintanto che non viene rilasciata la relativa voce nella file table; la +rimozione cioè avverrà solo quando tutti i file descriptor che fanno +riferimento alla stessa voce sono stati chiusi, quindi, nel caso ci siano +processi figli che mantengono ancora aperto un file descriptor, il lock non +sarà rilasciato. + + +\subsection{Il file locking POSIX} +\label{sec:file_posix_lock} + +La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è +quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo +già trattato questa funzione nelle sue molteplici funzionalità in +\secref{sec:file_fcntl}, quando la si impiega per il \textit{file locking} +però essa viene usata secondo il prototipo: +\begin{prototype}{fcntl.h}{int fcntl(int fd, int cmd, struct flock *lock)} + + Applica o rimuove un \textit{file lock} sul file \param{fd}. + + \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di + errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\macro{EACCES}] L'operazione è proibita per la presenza di + \textit{file lock} da parte di altri processi. + \item[\macro{ENOLCK}] Il sistema non ha le risorse per il locking: ci sono + troppi segmenti di lock aperti, si è esaurita la tabella dei lock, o il + protocollo per il locking remoto è fallito. + \item[\macro{EDEADLK}] Si è richiesto un lock su una regione bloccata da + un altro processo che è a sua volta in attesa dello sblocco di un lock + mantenuto dal processo corrente; si avrebbe pertanto un + \textit{deadlock}. Non è garantito che il sistema riconosca sempre + questa situazione. + \item[\macro{EINTR}] La funzione è stata interrotta da un segnale prima di + poter acquisire un lock. + \end{errlist} + ed inoltre \macro{EBADF}, \macro{EFAULT}. + } +\end{prototype} + +Si tenga presente che \func{flock} non è in grado di funzionare per i file +manetenuti su NFS, in questo caso, se si ha la necessità di eseguire il +\textit{file locking}, occorre usare l'interfaccia basata su \func{fcntl} che +può funzionare anche attraverso NFS, a condizione che sia il client che il +server supportino questa funzionalità. + +La standardizzatione operata con POSIX.1 ha adottato le API per il +\textit{file locking} originarie di System V, basate sulla funzione -\subsection{Il \textit{mandatory locking}} -\label{sec:file_mand_locking} -Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4, +Al contrario di \func{flock} con \func{fcntl} è possibile bloccare anche solo +delle sezioni di un file. La funzione prende come argomento una struttura +\var{flock} la cui definizione è riportata in \figref{fig:struct_flock}. +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{} +struct flock { + short int l_type; /* Type of lock: F_RDLCK, F_WRLCK, or F_UNLCK. */ + short int l_whence; /* Where `l_start' is relative to (like `lseek'). */ + off_t l_start; /* Offset where the lock begins. */ + off_t l_len; /* Size of the locked area; zero means until EOF. */ + pid_t l_pid; /* Process holding the lock. */ +}; + \end{lstlisting} + \end{minipage} + \normalsize + \caption{La struttura \type{flock}, usata da \func{fcntl} per il file + locking.} + \label{fig:struct_flock} +\end{figure} + + + +\subsection{Il \textit{mandatory locking}} +\label{sec:file_mand_locking} + +Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4, +per introdurre un file locking che come dice il nome, fosse effettivo +indipendentemente dai controlli eseguiti da un processo. Con il +\textit{mandatory locking} infatti è possibile far eseguire il blocco del file +direttamente al sistema, così che anche qualora non si predisponessero le +opportune verifiche nei processi, questo verrebbe comunque rispettato. + +Per poter utilizzare il \textit{mandatory locking} è stato introdotto un +utilizzo particolare del bit \acr{suid}. Se si ricorda quanto esposto in +\secref{sec:file_suid_sgid}), esso viene di norma utilizzato per cambiare +l'userid effettivo con cui viene eseguito un programma, ed è pertanto sempre +associato alla presenza del permesso di esecuzione. Impostando questo bit su +un file senza permesso di esecuzione in un sistema che supporta il +\textit{mandatory locking}, fa sì che quest'ultimo venga attivato per il file +in questione. In questo modo una combinazione dei permessi originariamente non +contemplata, in quanto senza significato, diventa l'indicazione della presenza +o meno del \textit{mandatory locking}.