3 %% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
11 \chapter{La gestione avanzata dei file}
12 \label{cha:file_advanced}
14 In questo capitolo affronteremo le tematiche relative alla gestione avanzata
15 dei file. In particolare tratteremo delle funzioni di input/output avanzato,
16 che permettono una gestione più sofisticata dell'I/O su file, a partire da
17 quelle che permettono di gestire l'accesso contemporaneo a più file, per
18 concludere con la gestione dell'I/O mappato in memoria. Dedicheremo poi la
19 fine del capitolo alle problematiche del \textit{file locking}.
22 \section{L'\textit{I/O multiplexing}}
23 \label{sec:file_multiplexing}
25 Uno dei problemi che si presentano quando si deve operare contemporaneamente
26 su molti file usando le funzioni illustrate in
27 cap.~\ref{cha:file_unix_interface} e cap.~\ref{cha:files_std_interface} è che
28 si può essere bloccati nelle operazioni su un file mentre un altro potrebbe
29 essere disponibile. L'\textit{I/O multiplexing} nasce risposta a questo
30 problema. In questa sezione forniremo una introduzione a questa problematica
31 ed analizzeremo le varie funzioni usate per implementare questa modalità di
35 \subsection{La problematica dell'\textit{I/O multiplexing}}
36 \label{sec:file_noblocking}
38 Abbiamo visto in sez.~\ref{sec:sig_gen_beha}, affrontando la suddivisione fra
39 \textit{fast} e \textit{slow} system call,\index{system~call~lente} che in
40 certi casi le funzioni di I/O possono bloccarsi indefinitamente.\footnote{si
41 ricordi però che questo può accadere solo per le pipe, i socket ed alcuni
42 file di dispositivo\index{file!di~dispositivo}; sui file normali le funzioni
43 di lettura e scrittura ritornano sempre subito.} Ad esempio le operazioni
44 di lettura possono bloccarsi quando non ci sono dati disponibili sul
45 descrittore su cui si sta operando.
47 Questo comportamento causa uno dei problemi più comuni che ci si trova ad
48 affrontare nelle operazioni di I/O, che si verifica quando si deve operare con
49 più file descriptor eseguendo funzioni che possono bloccarsi senza che sia
50 possibile prevedere quando questo può avvenire (il caso più classico è quello
51 di un server in attesa di dati in ingresso da vari client). Quello che può
52 accadere è di restare bloccati nell'eseguire una operazione su un file
53 descriptor che non è ``\textsl{pronto}'', quando ce ne potrebbe essere un
54 altro disponibile. Questo comporta nel migliore dei casi una operazione
55 ritardata inutilmente nell'attesa del completamento di quella bloccata, mentre
56 nel peggiore dei casi (quando la conclusione della operazione bloccata dipende
57 da quanto si otterrebbe dal file descriptor ``\textsl{disponibile}'') si
58 potrebbe addirittura arrivare ad un \itindex{deadlock} \textit{deadlock}.
60 Abbiamo già accennato in sez.~\ref{sec:file_open} che è possibile prevenire
61 questo tipo di comportamento delle funzioni di I/O aprendo un file in
62 \textsl{modalità non-bloccante}, attraverso l'uso del flag \const{O\_NONBLOCK}
63 nella chiamata di \func{open}. In questo caso le funzioni di input/output
64 eseguite sul file che si sarebbero bloccate, ritornano immediatamente,
65 restituendo l'errore \errcode{EAGAIN}. L'utilizzo di questa modalità di I/O
66 permette di risolvere il problema controllando a turno i vari file descriptor,
67 in un ciclo in cui si ripete l'accesso fintanto che esso non viene garantito.
68 Ovviamente questa tecnica, detta \itindex{polling} \textit{polling}, è
69 estremamente inefficiente: si tiene costantemente impiegata la CPU solo per
70 eseguire in continuazione delle system call che nella gran parte dei casi
73 Per superare questo problema è stato introdotto il concetto di \textit{I/O
74 multiplexing}, una nuova modalità di operazioni che consente di tenere sotto
75 controllo più file descriptor in contemporanea, permettendo di bloccare un
76 processo quando le operazioni volute non sono possibili, e di riprenderne
77 l'esecuzione una volta che almeno una di quelle richieste sia effettuabile, in
78 modo da poterla eseguire con la sicurezza di non restare bloccati.
80 Dato che, come abbiamo già accennato, per i normali file su disco non si ha
81 mai un accesso bloccante, l'uso più comune delle funzioni che esamineremo nei
82 prossimi paragrafi è per i server di rete, in cui esse vengono utilizzate per
83 tenere sotto controllo dei socket; pertanto ritorneremo su di esse con
84 ulteriori dettagli e qualche esempio di utilizzo concreto in
85 sez.~\ref{sec:TCP_sock_multiplexing}.
88 \subsection{Le funzioni \func{select} e \func{pselect}}
89 \label{sec:file_select}
91 Il primo kernel unix-like ad introdurre una interfaccia per l'\textit{I/O
92 multiplexing} è stato BSD,\footnote{la funzione \func{select} è apparsa in
93 BSD4.2 e standardizzata in BSD4.4, ma è stata portata su tutti i sistemi che
94 supportano i socket, compreso le varianti di System V.} con la funzione
95 \funcd{select}, il cui prototipo è:
98 \headdecl{sys/types.h}
100 \funcdecl{int select(int ndfs, fd\_set *readfds, fd\_set *writefds, fd\_set
101 *exceptfds, struct timeval *timeout)}
103 Attende che uno dei file descriptor degli insiemi specificati diventi
106 \bodydesc{La funzione in caso di successo restituisce il numero di file
107 descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
108 caso \var{errno} assumerà uno dei valori:
110 \item[\errcode{EBADF}] Si è specificato un file descriptor sbagliato in uno
112 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
113 \item[\errcode{EINVAL}] Si è specificato per \param{ndfs} un valore negativo
114 o un valore non valido per \param{timeout}.
116 ed inoltre \errval{ENOMEM}.
120 La funzione mette il processo in stato di \textit{sleep} (vedi
121 tab.~\ref{tab:proc_proc_states}) fintanto che almeno uno dei file descriptor
122 degli insiemi specificati (\param{readfds}, \param{writefds} e
123 \param{exceptfds}), non diventa attivo, per un tempo massimo specificato da
126 \itindbeg{file~descriptor~set}
128 Per specificare quali file descriptor si intende \textsl{selezionare}, la
129 funzione usa un particolare oggetto, il \textit{file descriptor set},
130 identificato dal tipo \type{fd\_set}, che serve ad identificare un insieme di
131 file descriptor, in maniera analoga a come un \itindex{signal~set}
132 \textit{signal set} (vedi sez.~\ref{sec:sig_sigset}) identifica un insieme di
133 segnali. Per la manipolazione di questi \textit{file descriptor set} si
134 possono usare delle opportune macro di preprocessore:
136 \headdecl{sys/time.h}
137 \headdecl{sys/types.h}
139 \funcdecl{void \macro{FD\_ZERO}(fd\_set *set)}
140 Inizializza l'insieme (vuoto).
142 \funcdecl{void \macro{FD\_SET}(int fd, fd\_set *set)}
143 Inserisce il file descriptor \param{fd} nell'insieme.
145 \funcdecl{void \macro{FD\_CLR}(int fd, fd\_set *set)}
146 Rimuove il file descriptor \param{fd} dall'insieme.
148 \funcdecl{int \macro{FD\_ISSET}(int fd, fd\_set *set)}
149 Controlla se il file descriptor \param{fd} è nell'insieme.
152 In genere un \textit{file descriptor set} può contenere fino ad un massimo di
153 \const{FD\_SETSIZE} file descriptor. Questo valore in origine corrispondeva
154 al limite per il numero massimo di file aperti\footnote{ad esempio in Linux,
155 fino alla serie 2.0.x, c'era un limite di 256 file per processo.}, ma da
156 quando, come nelle versioni più recenti del kernel, non c'è più un limite
157 massimo, esso indica le dimensioni massime dei numeri usati nei \textit{file
158 descriptor set}.\footnote{il suo valore, secondo lo standard POSIX
159 1003.1-2001, è definito in \file{sys/select.h}, ed è pari a 1024.} Si tenga
160 presente che i \textit{file descriptor set} devono sempre essere inizializzati
161 con \macro{FD\_ZERO}; passare a \func{select} un valore non inizializzato può
162 dar luogo a comportamenti non prevedibili; allo stesso modo usare
163 \macro{FD\_SET} o \macro{FD\_CLR} con un file descriptor il cui valore eccede
164 \const{FD\_SETSIZE} può dare luogo ad un comportamento indefinito.
166 La funzione richiede di specificare tre insiemi distinti di file descriptor;
167 il primo, \param{readfds}, verrà osservato per rilevare la disponibilità di
168 effettuare una lettura,\footnote{per essere precisi la funzione ritornerà in
169 tutti i casi in cui la successiva esecuzione di \func{read} risulti non
170 bloccante, quindi anche in caso di \textit{end-of-file}; inoltre con Linux
171 possono verificarsi casi particolari, ad esempio quando arrivano dati su un
172 socket dalla rete che poi risultano corrotti e vengono scartati, può
173 accadere che \func{select} riporti il relativo file descriptor come
174 leggibile, ma una successiva \func{read} si blocchi.} il secondo,
175 \param{writefds}, per verificare la possibilità effettuare una scrittura ed il
176 terzo, \param{exceptfds}, per verificare l'esistenza di eccezioni (come i dati
177 urgenti \itindex{out-of-band} su un socket, vedi
178 sez.~\ref{sec:TCP_urgent_data}).
180 Dato che in genere non si tengono mai sotto controllo fino a
181 \const{FD\_SETSIZE} file contemporaneamente la funzione richiede di
182 specificare qual è il valore più alto fra i file descriptor indicati nei tre
183 insiemi precedenti. Questo viene fatto per efficienza, per evitare di passare
184 e far controllare al kernel una quantità di memoria superiore a quella
185 necessaria. Questo limite viene indicato tramite l'argomento \param{ndfs}, che
186 deve corrispondere al valore massimo aumentato di uno.\footnote{si ricordi che
187 i file descriptor sono numerati progressivamente a partire da zero, ed il
188 valore indica il numero più alto fra quelli da tenere sotto controllo;
189 dimenticarsi di aumentare di uno il valore di \param{ndfs} è un errore
190 comune.} Infine l'argomento \param{timeout} specifica un tempo massimo di
191 attesa prima che la funzione ritorni; se impostato a \val{NULL} la funzione
192 attende indefinitamente. Si può specificare anche un tempo nullo (cioè una
193 struttura \struct{timeval} con i campi impostati a zero), qualora si voglia
194 semplicemente controllare lo stato corrente dei file descriptor.
196 La funzione restituisce il numero di file descriptor pronti,\footnote{questo è
197 il comportamento previsto dallo standard, ma la standardizzazione della
198 funzione è recente, ed esistono ancora alcune versioni di Unix che non si
199 comportano in questo modo.} e ciascun insieme viene sovrascritto per
200 indicare quali sono i file descriptor pronti per le operazioni ad esso
201 relative, in modo da poterli controllare con \macro{FD\_ISSET}. Se invece si
202 ha un timeout viene restituito un valore nullo e gli insiemi non vengono
203 modificati. In caso di errore la funzione restituisce -1, ed i valori dei tre
204 insiemi sono indefiniti e non si può fare nessun affidamento sul loro
207 \itindend{file~descriptor~set}
209 Una volta ritornata la funzione si potrà controllare quali sono i file
210 descriptor pronti ed operare su di essi, si tenga presente però che si tratta
211 solo di un suggerimento, esistono infatti condizioni\footnote{ad esempio
212 quando su un socket arrivano dei dati che poi vengono scartati perché
213 corrotti.} in cui \func{select} può riportare in maniera spuria che un file
214 descriptor è pronto in lettura, quando una successiva lettura si bloccherebbe.
215 Per questo quando si usa \textit{I/O multiplexing} è sempre raccomandato l'uso
216 delle funzioni di lettura e scrittura in modalità non bloccante.
218 In Linux \func{select} modifica anche il valore di \param{timeout},
219 impostandolo al tempo restante in caso di interruzione prematura; questo è
220 utile quando la funzione viene interrotta da un segnale, in tal caso infatti
221 si ha un errore di \errcode{EINTR}, ed occorre rilanciare la funzione; in
222 questo modo non è necessario ricalcolare tutte le volte il tempo
223 rimanente.\footnote{questo può causare problemi di portabilità sia quando si
224 trasporta codice scritto su Linux che legge questo valore, sia quando si
225 usano programmi scritti per altri sistemi che non dispongono di questa
226 caratteristica e ricalcolano \param{timeout} tutte le volte. In genere la
227 caratteristica è disponibile nei sistemi che derivano da System V e non
228 disponibile per quelli che derivano da BSD.}
230 Uno dei problemi che si presentano con l'uso di \func{select} è che il suo
231 comportamento dipende dal valore del file descriptor che si vuole tenere sotto
232 controllo. Infatti il kernel riceve con \param{ndfs} un limite massimo per
233 tale valore, e per capire quali sono i file descriptor da tenere sotto
234 controllo dovrà effettuare una scansione su tutto l'intervallo, che può anche
235 essere molto ampio anche se i file descriptor sono solo poche unità; tutto ciò
236 ha ovviamente delle conseguenze ampiamente negative per le prestazioni.
238 Inoltre c'è anche il problema che il numero massimo dei file che si possono
239 tenere sotto controllo, la funzione è nata quando il kernel consentiva un
240 numero massimo di 1024 file descriptor per processo, adesso che il numero può
241 essere arbitrario si viene a creare una dipendenza del tutto artificiale dalle
242 dimensioni della struttura \type{fd\_set}, che può necessitare di essere
243 estesa, con ulteriori perdite di prestazioni.
245 Lo standard POSIX è rimasto a lungo senza primitive per l'\textit{I/O
246 multiplexing}, introdotto solo con le ultime revisioni dello standard (POSIX
247 1003.1g-2000 e POSIX 1003.1-2001). La scelta è stata quella di seguire
248 l'interfaccia creata da BSD, ma prevede che tutte le funzioni ad esso relative
249 vengano dichiarate nell'header \file{sys/select.h}, che sostituisce i
250 precedenti, ed inoltre aggiunge a \func{select} una nuova funzione
251 \funcd{pselect},\footnote{il supporto per lo standard POSIX 1003.1-2001, ed
252 l'header \file{sys/select.h}, compaiono in Linux a partire dalle \acr{glibc}
253 2.1. Le \acr{libc4} e \acr{libc5} non contengono questo header, le
254 \acr{glibc} 2.0 contengono una definizione sbagliata di \func{psignal},
255 senza l'argomento \param{sigmask}, la definizione corretta è presente dalle
256 \acr{glibc} 2.1-2.2.1 se si è definito \macro{\_GNU\_SOURCE} e nelle
257 \acr{glibc} 2.2.2-2.2.4 se si è definito \macro{\_XOPEN\_SOURCE} con valore
258 maggiore di 600.} il cui prototipo è:
259 \begin{prototype}{sys/select.h}
260 {int pselect(int n, fd\_set *readfds, fd\_set *writefds, fd\_set *exceptfds,
261 struct timespec *timeout, sigset\_t *sigmask)}
263 Attende che uno dei file descriptor degli insiemi specificati diventi
266 \bodydesc{La funzione in caso di successo restituisce il numero di file
267 descriptor (anche nullo) che sono attivi, e -1 in caso di errore, nel qual
268 caso \var{errno} assumerà uno dei valori:
270 \item[\errcode{EBADF}] Si è specificato un file descriptor sbagliato in uno
272 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
273 \item[\errcode{EINVAL}] Si è specificato per \param{ndfs} un valore negativo
274 o un valore non valido per \param{timeout}.
276 ed inoltre \errval{ENOMEM}.}
279 La funzione è sostanzialmente identica a \func{select}, solo che usa una
280 struttura \struct{timespec} (vedi fig.~\ref{fig:sys_timeval_struct}) per
281 indicare con maggiore precisione il timeout e non ne aggiorna il valore in
282 caso di interruzione.\footnote{in realtà la system call di Linux aggiorna il
283 valore al tempo rimanente, ma la funzione fornita dalle \acr{glibc} modifica
284 questo comportamento passando alla system call una variabile locale, in modo
285 da mantenere l'aderenza allo standard POSIX che richiede che il valore di
286 \param{timeout} non sia modificato.} Inoltre prende un argomento aggiuntivo
287 \param{sigmask} che è il puntatore ad una maschera di segnali (si veda
288 sez.~\ref{sec:sig_sigmask}). La maschera corrente viene sostituita da questa
289 immediatamente prima di eseguire l'attesa, e ripristinata al ritorno della
292 L'uso di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
293 \textit{race condition} \itindex{race~condition} quando ci si deve porre in
294 attesa sia di un segnale che di dati. La tecnica classica è quella di
295 utilizzare il gestore per impostare una variabile globale e controllare questa
296 nel corpo principale del programma; abbiamo visto in
297 sez.~\ref{sec:sig_example} come questo lasci spazio a possibili race
298 condition, per cui diventa essenziale utilizzare \func{sigprocmask} per
299 disabilitare la ricezione del segnale prima di eseguire il controllo e
300 riabilitarlo dopo l'esecuzione delle relative operazioni, onde evitare
301 l'arrivo di un segnale immediatamente dopo il controllo, che andrebbe perso.
303 Nel nostro caso il problema si pone quando oltre al segnale si devono tenere
304 sotto controllo anche dei file descriptor con \func{select}, in questo caso si
305 può fare conto sul fatto che all'arrivo di un segnale essa verrebbe interrotta
306 e si potrebbero eseguire di conseguenza le operazioni relative al segnale e
307 alla gestione dati con un ciclo del tipo:
308 \includecodesnip{listati/select_race.c}
309 qui però emerge una \itindex{race~condition} \textit{race condition}, perché
310 se il segnale arriva prima della chiamata a \func{select}, questa non verrà
311 interrotta, e la ricezione del segnale non sarà rilevata.
313 Per questo è stata introdotta \func{pselect} che attraverso l'argomento
314 \param{sigmask} permette di riabilitare la ricezione il segnale
315 contestualmente all'esecuzione della funzione,\footnote{in Linux però, fino al
316 kernel 2.6.16, non era presente la relativa system call, e la funzione era
317 implementata nelle \acr{glibc} attraverso \func{select} (vedi \texttt{man
318 select\_tut}) per cui la possibilità di \itindex{race~condition}
319 \textit{race condition} permaneva; in tale situazione si può ricorrere ad una
320 soluzione alternativa, chiamata \itindex{self-pipe trick} \textit{self-pipe
321 trick}, che consiste nell'aprire una pipe (vedi sez.~\ref{sec:ipc_pipes})
322 ed usare \func{select} sul capo in lettura della stessa; si può indicare
323 l'arrivo di un segnale scrivendo sul capo in scrittura all'interno del
324 gestore dello stesso; in questo modo anche se il segnale va perso prima
325 della chiamata di \func{select} questa lo riconoscerà comunque dalla
326 presenza di dati sulla pipe.} ribloccandolo non appena essa ritorna, così
327 che il precedente codice potrebbe essere riscritto nel seguente modo:
328 \includecodesnip{listati/pselect_norace.c}
329 in questo caso utilizzando \var{oldmask} durante l'esecuzione di
330 \func{pselect} la ricezione del segnale sarà abilitata, ed in caso di
331 interruzione si potranno eseguire le relative operazioni.
334 \subsection{Le funzioni \func{poll} e \func{ppoll}}
335 \label{sec:file_poll}
337 Nello sviluppo di System V, invece di utilizzare l'interfaccia di
338 \func{select}, che è una estensione tipica di BSD, è stata introdotta un'altra
339 interfaccia, basata sulla funzione \funcd{poll},\footnote{la funzione è
340 prevista dallo standard XPG4, ed è stata introdotta in Linux come system
341 call a partire dal kernel 2.1.23 ed inserita nelle \acr{libc} 5.4.28.} il
343 \begin{prototype}{sys/poll.h}
344 {int poll(struct pollfd *ufds, unsigned int nfds, int timeout)}
346 La funzione attende un cambiamento di stato su un insieme di file
349 \bodydesc{La funzione restituisce il numero di file descriptor con attività
350 in caso di successo, o 0 se c'è stato un timeout e -1 in caso di errore,
351 ed in quest'ultimo caso \var{errno} assumerà uno dei valori:
353 \item[\errcode{EBADF}] Si è specificato un file descriptor sbagliato in uno
355 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
356 \item[\errcode{EINVAL}] Il valore di \param{nfds} eccede il limite
357 \macro{RLIMIT\_NOFILE}.
359 ed inoltre \errval{EFAULT} e \errval{ENOMEM}.}
362 La funzione permette di tenere sotto controllo contemporaneamente \param{ndfs}
363 file descriptor, specificati attraverso il puntatore \param{ufds} ad un
364 vettore di strutture \struct{pollfd}. Come con \func{select} si può
365 interrompere l'attesa dopo un certo tempo, questo deve essere specificato con
366 l'argomento \param{timeout} in numero di millisecondi: un valore negativo
367 indica un'attesa indefinita, mentre un valore nullo comporta il ritorno
368 immediato (e può essere utilizzato per impiegare \func{poll} in modalità
369 \textsl{non-bloccante}).
371 Per ciascun file da controllare deve essere inizializzata una struttura
372 \struct{pollfd} nel vettore indicato dall'argomento \param{ufds}. La
373 struttura, la cui definizione è riportata in fig.~\ref{fig:file_pollfd},
374 prevede tre campi: in \var{fd} deve essere indicato il numero del file
375 descriptor da controllare, in \var{events} deve essere specificata una
376 maschera binaria di flag che indichino il tipo di evento che si vuole
377 controllare, mentre in \var{revents} il kernel restituirà il relativo
378 risultato. Usando un valore negativo per \param{fd} la corrispondente
379 struttura sarà ignorata da \func{poll}. Dato che i dati in ingresso sono del
380 tutto indipendenti da quelli in uscita (che vengono restituiti in
381 \var{revents}) non è necessario reinizializzare tutte le volte il valore delle
382 strutture \struct{pollfd} a meno di non voler cambiare qualche condizione.
385 \footnotesize \centering
386 \begin{minipage}[c]{15cm}
387 \includestruct{listati/pollfd.h}
390 \caption{La struttura \structd{pollfd}, utilizzata per specificare le
391 modalità di controllo di un file descriptor alla funzione \func{poll}.}
392 \label{fig:file_pollfd}
395 Le costanti che definiscono i valori relativi ai bit usati nelle maschere
396 binarie dei campi \var{events} e \var{revents} sono riportati in
397 tab.~\ref{tab:file_pollfd_flags}, insieme al loro significato. Le si sono
398 suddivise in tre gruppi, nel primo gruppo si sono indicati i bit utilizzati
399 per controllare l'attività in ingresso, nel secondo quelli per l'attività in
400 uscita, mentre il terzo gruppo contiene dei valori che vengono utilizzati solo
401 nel campo \var{revents} per notificare delle condizioni di errore.
406 \begin{tabular}[c]{|l|l|}
408 \textbf{Flag} & \textbf{Significato} \\
411 \const{POLLIN} & È possibile la lettura.\\
412 \const{POLLRDNORM}& Sono disponibili in lettura dati normali.\\
413 \const{POLLRDBAND}& Sono disponibili in lettura dati prioritari. \\
414 \const{POLLPRI} & È possibile la lettura di \itindex{out-of-band} dati
417 \const{POLLOUT} & È possibile la scrittura immediata.\\
418 \const{POLLWRNORM}& È possibile la scrittura di dati normali. \\
419 \const{POLLWRBAND}& È possibile la scrittura di dati prioritari. \\
421 \const{POLLERR} & C'è una condizione di errore.\\
422 \const{POLLHUP} & Si è verificato un hung-up.\\
423 \const{POLLNVAL} & Il file descriptor non è aperto.\\
425 \const{POLLMSG} & Definito per compatibilità con SysV.\\
428 \caption{Costanti per l'identificazione dei vari bit dei campi
429 \var{events} e \var{revents} di \struct{pollfd}.}
430 \label{tab:file_pollfd_flags}
433 Il valore \const{POLLMSG} non viene utilizzato ed è definito solo per
434 compatibilità con l'implementazione di SysV che usa gli
435 \textit{stream};\footnote{essi sono una interfaccia specifica di SysV non
436 presente in Linux, e non hanno nulla a che fare con i file \textit{stream}
437 delle librerie standard del C.} è da questi che derivano i nomi di alcune
438 costanti, in quanto per essi sono definite tre classi di dati:
439 \textsl{normali}, \textit{prioritari} ed \textit{urgenti}. In Linux la
440 distinzione ha senso solo per i dati urgenti \itindex{out-of-band} dei socket
441 (vedi sez.~\ref{sec:TCP_urgent_data}), ma su questo e su come \func{poll}
442 reagisce alle varie condizioni dei socket torneremo in
443 sez.~\ref{sec:TCP_serv_poll}, dove vedremo anche un esempio del suo utilizzo.
444 Si tenga conto comunque che le costanti relative ai diversi tipi di dati (come
445 \const{POLLRDNORM} e \const{POLLRDBAND}) sono utilizzabili soltanto qualora si
446 sia definita la macro \macro{\_XOPEN\_SOURCE}.\footnote{e ci si ricordi di
447 farlo sempre in testa al file, definirla soltanto prima di includere
448 \file{sys/poll.h} non è sufficiente.}
450 In caso di successo funzione ritorna restituendo il numero di file (un valore
451 positivo) per i quali si è verificata una delle condizioni di attesa richieste
452 o per i quali si è verificato un errore (nel qual caso vengono utilizzati i
453 valori di tab.~\ref{tab:file_pollfd_flags} esclusivi di \var{revents}). Un
454 valore nullo indica che si è raggiunto il timeout, mentre un valore negativo
455 indica un errore nella chiamata, il cui codice viene riportato al solito
458 L'uso di \func{poll} consente di superare alcuni dei problemi illustrati in
459 precedenza per \func{select}; anzitutto, dato che in questo caso si usa un
460 vettore di strutture \struct{pollfd} di dimensione arbitraria, non esiste il
461 limite introdotto dalle dimensioni massime di un \itindex{file~descriptor~set}
462 \textit{file descriptor set} e la dimensione dei dati passati al kernel
463 dipende solo dal numero dei file descriptor che si vogliono controllare, non
464 dal loro valore.\footnote{anche se usando dei bit un \textit{file descriptor
465 set} può essere più efficiente di un vettore di strutture \struct{pollfd},
466 qualora si debba osservare un solo file descriptor con un valore molto alto
467 ci si troverà ad utilizzare inutilmente un maggiore quantitativo di
470 Inoltre con \func{select} lo stesso \itindex{file~descriptor~set} \textit{file
471 descriptor set} è usato sia in ingresso che in uscita, e questo significa
472 che tutte le volte che si vuole ripetere l'operazione occorre reinizializzarlo
473 da capo. Questa operazione, che può essere molto onerosa se i file descriptor
474 da tenere sotto osservazione sono molti, non è invece necessaria con
477 Abbiamo visto in sez.~\ref{sec:file_select} come lo standard POSIX preveda una
478 variante di \func{select} che consente di gestire correttamente la ricezione
479 dei segnali nell'attesa su un file descriptor. Con l'introduzione di una
480 implementazione reale di \func{pselect} nel kernel 2.6.16, è stata aggiunta
481 anche una analoga funzione che svolga lo stesso ruolo per \func{poll}.
483 In questo caso si tratta di una estensione che è specifica di Linux e non è
484 prevista da nessuno standard; essa può essere utilizzata esclusivamente se si
485 definisce la macro \macro{\_GNU\_SOURCE} ed ovviamente non deve essere usata
486 se si ha a cuore la portabilità. La funzione è \funcd{ppoll}, ed il suo
488 \begin{prototype}{sys/poll.h}
489 {int ppoll(struct pollfd *fds, nfds\_t nfds, const struct timespec *timeout,
490 const sigset\_t *sigmask)}
492 La funzione attende un cambiamento di stato su un insieme di file
495 \bodydesc{La funzione restituisce il numero di file descriptor con attività
496 in caso di successo, o 0 se c'è stato un timeout e -1 in caso di errore,
497 ed in quest'ultimo caso \var{errno} assumerà uno dei valori:
499 \item[\errcode{EBADF}] Si è specificato un file descriptor sbagliato in uno
501 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
502 \item[\errcode{EINVAL}] Il valore di \param{nfds} eccede il limite
503 \macro{RLIMIT\_NOFILE}.
505 ed inoltre \errval{EFAULT} e \errval{ENOMEM}.}
508 La funzione ha lo stesso comportamento di \func{poll}, solo che si può
509 specificare, con l'argomento \param{sigmask}, il puntatore ad una maschera di
510 segnali; questa sarà la maschera utilizzata per tutto il tempo che la funzione
511 resterà in attesa, all'uscita viene ripristinata la maschera originale. L'uso
512 di questa funzione è cioè equivalente, come illustrato nella pagina di
513 manuale, all'esecuzione atomica del seguente codice:
514 \includecodesnip{listati/ppoll_means.c}
516 Eccetto per \param{timeout}, che come per \func{pselect} deve essere un
517 puntatore ad una struttura \struct{timespec}, gli altri argomenti comuni con
518 \func{poll} hanno lo stesso significato, e la funzione restituisce gli stessi
519 risultati illustrati in precedenza.
522 \subsection{L'interfaccia di \textit{epoll}}
523 \label{sec:file_epoll}
527 Nonostante \func{poll} presenti alcuni vantaggi rispetto a \func{select},
528 anche questa funzione non è molto efficiente quando deve essere utilizzata con
529 un gran numero di file descriptor,\footnote{in casi del genere \func{select}
530 viene scartata a priori, perché può avvenire che il numero di file
531 descriptor ecceda le dimensioni massime di un \itindex{file~descriptor~set}
532 \textit{file descriptor set}.} in particolare nel caso in cui solo pochi di
533 questi diventano attivi. Il problema in questo caso è che il tempo impiegato
534 da \func{poll} a trasferire i dati da e verso il kernel è proporzionale al
535 numero di file descriptor osservati, non a quelli che presentano attività.
537 Quando ci sono decine di migliaia di file descriptor osservati e migliaia di
538 eventi al secondo,\footnote{il caso classico è quello di un server web di un
539 sito con molti accessi.} l'uso di \func{poll} comporta la necessità di
540 trasferire avanti ed indietro da user space a kernel space la lunga lista
541 delle strutture \struct{pollfd} migliaia di volte al secondo. A questo poi si
542 aggiunge il fatto che la maggior parte del tempo di esecuzione sarà impegnato
543 ad eseguire una scansione su tutti i file descriptor tenuti sotto controllo
544 per determinare quali di essi (in genere una piccola percentuale) sono
545 diventati attivi. In una situazione come questa l'uso delle funzioni classiche
546 dell'interfaccia dell'\textit{I/O multiplexing} viene a costituire un collo di
547 bottiglia che degrada irrimediabilmente le prestazioni.
549 Per risolvere questo tipo di situazioni sono state ideate delle interfacce
550 specialistiche\footnote{come \texttt{/dev/poll} in Solaris, o \texttt{kqueue}
551 in BSD.} il cui scopo fondamentale è quello di restituire solamente le
552 informazioni relative ai file descriptor osservati che presentano una
553 attività, evitando così le problematiche appena illustrate. In genere queste
554 prevedono che si registrino una sola volta i file descriptor da tenere sotto
555 osservazione, e forniscono un meccanismo che notifica quali di questi
558 Le modalità con cui avviene la notifica sono due, la prima è quella classica
559 (quella usata da \func{poll} e \func{select}) che viene chiamata \textit{level
560 triggered}.\footnote{la nomenclatura è stata introdotta da Jonathan Lemon in
561 un articolo su \texttt{kqueue} al BSDCON 2000, e deriva da quella usata
562 nell'elettronica digitale.} In questa modalità vengono notificati i file
563 descriptor che sono \textsl{pronti} per l'operazione richiesta, e questo
564 avviene indipendentemente dalle operazioni che possono essere state fatte su
565 di essi a partire dalla precedente notifica. Per chiarire meglio il concetto
566 ricorriamo ad un esempio: se su un file descriptor sono diventati disponibili
567 in lettura 2000 byte ma dopo la notifica ne sono letti solo 1000 (ed è quindi
568 possibile eseguire una ulteriore lettura dei restanti 1000), in modalità
569 \textit{level triggered} questo sarà nuovamente notificato come
572 La seconda modalità, è detta \textit{edge triggered}, e prevede che invece
573 vengano notificati solo i file descriptor che hanno subito una transizione da
574 \textsl{non pronti} a \textsl{pronti}. Questo significa che in modalità
575 \textit{edge triggered} nel caso del precedente esempio il file descriptor
576 diventato pronto da cui si sono letti solo 1000 byte non verrà nuovamente
577 notificato come pronto, nonostante siano ancora disponibili in lettura 1000
578 byte. Solo una volta che si saranno esauriti tutti i byte disponibili, e che
579 il file descriptor sia tornato non essere pronto, si potrà ricevere una
580 ulteriore notifica qualora ritornasse pronto.
582 Nel caso di Linux al momento la sola interfaccia che fornisce questo tipo di
583 servizio è \textit{epoll},\footnote{l'interfaccia è stata creata da Davide
584 Libenzi, ed è stata introdotta per la prima volta nel kernel 2.5.44, ma la
585 sua forma definitiva è stata raggiunta nel kernel 2.5.66.} anche se sono in
586 discussione altre interfacce con le quali si potranno effettuare lo stesso
587 tipo di operazioni;\footnote{al momento della stesura di queste note (Giugno
588 2007) un'altra interfaccia proposta è quella di \textit{kevent}, che
589 fornisce un sistema di notifica di eventi generico in grado di fornire le
590 stesse funzionalità di \textit{epoll}, esiste però una forte discussione
591 intorno a tutto ciò e niente di definito.} \textit{epoll} è in grado di
592 operare sia in modalità \textit{level triggered} che \textit{edge triggered}.
594 La prima versione \textit{epoll} prevedeva l'apertura di uno speciale file di
595 dispositivo, \texttt{/dev/epoll}, per ottenere un file descriptor da
596 utilizzare con le funzioni dell'interfaccia,\footnote{il backporting
597 dell'interfaccia per il kernel 2.4, non ufficiale, utilizza sempre questo
598 file.} ma poi si è passati all'uso una apposita \textit{system call}. Il
599 primo passo per usare l'interfaccia di \textit{epoll} è pertanto quello di
600 chiamare la funzione \funcd{epoll\_create}, il cui prototipo è:
601 \begin{prototype}{sys/epoll.h}
602 {int epoll\_create(int size)}
604 Apre un file descriptor per \textit{epoll}.
606 \bodydesc{La funzione restituisce un file descriptor in caso di successo, o
607 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
609 \item[\errcode{EINVAL}] si è specificato un valore di \param{size} non
611 \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
613 \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
619 La funzione restituisce un file descriptor speciale, detto anche \textit{epoll
620 descriptor} che viene associato alla infrastruttura utilizzata dal kernel
621 per gestire la notifica degli eventi; l'argomento \param{size} serve a dare
622 l'indicazione del numero di file descriptor che si vorranno tenere sotto
623 controllo, ma costituisce solo un suggerimento per semplificare l'allocazione
624 di risorse sufficienti, non un valore massimo.
626 Una volta ottenuto un file descriptor per \textit{epoll} il passo successivo è
627 indicare quali file descriptor mettere sotto osservazione e quali operazioni
628 controllare, per questo si deve usare la seconda funzione dell'interfaccia,
629 \funcd{epoll\_ctl}, il cui prototipo è:
630 \begin{prototype}{sys/epoll.h}
631 {int epoll\_ctl(int epfd, int op, int fd, struct epoll\_event *event)}
633 Esegue le operazioni di controllo di \textit{epoll}.
635 \bodydesc{La funzione restituisce $0$ in caso di successo o $-1$ in caso di
636 errore, nel qual caso \var{errno} assumerà uno dei valori:
638 \item[\errcode{EBADF}] il file descriptor \param{epfd} o \param{fd} non sono
640 \item[\errcode{EEXIST}] l'operazione richiesta è \const{EPOLL\_CTL\_ADD} ma
641 \param{fd} è già stato inserito in \param{epfd}.
642 \item[\errcode{EINVAL}] il file descriptor \param{epfd} non è stato ottenuto
643 con \func{epoll\_create}, o \param{fd} è lo stesso \param{epfd} o
644 l'operazione richiesta con \param{op} non è supportata.
645 \item[\errcode{ENOENT}] l'operazione richiesta è \const{EPOLL\_CTL\_MOD} o
646 \const{EPOLL\_CTL\_DEL} ma \param{fd} non è inserito in \param{epfd}.
647 \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel gestire
648 l'operazione richiesta.
649 \item[\errcode{EPERM}] il file \param{fd} non supporta \textit{epoll}.
654 Il comportamento della funzione viene controllato dal valore dall'argomento
655 \param{op} che consente di specificare quale operazione deve essere eseguita.
656 Le costanti che definiscono i valori utilizzabili per l'argomento \param{op}
657 sono riportate in tab.~\ref{tab:epoll_ctl_operation}, assieme al significato
658 delle operazioni cui fanno riferimento.
663 \begin{tabular}[c]{|l|l|}
665 \textbf{Valore} & \textbf{Significato} \\
668 \const{EPOLL\_CTL\_ADD}& aggiunge un nuovo file descriptor da osservare
669 \param{fd} alla lista dei file descriptor
670 controllati tramite \param{epfd}.\\
671 \const{EPOLL\_CTL\_MOD}& .\\
672 \const{EPOLL\_CTL\_DEL}& .\\
675 \caption{Valori dell'argomento \param{op} che consentono di scegliere quale
676 operazione di controllo effettuare con la funzione \func{epoll\_ctl}.}
677 \label{tab:epoll_ctl_operation}
683 \footnotesize \centering
684 \begin{minipage}[c]{15cm}
685 \includestruct{listati/epoll_event.h}
688 \caption{La struttura \structd{epoll\_event}, .}
698 \begin{tabular}[c]{|l|l|}
700 \textbf{Valore} & \textbf{Significato} \\
704 \const{EPOLLOUT}& .\\
705 \const{EPOLLRDHUP}& .\\
706 \const{EPOLLPRI}& .\\
707 \const{EPOLLERR}& .\\
708 \const{EPOLLHUP}& .\\
710 \const{EPOLLONESHOT}& .\\
713 \caption{Valori del campo \param{events} di \struct{epoll\_event}.}
714 \label{tab:epoll_events}
719 specificare con le costanti riportate in tab.,
720 La funzione prende come primo argomento un file descriptor di \textit{epoll}
721 \param{epfd}, che deve essere stato ottenuto tramite \func{epoll\_create}, e
722 consente di impostare le operazioni di osservazione su un altro file
723 descriptor \param{fd}
728 La funzione esegue l'operazione di controllo specificata dall'argomento
732 \param{fd} alla lista dei file descriptor osservati
734 sull'\textit{epoll descripter} \param{epfd}
737 La funzione che consente di attendere è \funcd{epoll\_wait}, il cui prototipo
739 \begin{prototype}{sys/epoll.h}
740 {int epoll\_wait(int epfd, struct epoll\_event * events, int maxevents, int
743 Attende che uno dei file descriptor osservati sia pronto.
745 \bodydesc{La funzione restituisce il numero di file descriptor pronti in
746 caso di successo o $-1$ in caso di errore, nel qual caso \var{errno}
747 assumerà uno dei valori:
749 \item[\errcode{EBADF}] il file descriptor \param{epfd} non è valido.
750 \item[\errcode{EFAULT}] il puntatore \param{events} non è valido.
751 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima
752 della scadenza di \param{timeout}.
753 \item[\errcode{EINVAL}] il file descriptor \param{epfd} non è stato ottenuto
754 con \func{epoll\_create}, o \param{fd} è lo stesso \param{epfd} o
755 l'operazione richiesta con \param{op} non è supportata.
765 \section{L'accesso \textsl{asincrono} ai file}
766 \label{sec:file_asyncronous_access}
768 Benché l'\textit{I/O multiplexing} sia stata la prima, e sia tutt'ora una fra
769 le più diffuse modalità di gestire l'I/O in situazioni complesse in cui si
770 debba operare su più file contemporaneamente, esistono altre modalità di
771 gestione delle stesse problematiche. In particolare sono importanti in questo
772 contesto le modalità di accesso ai file eseguibili in maniera
773 \textsl{asincrona}, quelle cioè in cui un processo non deve bloccarsi in
774 attesa della disponibilità dell'accesso al file, ma può proseguire
775 nell'esecuzione utilizzando invece un meccanismo di notifica asincrono (di
776 norma un segnale), per essere avvisato della possibilità di eseguire le
777 operazioni di I/O volute.
780 \subsection{Operazioni asincrone sui file}
781 \label{sec:file_asyncronous_operation}
783 Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso l'uso
784 del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e dei
785 comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è specifico
786 di Linux e BSD.} aprire un file in modalità asincrona, così come è possibile
787 attivare in un secondo tempo questa modalità impostando questo flag attraverso
788 l'uso di \func{fcntl} con il comando \const{F\_SETFL} (vedi
789 sez.~\ref{sec:file_fcntl}).
791 In realtà in questo caso non si tratta di eseguire delle operazioni di lettura
792 o scrittura del file in modo asincrono (tratteremo questo, che più
793 propriamente è detto \textsl{I/O asincrono} in
794 sez.~\ref{sec:file_asyncronous_io}), quanto di un meccanismo asincrono di
795 notifica delle variazione dello stato del file descriptor aperto in questo
798 Quello che succede in questo caso è che il sistema genera un segnale
799 (normalmente \const{SIGIO}, ma è possibile usarne altri con il comando
800 \const{F\_SETSIG} di \func{fcntl}) tutte le volte che diventa possibile
801 leggere o scrivere dal file descriptor che si è posto in questa modalità. Si
802 può inoltre selezionare, con il comando \const{F\_SETOWN} di \func{fcntl},
803 quale processo (o gruppo di processi) riceverà il segnale. Se pertanto si
804 effettuano le operazioni di I/O in risposta alla ricezione del segnale non ci
805 sarà più la necessità di restare bloccati in attesa della disponibilità di
806 accesso ai file; per questo motivo Stevens chiama questa modalità
807 \textit{signal driven I/O}.
809 Questa è un'altra modalità di gestione I/O, alternativa all'uso di
810 \itindex{epoll} \textit{epoll}, che consente di evitare l'uso delle funzioni
811 \func{poll} o \func{select} che, come illustrato in sez.~\ref{sec:file_epoll},
812 quando vengono usate con un numero molto grande di file descriptor, non hanno
815 Tuttavia con l'implementazione classica dei segnali questa modalità di I/O
816 presenta notevoli problemi, dato che non è possibile determinare, quando i
817 file descriptor sono più di uno, qual è quello responsabile dell'emissione del
818 segnale. Inoltre dato che i segnali normali non si accodano (si ricordi quanto
819 illustrato in sez.~\ref{sec:sig_notification}), in presenza di più file
820 descriptor attivi contemporaneamente, più segnali emessi nello stesso momento
821 verrebbero notificati una volta sola.
823 Linux però supporta le estensioni POSIX.1b dei segnali real-time, che vengono
824 accodati e che permettono di riconoscere il file descriptor che li ha emessi.
825 In questo caso infatti si può fare ricorso alle informazioni aggiuntive
826 restituite attraverso la struttura \struct{siginfo\_t}, utilizzando la forma
827 estesa \var{sa\_sigaction} del gestore installata con il flag
828 \const{SA\_SIGINFO} (si riveda quanto illustrato in
829 sez.~\ref{sec:sig_sigaction}).
831 Per far questo però occorre utilizzare le funzionalità dei segnali real-time
832 (vedi sez.~\ref{sec:sig_real_time}) impostando esplicitamente con il comando
833 \const{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
834 I/O asincrono (il segnale predefinito è \const{SIGIO}). In questo caso il
835 gestore, tutte le volte che riceverà \const{SI\_SIGIO} come valore del
836 campo \var{si\_code}\footnote{il valore resta \const{SI\_SIGIO} qualunque sia
837 il segnale che si è associato all'I/O asincrono, ed indica appunto che il
838 segnale è stato generato a causa di attività nell'I/O asincrono.} di
839 \struct{siginfo\_t}, troverà nel campo \var{si\_fd} il valore del file
840 descriptor che ha generato il segnale.
842 Un secondo vantaggio dell'uso dei segnali real-time è che essendo questi
843 ultimi dotati di una coda di consegna ogni segnale sarà associato ad uno solo
844 file descriptor; inoltre sarà possibile stabilire delle priorità nella
845 risposta a seconda del segnale usato, dato che i segnali real-time supportano
846 anche questa funzionalità. In questo modo si può identificare immediatamente
847 un file su cui l'accesso è diventato possibile evitando completamente l'uso di
848 funzioni come \func{poll} e \func{select}, almeno fintanto che non si satura
851 Se infatti si eccedono le dimensioni di quest'ultima, il kernel, non potendo
852 più assicurare il comportamento corretto per un segnale real-time, invierà al
853 suo posto un solo \const{SIGIO}, su cui si saranno accumulati tutti i segnali
854 in eccesso, e si dovrà allora determinare con un ciclo quali sono i file
857 % TODO fare esempio che usa O_ASYNC
860 \subsection{I meccanismi di notifica asincrona.}
861 \label{sec:file_asyncronous_lease}
863 Una delle domande più frequenti nella programmazione in ambiente unix-like è
864 quella di come fare a sapere quando un file viene modificato. La
865 risposta\footnote{o meglio la non risposta, tanto che questa nelle Unix FAQ
866 \cite{UnixFAQ} viene anche chiamata una \textit{Frequently Unanswered
867 Question}.} è che nell'architettura classica di Unix questo non è
868 possibile. Al contrario di altri sistemi operativi infatti un kernel unix-like
869 non prevede alcun meccanismo per cui un processo possa essere
870 \textsl{notificato} di eventuali modifiche avvenute su un file. Questo è il
871 motivo per cui i demoni devono essere \textsl{avvisati} in qualche
872 modo\footnote{in genere questo vien fatto inviandogli un segnale di
873 \const{SIGHUP} che, per convenzione adottata dalla gran parte di detti
874 programmi, causa la rilettura della configurazione.} se il loro file di
875 configurazione è stato modificato, perché possano rileggerlo e riconoscere le
878 Questa scelta è stata fatta perché provvedere un simile meccanismo a livello
879 generale comporterebbe un notevole aumento di complessità dell'architettura
880 della gestione dei file, per fornire una funzionalità necessaria soltanto in
881 casi particolari. Dato che all'origine di Unix i soli programmi che potevano
882 avere una tale esigenza erano i demoni, attenendosi a uno dei criteri base
883 della progettazione, che era di far fare al kernel solo le operazioni
884 strettamente necessarie e lasciare tutto il resto a processi in user space,
885 non era stata prevista nessuna funzionalità di notifica.
887 Visto però il crescente interesse nei confronti di una funzionalità di questo
888 tipo (molto richiesta specialmente nello sviluppo dei programmi ad interfaccia
889 grafica) sono state successivamente introdotte delle estensioni che
890 permettessero la creazione di meccanismi di notifica più efficienti dell'unica
891 soluzione disponibile con l'interfaccia tradizionale, che è quella del
892 \itindex{polling} \textit{polling}.
894 Queste nuove funzionalità sono delle estensioni specifiche, non
895 standardizzate, che sono disponibili soltanto su Linux (anche se altri kernel
896 supportano meccanismi simili). Alcune di esse sono realizzate, e solo a
897 partire dalla versione 2.4 del kernel, attraverso l'uso di alcuni
898 \textsl{comandi} aggiuntivi per la funzione \func{fcntl} (vedi
899 sez.~\ref{sec:file_fcntl}), che divengono disponibili soltanto se si è
900 definita la macro \macro{\_GNU\_SOURCE} prima di includere \file{fcntl.h}.
904 La prima di queste funzionalità è quella del cosiddetto \textit{file lease};
905 questo è un meccanismo che consente ad un processo, detto \textit{lease
906 holder}, di essere notificato quando un altro processo, chiamato a sua volta
907 \textit{lease breaker}, cerca di eseguire una \func{open} o una
908 \func{truncate} sul file del quale l'\textit{holder} detiene il
911 La notifica avviene in maniera analoga a come illustrato in precedenza per
912 l'uso di \const{O\_ASYNC}: di default viene inviato al \textit{lease holder}
913 il segnale \const{SIGIO}, ma questo segnale può essere modificato usando il
914 comando \const{F\_SETSIG} di \func{fcntl}.\footnote{anche in questo caso si
915 può rispecificare lo stesso \const{SIGIO}.} Se si è fatto questo\footnote{è
916 in genere è opportuno farlo, come in precedenza, per utilizzare segnali
917 real-time.} e si è installato il gestore del segnale con \const{SA\_SIGINFO}
918 si riceverà nel campo \var{si\_fd} della struttura \struct{siginfo\_t} il
919 valore del file descriptor del file sul quale è stato compiuto l'accesso; in
920 questo modo un processo può mantenere anche più di un \textit{file lease}.
922 Esistono due tipi di \textit{file lease}: di lettura (\textit{read lease}) e
923 di scrittura (\textit{write lease}). Nel primo caso la notifica avviene quando
924 un altro processo esegue l'apertura del file in scrittura o usa
925 \func{truncate} per troncarlo. Nel secondo caso la notifica avviene anche se
926 il file viene aperto il lettura; in quest'ultimo caso però il \textit{lease}
927 può essere ottenuto solo se nessun altro processo ha aperto lo stesso file.
929 Come accennato in sez.~\ref{sec:file_fcntl} il comando di \func{fcntl} che
930 consente di acquisire un \textit{file lease} è \const{F\_SETLEASE}, che viene
931 utilizzato anche per rilasciarlo. In tal caso il file descriptor \param{fd}
932 passato a \func{fcntl} servirà come riferimento per il file su cui si vuole
933 operare, mentre per indicare il tipo di operazione (acquisizione o rilascio)
934 occorrerà specificare come valore dell'argomento \param{arg} di \func{fcntl}
935 uno dei tre valori di tab.~\ref{tab:file_lease_fctnl}.
940 \begin{tabular}[c]{|l|l|}
942 \textbf{Valore} & \textbf{Significato} \\
945 \const{F\_RDLCK} & Richiede un \textit{read lease}.\\
946 \const{F\_WRLCK} & Richiede un \textit{write lease}.\\
947 \const{F\_UNLCK} & Rilascia un \textit{file lease}.\\
950 \caption{Costanti per i tre possibili valori dell'argomento \param{arg} di
951 \func{fcntl} quando usata con i comandi \const{F\_SETLEASE} e
952 \const{F\_GETLEASE}.}
953 \label{tab:file_lease_fctnl}
956 Se invece si vuole conoscere lo stato di eventuali \textit{file lease}
957 occorrerà chiamare \func{fcntl} sul relativo file descriptor \param{fd} con il
958 comando \const{F\_GETLEASE}, e si otterrà indietro nell'argomento \param{arg}
959 uno dei valori di tab.~\ref{tab:file_lease_fctnl}, che indicheranno la
960 presenza del rispettivo tipo di \textit{lease}, o, nel caso di
961 \const{F\_UNLCK}, l'assenza di qualunque \textit{file lease}.
963 Si tenga presente che un processo può mantenere solo un tipo di \textit{lease}
964 su un file, e che un \textit{lease} può essere ottenuto solo su file di dati
965 (pipe e dispositivi sono quindi esclusi). Inoltre un processo non privilegiato
966 può ottenere un \textit{lease} soltanto per un file appartenente ad un
967 \acr{uid} corrispondente a quello del processo. Soltanto un processo con
968 privilegi di amministratore (cioè con la \itindex{capabilities} capability
969 \const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può acquisire
970 \textit{lease} su qualunque file.
972 Se su un file è presente un \textit{lease} quando il \textit{lease breaker}
973 esegue una \func{truncate} o una \func{open} che confligge con
974 esso,\footnote{in realtà \func{truncate} confligge sempre, mentre \func{open},
975 se eseguita in sola lettura, non confligge se si tratta di un \textit{read
976 lease}.} la funzione si blocca\footnote{a meno di non avere aperto il file
977 con \const{O\_NONBLOCK}, nel qual caso \func{open} fallirebbe con un errore
978 di \errcode{EWOULDBLOCK}.} e viene eseguita la notifica al \textit{lease
979 holder}, così che questo possa completare le sue operazioni sul file e
980 rilasciare il \textit{lease}. In sostanza con un \textit{read lease} si
981 rilevano i tentativi di accedere al file per modificarne i dati da parte di un
982 altro processo, mentre con un \textit{write lease} si rilevano anche i
983 tentativi di accesso in lettura. Si noti comunque che le operazioni di
984 notifica avvengono solo in fase di apertura del file e non sulle singole
985 operazioni di lettura e scrittura.
987 L'utilizzo dei \textit{file lease} consente al \textit{lease holder} di
988 assicurare la consistenza di un file, a seconda dei due casi, prima che un
989 altro processo inizi con le sue operazioni di scrittura o di lettura su di
990 esso. In genere un \textit{lease holder} che riceve una notifica deve
991 provvedere a completare le necessarie operazioni (ad esempio scaricare
992 eventuali buffer), per poi rilasciare il \textit{lease} così che il
993 \textit{lease breaker} possa eseguire le sue operazioni. Questo si fa con il
994 comando \const{F\_SETLEASE}, o rimuovendo il \textit{lease} con
995 \const{F\_UNLCK}, o, nel caso di \textit{write lease} che confligge con una
996 operazione di lettura, declassando il \textit{lease} a lettura con
999 Se il \textit{lease holder} non provvede a rilasciare il \textit{lease} entro
1000 il numero di secondi specificato dal parametro di sistema mantenuto in
1001 \file{/proc/sys/fs/lease-break-time} sarà il kernel stesso a rimuoverlo (o
1002 declassarlo) automaticamente.\footnote{questa è una misura di sicurezza per
1003 evitare che un processo blocchi indefinitamente l'accesso ad un file
1004 acquisendo un \textit{lease}.} Una volta che un \textit{lease} è stato
1005 rilasciato o declassato (che questo sia fatto dal \textit{lease holder} o dal
1006 kernel è lo stesso) le chiamate a \func{open} o \func{truncate} eseguite dal
1007 \textit{lease breaker} rimaste bloccate proseguono automaticamente.
1010 \index{file!dnotify|(}
1012 Benché possa risultare utile per sincronizzare l'accesso ad uno stesso file da
1013 parte di più processi, l'uso dei \textit{file lease} non consente comunque di
1014 risolvere il problema di rilevare automaticamente quando un file o una
1015 directory vengono modificati, che è quanto necessario ad esempio ai programma
1016 di gestione dei file dei vari desktop grafici.
1018 Per risolvere questo problema è stata allora creata un'altra interfaccia,
1019 chiamata \textit{dnotify}, che consente di richiedere una notifica quando una
1020 directory, o di uno qualunque dei file in essa contenuti, viene modificato.
1021 Come per i \textit{file lease} la notifica avviene di default attraverso il
1022 segnale \const{SIGIO}, ma se ne può utilizzare un altro. Inoltre si potrà
1023 ottenere nel gestore del segnale il file descriptor che è stato modificato
1024 tramite il contenuto della struttura \struct{siginfo\_t}.
1026 \index{file!lease|)}
1031 \begin{tabular}[c]{|l|p{8cm}|}
1033 \textbf{Valore} & \textbf{Significato} \\
1036 \const{DN\_ACCESS} & Un file è stato acceduto, con l'esecuzione di una fra
1037 \func{read}, \func{pread}, \func{readv}.\\
1038 \const{DN\_MODIFY} & Un file è stato modificato, con l'esecuzione di una
1039 fra \func{write}, \func{pwrite}, \func{writev},
1040 \func{truncate}, \func{ftruncate}.\\
1041 \const{DN\_CREATE} & È stato creato un file nella directory, con
1042 l'esecuzione di una fra \func{open}, \func{creat},
1043 \func{mknod}, \func{mkdir}, \func{link},
1044 \func{symlink}, \func{rename} (da un'altra
1046 \const{DN\_DELETE} & È stato cancellato un file dalla directory con
1047 l'esecuzione di una fra \func{unlink}, \func{rename}
1048 (su un'altra directory), \func{rmdir}.\\
1049 \const{DN\_RENAME} & È stato rinominato un file all'interno della
1050 directory (con \func{rename}).\\
1051 \const{DN\_ATTRIB} & È stato modificato un attributo di un file con
1052 l'esecuzione di una fra \func{chown}, \func{chmod},
1054 \const{DN\_MULTISHOT}& richiede una notifica permanente di tutti gli
1058 \caption{Le costanti che identificano le varie classi di eventi per i quali
1059 si richiede la notifica con il comando \const{F\_NOTIFY} di \func{fcntl}.}
1060 \label{tab:file_notify}
1063 Ci si può registrare per le notifiche dei cambiamenti al contenuto di una
1064 certa directory eseguendo la funzione \func{fcntl} su un file descriptor
1065 associato alla stessa con il comando \const{F\_NOTIFY}. In questo caso
1066 l'argomento \param{arg} di \func{fcntl} serve ad indicare per quali classi
1067 eventi si vuole ricevere la notifica, e prende come valore una maschera
1068 binaria composta dall'OR aritmetico di una o più delle costanti riportate in
1069 tab.~\ref{tab:file_notify}.
1071 A meno di non impostare in maniera esplicita una notifica permanente usando il
1072 valore \const{DN\_MULTISHOT}, la notifica è singola: viene cioè inviata una
1073 sola volta quando si verifica uno qualunque fra gli eventi per i quali la si è
1074 richiesta. Questo significa che un programma deve registrarsi un'altra volta
1075 se desidera essere notificato di ulteriori cambiamenti. Se si eseguono diverse
1076 chiamate con \const{F\_NOTIFY} e con valori diversi per \param{arg} questi
1077 ultimi si \textsl{accumulano}; cioè eventuali nuovi classi di eventi
1078 specificate in chiamate successive vengono aggiunte a quelle già impostate
1079 nelle precedenti. Se si vuole rimuovere la notifica si deve invece
1080 specificare un valore nullo.
1082 \index{file!inotify|(}
1084 Il maggiore problema di \textit{dnotify} è quello della scalabilità: si deve
1085 usare un file descriptor per ciascuna directory che si vuole tenere sotto
1086 controllo, il che porta facilmente ad un eccesso di file aperti. Inoltre
1087 quando la directory è su un dispositivo rimovibile, mantenere un file
1088 descriptor aperto comporta l'impossibilità di smontare il dispositivo e
1089 rimuoverlo, complicando la gestione.
1091 Un secondo problema è che l'interfaccia consente solo di tenere sotto
1092 controllo il contenuto di una directory; la modifica di un file viene
1093 segnalata, ma poi devo verificare quale è. Infine l'uso dei segnali come
1094 interfaccia di notifica comporta tutti i problemi di gestione visti in
1095 sez.~\ref{sec:sig_management} e sez.~\ref{sec:sig_control}, e per questo in
1096 generale quella di \textit{dnotify} viene considerata una interfaccia di
1097 usabilità problematica.
1099 \index{file!dnotify|)}
1101 Per questa serie di motivi, a partire dal kernel 2.6.13, è stata introdotta
1102 una nuova interfaccia per l'osservazione delle modifiche a file o directory,
1103 chiamata \textit{inotify}.\footnote{le corrispondenti funzioni di interfaccia
1104 sono state introdotte nelle glibc 2.4.} Questa è una interfaccia specifica
1105 di Linux (pertanto non deve essere usata se si devono scrivere programmi
1106 portabili), ed è basata sull'uso di una coda di notifica degli eventi
1107 associata ad un singolo file descriptor, risolvendo così il principale
1108 problema di \itindex{dnotify} \textit{dnotify}. La coda viene creata
1109 attraverso la funzione \funcd{inotify\_init}, il cui prototipo è:
1110 \begin{prototype}{sys/inotify.h}
1111 {int inotify\_init(void)}
1113 Inizializza una istanza di \textit{inotify}.
1115 \bodydesc{La funzione restituisce un file descriptor in caso di successo, o
1116 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1118 \item[\errcode{EMFILE}] si è raggiunto il numero massimo di istanze di
1119 \textit{inotify} consentite all'utente.
1120 \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
1122 \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
1128 La funzione non prende alcun argomento, e restituisce un file descriptor
1129 associato alla coda, attraverso il quale verranno effettuate le operazioni di
1130 notifica. Si tratta di un file descriptor speciale, che non è associato a
1131 nessun file, ma che viene utilizzato per notificare gli eventi che si sono
1132 posti in osservazione all'applicazione che usa l'interfaccia di
1133 \textit{inotify}. Dato che questo file descriptor non è associato a nessun
1134 file o directory, questo consente di evitare l'inconveniente di non poter
1135 smontare un filesystem i cui file sono tenuti sotto osservazione.\footnote{ed
1136 una delle caratteristiche dell'interfaccia di \textit{inotify} è proprio
1137 quella di notificare il fatto che il filesystem su cui si trova il file o la
1138 directory osservata è stato smontato.}
1140 Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà
1141 essere utilizzato come argomento per le funzioni \func{select} e \func{poll},
1142 e siccome gli eventi vengono notificati come dati disponibili in lettura sul
1143 file descriptor, dette funzioni ritorneranno tutte le volte che si avrà un
1144 evento di notifica. Così, invece di dover utilizzare i segnali, si potrà
1145 gestire l'osservazione delle modifiche con l'\textit{I/O multiplexing},
1146 utilizzando secondo le modalità illustrate in
1147 sez.~\ref{sec:file_multiplexing}.
1149 Infine l'interfaccia di \textit{inotify} consente di mettere sotto
1150 osservazione sia singoli file, che intere directory; in quest'ultimo caso
1151 l'interfaccia restituirà informazioni sia riguardo alla directory che ai file
1152 che essa contiene. Una volta creata la coda di notifica si devono definire
1153 gli eventi da tenere sotto osservazione; questo viene fatto tramite una
1154 \textsl{lista di osservazione} (o \textit{watch list}) associata alla coda.
1155 Per gestire la lista di osservazione l'interfaccia fornisce due funzioni, la
1156 prima di queste è \funcd{inotify\_add\_watch}, il cui prototipo è:
1157 \begin{prototype}{sys/inotify.h}
1158 {int inotify\_add\_watch(int fd, const char *pathname, uint32\_t mask)}
1160 Aggiunge un evento di osservazione alla lista di osservazione di \param{fd}.
1162 \bodydesc{La funzione restituisce un valore positivo in caso di successo, o
1163 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1165 \item[\errcode{EACCESS}] non si ha accesso in lettura al file indicato.
1166 \item[\errcode{EINVAL}] \param{mask} non contiene eventi legali o \param{fd}
1167 non è un filesystem di \textit{inotify}.
1168 \item[\errcode{ENOSPC}] si è raggiunto il numero massimo di voci di
1169 osservazione o il kernel non ha potuto allocare una risorsa necessaria.
1171 ed inoltre \errval{EFAULT}, \errval{ENOMEM} e \errval{EBADF}.}
1174 La funzione consente di creare un \textsl{evento di osservazione} (un
1175 cosiddetto ``\textit{watch}'') nella lista di una coda di notifica, indicata
1176 specificando il file descriptor ad essa associato nell'argomento \param{fd}.
1177 Il file o la directory da porre sotto osservazione viene invece indicato per
1178 nome, che viene passato nell'argomento \param{pathname}. Infine il terzo
1179 argomento, \param{mask}, indica che tipo di eventi devono essere tenuti sotto
1180 osservazione. Questo deve essere specificato come maschera binaria combinando
1181 i valori delle costanti riportate in tab.~\ref{tab:inotify_event_watch}. In
1182 essa si sono marcati con un ``$\bullet$'' gli eventi che, quando specificati
1183 per una directory, vengono osservati anche su tutti i file che essa contiene.
1188 \begin{tabular}[c]{|l|c|p{10cm}|}
1190 \textbf{Valore} & & \textbf{Significato} \\
1193 \const{IN\_ACCESS} &$\bullet$& c'è stato accesso al file in
1195 \const{IN\_ATTRIB} &$\bullet$& ci sono stati cambiamenti sui dati
1197 \const{IN\_CLOSE\_WRITE} &$\bullet$& è stato chiuso un file aperto in
1199 \const{IN\_CLOSE\_NOWRITE}&$\bullet$& è stato chiuso un file aperto in
1201 \const{IN\_CREATE} &$\bullet$& è stato creato un file o una
1202 directory in una directory sotto
1204 \const{IN\_DELETE} &$\bullet$& è stato cancellato un file o una
1205 directory in una directory sotto
1207 \const{IN\_DELETE\_SELF} & & è stato cancellato il file (o la
1208 directory) sotto osservazione.\\
1209 \const{IN\_MODIFY} &$\bullet$& è stato modificato il file.\\
1210 \const{IN\_MOVE\_SELF} & & è stato rinominato il file (o la
1211 directory) sotto osservazione.\\
1212 \const{IN\_MOVED\_FROM} &$\bullet$& un file è stato spostato fuori dalla
1213 directory sotto osservazione.\\
1214 \const{IN\_MOVED\_TO} &$\bullet$& un file è stato spostato nella
1215 directory sotto osservazione.\\
1216 \const{IN\_OPEN} &$\bullet$& un file è stato aperto.\\
1219 \caption{Le costanti che identificano i valori per la maschera binaria
1220 dell'argomento \param{mask} di \func{inotify\_add\_watch}.}
1221 \label{tab:inotify_event_watch}
1224 Se non esiste nessun \textit{watch} per il file (o la directory) specificata
1225 questo verrà creato per gli eventi specificati dall'argomento \param{mask},
1226 altrimenti la funzione sovrascriverà le impostazioni precedenti. In caso di
1227 successo la funzione ritorna un intero positivo, detto \textit{watch
1228 descriptor} che identifica univocamente l'evento di osservazione. Questo
1229 valore è importante perché è soltanto con esso che si può rimuovere un evento
1230 di osservazione, usando la seconda funzione dell'interfaccia di gestione,
1231 \funcd{inotify\_rm\_watch}, il cui prototipo è:
1232 \begin{prototype}{sys/inotify.h}
1233 {int inotify\_rm\_watch(int fd, uint32\_t wd)}
1235 Rimuove un evento di osservazione.
1237 \bodydesc{La funzione restituisce 0 in caso di successo, o $-1$ in caso di
1238 errore, nel qual caso \var{errno} assumerà uno dei valori:
1240 \item[\errcode{EBADF}] non si è specificato in \param{fd} un file descriptor
1242 \item[\errcode{EINVAL}] il valore di \param{wd} non è corretto, o \param{fd}
1243 non è associato ad una coda di notifica.
1248 Oltre che per la rimozione, il \textit{watch descriptor} viene usato anche per
1249 identificare l'evento a cui si fa riferimento nella lista dei risultati
1250 restituiti da \textit{inotify}
1253 \begin{figure}[!htb]
1254 \footnotesize \centering
1255 \begin{minipage}[c]{15cm}
1256 \includestruct{listati/inotify_event.h}
1259 \caption{La struttura \structd{inotify\_event}.}
1260 \label{fig:inotify_event}
1264 Inoltre l'interfaccia di \textit{inotify} permette di conoscere, come avviene
1265 per i file descriptor associati ai socket (si veda al proposito quanto
1266 trattato in sez.~\ref{sec:sock_ioctl_IP}) il numero di byte disponibili in
1267 lettura sul nostro file descriptor, utilizzando su di esso l'operazione
1268 \const{FIONREAD} con \func{ioctl}.\footnote{questa è una delle operazioni
1269 speciali (che abbiamo visto in sez.~\ref{sec:file_ioctl}) che nel caso è
1270 disponibile solo per i socket e per i file descriptor creati con
1271 \func{inotify\_init}.} Questo consente anche di ottenere rapidamente il
1272 numero di file che sono cambiati.
1276 % TODO inserire anche inotify, vedi http://www.linuxjournal.com/article/8478
1277 % TODO e man inotify
1279 \index{file!inotify|)}
1282 % TODO inserire anche eventfd (vedi http://lwn.net/Articles/233462/)
1286 \subsection{L'interfaccia POSIX per l'I/O asincrono}
1287 \label{sec:file_asyncronous_io}
1289 Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione
1290 dell'I/O simultaneo su molti file è costituita dal cosiddetto \textsl{I/O
1291 asincrono}. Il concetto base dell'\textsl{I/O asincrono} è che le funzioni
1292 di I/O non attendono il completamento delle operazioni prima di ritornare,
1293 così che il processo non viene bloccato. In questo modo diventa ad esempio
1294 possibile effettuare una richiesta preventiva di dati, in modo da poter
1295 effettuare in contemporanea le operazioni di calcolo e quelle di I/O.
1297 Benché la modalità di apertura asincrona di un file possa risultare utile in
1298 varie occasioni (in particolar modo con i socket e gli altri file per i quali
1299 le funzioni di I/O sono \index{system~call~lente} system call lente), essa è
1300 comunque limitata alla notifica della disponibilità del file descriptor per le
1301 operazioni di I/O, e non ad uno svolgimento asincrono delle medesime. Lo
1302 standard POSIX.1b definisce una interfaccia apposita per l'I/O asincrono vero
1303 e proprio, che prevede un insieme di funzioni dedicate per la lettura e la
1304 scrittura dei file, completamente separate rispetto a quelle usate
1307 In generale questa interfaccia è completamente astratta e può essere
1308 implementata sia direttamente nel kernel, che in user space attraverso l'uso
1309 di thread. Per le versioni del kernel meno recenti esiste una implementazione
1310 di questa interfaccia fornita delle \acr{glibc}, che è realizzata
1311 completamente in user space, ed è accessibile linkando i programmi con la
1312 libreria \file{librt}. Nelle versioni più recenti (a partire dalla 2.5.32) è
1313 stato introdotto direttamente nel kernel un nuovo layer per l'I/O asincrono.
1315 Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
1316 attraverso l'uso di una apposita struttura \struct{aiocb} (il cui nome sta per
1317 \textit{asyncronous I/O control block}), che viene passata come argomento a
1318 tutte le funzioni dell'interfaccia. La sua definizione, come effettuata in
1319 \file{aio.h}, è riportata in fig.~\ref{fig:file_aiocb}. Nello steso file è
1320 definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la
1321 disponibilità dell'interfaccia per l'I/O asincrono.
1323 \begin{figure}[!htb]
1324 \footnotesize \centering
1325 \begin{minipage}[c]{15cm}
1326 \includestruct{listati/aiocb.h}
1329 \caption{La struttura \structd{aiocb}, usata per il controllo dell'I/O
1331 \label{fig:file_aiocb}
1334 Le operazioni di I/O asincrono possono essere effettuate solo su un file già
1335 aperto; il file deve inoltre supportare la funzione \func{lseek}, pertanto
1336 terminali e pipe sono esclusi. Non c'è limite al numero di operazioni
1337 contemporanee effettuabili su un singolo file. Ogni operazione deve
1338 inizializzare opportunamente un \textit{control block}. Il file descriptor su
1339 cui operare deve essere specificato tramite il campo \var{aio\_fildes}; dato
1340 che più operazioni possono essere eseguita in maniera asincrona, il concetto
1341 di posizione corrente sul file viene a mancare; pertanto si deve sempre
1342 specificare nel campo \var{aio\_offset} la posizione sul file da cui i dati
1343 saranno letti o scritti. Nel campo \var{aio\_buf} deve essere specificato
1344 l'indirizzo del buffer usato per l'I/O, ed in \var{aio\_nbytes} la lunghezza
1345 del blocco di dati da trasferire.
1347 Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni
1348 di I/O.\footnote{in generale perché ciò sia possibile occorre che la
1349 piattaforma supporti questa caratteristica, questo viene indicato definendo
1350 le macro \macro{\_POSIX\_PRIORITIZED\_IO}, e
1351 \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene impostata a
1352 partire da quella del processo chiamante (vedi sez.~\ref{sec:proc_priority}),
1353 cui viene sottratto il valore di questo campo. Il campo
1354 \var{aio\_lio\_opcode} è usato solo dalla funzione \func{lio\_listio}, che,
1355 come vedremo, permette di eseguire con una sola chiamata una serie di
1356 operazioni, usando un vettore di \textit{control block}. Tramite questo campo
1357 si specifica quale è la natura di ciascuna di esse.
1359 \begin{figure}[!htb]
1360 \footnotesize \centering
1361 \begin{minipage}[c]{15cm}
1362 \includestruct{listati/sigevent.h}
1365 \caption{La struttura \structd{sigevent}, usata per specificare le modalità
1366 di notifica degli eventi relativi alle operazioni di I/O asincrono.}
1367 \label{fig:file_sigevent}
1370 Infine il campo \var{aio\_sigevent} è una struttura di tipo \struct{sigevent}
1371 che serve a specificare il modo in cui si vuole che venga effettuata la
1372 notifica del completamento delle operazioni richieste. La struttura è
1373 riportata in fig.~\ref{fig:file_sigevent}; il campo \var{sigev\_notify} è
1374 quello che indica le modalità della notifica, esso può assumere i tre valori:
1375 \begin{basedescript}{\desclabelwidth{2.6cm}}
1376 \item[\const{SIGEV\_NONE}] Non viene inviata nessuna notifica.
1377 \item[\const{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo
1378 chiamante il segnale specificato da \var{sigev\_signo}; se il gestore di
1379 questo è stato installato con \const{SA\_SIGINFO} gli verrà restituito il
1380 valore di \var{sigev\_value} (la cui definizione è in
1381 fig.~\ref{fig:sig_sigval}) come valore del campo \var{si\_value} di
1382 \struct{siginfo\_t}.
1383 \item[\const{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo
1384 thread che esegue la funzione specificata da \var{sigev\_notify\_function}
1385 con argomento \var{sigev\_value}, e con gli attributi specificati da
1386 \var{sigev\_notify\_attribute}.
1389 Le due funzioni base dell'interfaccia per l'I/O asincrono sono
1390 \funcd{aio\_read} ed \funcd{aio\_write}. Esse permettono di richiedere una
1391 lettura od una scrittura asincrona di dati, usando la struttura \struct{aiocb}
1392 appena descritta; i rispettivi prototipi sono:
1396 \funcdecl{int aio\_read(struct aiocb *aiocbp)}
1397 Richiede una lettura asincrona secondo quanto specificato con \param{aiocbp}.
1399 \funcdecl{int aio\_write(struct aiocb *aiocbp)}
1400 Richiede una scrittura asincrona secondo quanto specificato con
1403 \bodydesc{Le funzioni restituiscono 0 in caso di successo, e -1 in caso di
1404 errore, nel qual caso \var{errno} assumerà uno dei valori:
1406 \item[\errcode{EBADF}] Si è specificato un file descriptor sbagliato.
1407 \item[\errcode{ENOSYS}] La funzione non è implementata.
1408 \item[\errcode{EINVAL}] Si è specificato un valore non valido per i campi
1409 \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}.
1410 \item[\errcode{EAGAIN}] La coda delle richieste è momentaneamente piena.
1415 Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la
1416 richiesta, o in caso di errore. Non è detto che gli errori \errcode{EBADF} ed
1417 \errcode{EINVAL} siano rilevati immediatamente al momento della chiamata,
1418 potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e
1419 scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che
1420 il file non sia stato aperto in \itindex{append~mode} \textit{append mode}
1421 (vedi sez.~\ref{sec:file_open}), nel qual caso le scritture vengono effettuate
1422 comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}.
1424 Si tenga inoltre presente che deallocare la memoria indirizzata da
1425 \param{aiocbp} o modificarne i valori prima della conclusione di una
1426 operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
1427 campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
1428 richiesta. Questo comporta che non si devono usare per \param{aiocbp}
1429 variabili automatiche e che non si deve riutilizzare la stessa struttura per
1430 un'altra operazione fintanto che la precedente non sia stata ultimata. In
1431 generale per ogni operazione si deve utilizzare una diversa struttura
1434 Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
1435 \func{aio\_write} non implica che le operazioni siano state effettivamente
1436 eseguite in maniera corretta; per verificarne l'esito l'interfaccia prevede
1437 altre due funzioni, che permettono di controllare lo stato di esecuzione. La
1438 prima è \funcd{aio\_error}, che serve a determinare un eventuale stato di
1439 errore; il suo prototipo è:
1440 \begin{prototype}{aio.h}
1441 {int aio\_error(const struct aiocb *aiocbp)}
1443 Determina lo stato di errore delle operazioni di I/O associate a
1446 \bodydesc{La funzione restituisce 0 se le operazioni si sono concluse con
1447 successo, altrimenti restituisce il codice di errore relativo al loro
1451 Se l'operazione non si è ancora completata viene restituito l'errore di
1452 \errcode{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è
1453 conclusa con successo, altrimenti restituisce il codice dell'errore
1454 verificatosi, ed esegue la corrispondente impostazione di \var{errno}. Il
1455 codice può essere sia \errcode{EINVAL} ed \errcode{EBADF}, dovuti ad un valore
1456 errato per \param{aiocbp}, che uno degli errori possibili durante l'esecuzione
1457 dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda
1458 del caso, i codici di errore delle system call \func{read}, \func{write} e
1461 Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
1462 che una chiamata ad \func{aio\_error} non ha restituito
1463 \errcode{EINPROGRESS}), si potrà usare la funzione \funcd{aio\_return}, che
1464 permette di verificare il completamento delle operazioni di I/O asincrono; il
1466 \begin{prototype}{aio.h}
1467 {ssize\_t aio\_return(const struct aiocb *aiocbp)}
1469 Recupera il valore dello stato di ritorno delle operazioni di I/O associate a
1472 \bodydesc{La funzione restituisce lo stato di uscita dell'operazione
1476 La funzione deve essere chiamata una sola volte per ciascuna operazione
1477 asincrona, essa infatti fa sì che il sistema rilasci le risorse ad essa
1478 associate. É per questo motivo che occorre chiamare la funzione solo dopo che
1479 l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata
1480 precedente il completamento delle operazioni darebbe risultati indeterminati.
1482 La funzione restituisce il valore di ritorno relativo all'operazione eseguita,
1483 così come ricavato dalla sottostante system call (il numero di byte letti,
1484 scritti o il valore di ritorno di \func{fsync}). É importante chiamare sempre
1485 questa funzione, altrimenti le risorse disponibili per le operazioni di I/O
1486 asincrono non verrebbero liberate, rischiando di arrivare ad un loro
1489 Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a
1490 disposizione un'altra operazione, quella di sincronizzazione dell'I/O,
1491 compiuta dalla funzione \funcd{aio\_fsync}, che ha lo stesso effetto della
1492 analoga \func{fsync}, ma viene eseguita in maniera asincrona; il suo prototipo
1494 \begin{prototype}{aio.h}
1495 {int aio\_fsync(int op, struct aiocb *aiocbp)}
1497 Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}.
1499 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1500 errore, che può essere, con le stesse modalità di \func{aio\_read},
1501 \errval{EAGAIN}, \errval{EBADF} o \errval{EINVAL}.}
1504 La funzione richiede la sincronizzazione delle operazioni di I/O, ritornando
1505 immediatamente. L'esecuzione effettiva della sincronizzazione dovrà essere
1506 verificata con \func{aio\_error} e \func{aio\_return} come per le operazioni
1507 di lettura e scrittura. L'argomento \param{op} permette di indicare la
1508 modalità di esecuzione, se si specifica il valore \const{O\_DSYNC} le
1509 operazioni saranno completate con una chiamata a \func{fdatasync}, se si
1510 specifica \const{O\_SYNC} con una chiamata a \func{fsync} (per i dettagli vedi
1511 sez.~\ref{sec:file_sync}).
1513 Il successo della chiamata assicura la sincronizzazione delle operazioni fino
1514 allora richieste, niente è garantito riguardo la sincronizzazione dei dati
1515 relativi ad eventuali operazioni richieste successivamente. Se si è
1516 specificato un meccanismo di notifica questo sarà innescato una volta che le
1517 operazioni di sincronizzazione dei dati saranno completate.
1519 In alcuni casi può essere necessario interrompere le operazioni (in genere
1520 quando viene richiesta un'uscita immediata dal programma), per questo lo
1521 standard POSIX.1b prevede una funzioni apposita, \funcd{aio\_cancel}, che
1522 permette di cancellare una operazione richiesta in precedenza; il suo
1524 \begin{prototype}{aio.h}
1525 {int aio\_cancel(int fildes, struct aiocb *aiocbp)}
1527 Richiede la cancellazione delle operazioni sul file \param{fildes} specificate
1530 \bodydesc{La funzione restituisce il risultato dell'operazione con un codice
1531 di positivo, e -1 in caso di errore, che avviene qualora si sia specificato
1532 un valore non valido di \param{fildes}, imposta \var{errno} al valore
1536 La funzione permette di cancellare una operazione specifica sul file
1537 \param{fildes}, o tutte le operazioni pendenti, specificando \val{NULL} come
1538 valore di \param{aiocbp}. Quando una operazione viene cancellata una
1539 successiva chiamata ad \func{aio\_error} riporterà \errcode{ECANCELED} come
1540 codice di errore, ed il suo codice di ritorno sarà -1, inoltre il meccanismo
1541 di notifica non verrà invocato. Se si specifica una operazione relativa ad un
1542 altro file descriptor il risultato è indeterminato. In caso di successo, i
1543 possibili valori di ritorno per \func{aio\_cancel} (anch'essi definiti in
1544 \file{aio.h}) sono tre:
1545 \begin{basedescript}{\desclabelwidth{3.0cm}}
1546 \item[\const{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
1547 cancellazione sono state già completate,
1549 \item[\const{AIO\_CANCELED}] indica che tutte le operazioni richieste sono
1552 \item[\const{AIO\_NOTCANCELED}] indica che alcune delle operazioni erano in
1553 corso e non sono state cancellate.
1556 Nel caso si abbia \const{AIO\_NOTCANCELED} occorrerà chiamare
1557 \func{aio\_error} per determinare quali sono le operazioni effettivamente
1558 cancellate. Le operazioni che non sono state cancellate proseguiranno il loro
1559 corso normale, compreso quanto richiesto riguardo al meccanismo di notifica
1560 del loro avvenuto completamento.
1562 Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia
1563 fornisce anche una apposita funzione, \funcd{aio\_suspend}, che permette di
1564 sospendere l'esecuzione del processo chiamante fino al completamento di una
1565 specifica operazione; il suo prototipo è:
1566 \begin{prototype}{aio.h}
1567 {int aio\_suspend(const struct aiocb * const list[], int nent, const struct
1570 Attende, per un massimo di \param{timeout}, il completamento di una delle
1571 operazioni specificate da \param{list}.
1573 \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state
1574 completate, e -1 in caso di errore nel qual caso \var{errno} assumerà uno
1577 \item[\errcode{EAGAIN}] Nessuna operazione è stata completata entro
1579 \item[\errcode{ENOSYS}] La funzione non è implementata.
1580 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
1585 La funzione permette di bloccare il processo fintanto che almeno una delle
1586 \param{nent} operazioni specificate nella lista \param{list} è completata, per
1587 un tempo massimo specificato da \param{timout}, o fintanto che non arrivi un
1588 segnale.\footnote{si tenga conto che questo segnale può anche essere quello
1589 utilizzato come meccanismo di notifica.} La lista deve essere inizializzata
1590 con delle strutture \struct{aiocb} relative ad operazioni effettivamente
1591 richieste, ma può contenere puntatori nulli, che saranno ignorati. In caso si
1592 siano specificati valori non validi l'effetto è indefinito. Un valore
1593 \val{NULL} per \param{timout} comporta l'assenza di timeout.
1595 Lo standard POSIX.1b infine ha previsto pure una funzione, \funcd{lio\_listio},
1596 che permette di effettuare la richiesta di una intera lista di operazioni di
1597 lettura o scrittura; il suo prototipo è:
1598 \begin{prototype}{aio.h}
1599 {int lio\_listio(int mode, struct aiocb * const list[], int nent, struct
1602 Richiede l'esecuzione delle operazioni di I/O elencata da \param{list},
1603 secondo la modalità \param{mode}.
1605 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1606 errore, nel qual caso \var{errno} assumerà uno dei valori:
1608 \item[\errcode{EAGAIN}] Nessuna operazione è stata completata entro
1610 \item[\errcode{EINVAL}] Si è passato un valore di \param{mode} non valido
1611 o un numero di operazioni \param{nent} maggiore di
1612 \const{AIO\_LISTIO\_MAX}.
1613 \item[\errcode{ENOSYS}] La funzione non è implementata.
1614 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
1619 La funzione esegue la richiesta delle \param{nent} operazioni indicate nella
1620 lista \param{list} che deve contenere gli indirizzi di altrettanti
1621 \textit{control block} opportunamente inizializzati; in particolare dovrà
1622 essere specificato il tipo di operazione con il campo \var{aio\_lio\_opcode},
1623 che può prendere i valori:
1624 \begin{basedescript}{\desclabelwidth{2.0cm}}
1625 \item[\const{LIO\_READ}] si richiede una operazione di lettura.
1626 \item[\const{LIO\_WRITE}] si richiede una operazione di scrittura.
1627 \item[\const{LIO\_NOP}] non si effettua nessuna operazione.
1629 dove \const{LIO\_NOP} viene usato quando si ha a che fare con un vettore di
1630 dimensione fissa, per poter specificare solo alcune operazioni, o quando si
1631 sono dovute cancellare delle operazioni e si deve ripetere la richiesta per
1632 quelle non completate.
1634 L'argomento \param{mode} controlla il comportamento della funzione, se viene
1635 usato il valore \const{LIO\_WAIT} la funzione si blocca fino al completamento
1636 di tutte le operazioni richieste; se si usa \const{LIO\_NOWAIT} la funzione
1637 ritorna immediatamente dopo aver messo in coda tutte le richieste. In tal caso
1638 il chiamante può richiedere la notifica del completamento di tutte le
1639 richieste, impostando l'argomento \param{sig} in maniera analoga a come si fa
1640 per il campo \var{aio\_sigevent} di \struct{aiocb}.
1643 \section{Altre modalità di I/O avanzato}
1644 \label{sec:file_advanced_io}
1646 Oltre alle precedenti modalità di \textit{I/O multiplexing} e \textsl{I/O
1647 asincrono}, esistono altre funzioni che implementano delle modalità di
1648 accesso ai file più evolute rispetto alle normali funzioni di lettura e
1649 scrittura che abbiamo esaminato in sez.~\ref{sec:file_base_func}. In questa
1650 sezione allora prenderemo in esame le interfacce per l'\textsl{I/O
1651 vettorizzato} e per l'\textsl{I/O mappato in memoria} e la funzione
1655 \subsection{I/O vettorizzato}
1656 \label{sec:file_multiple_io}
1658 Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una
1659 serie multipla di operazioni di I/O, come una serie di letture o scritture di
1660 vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di
1661 una struttura ed essi devono essere caricati o salvati su un file. Benché
1662 l'operazione sia facilmente eseguibile attraverso una serie multipla di
1663 chiamate, ci sono casi in cui si vuole poter contare sulla atomicità delle
1666 Per questo motivo BSD 4.2\footnote{Le due funzioni sono riprese da BSD4.4 ed
1667 integrate anche dallo standard Unix 98. Fino alle libc5, Linux usava
1668 \type{size\_t} come tipo dell'argomento \param{count}, una scelta logica,
1669 che però è stata dismessa per restare aderenti allo standard.} ha introdotto
1670 due nuove system call, \funcd{readv} e \funcd{writev}, che permettono di
1671 effettuare con una sola chiamata una lettura o una scrittura su una serie di
1672 buffer (quello che viene chiamato \textsl{I/O vettorizzato}. I relativi
1675 \headdecl{sys/uio.h}
1677 \funcdecl{int readv(int fd, const struct iovec *vector, int count)}
1678 \funcdecl{int writev(int fd, const struct iovec *vector, int count)}
1680 Eseguono rispettivamente una lettura o una scrittura vettorizzata.
1682 \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti in
1683 caso di successo, e -1 in caso di errore, nel qual caso \var{errno}
1684 assumerà uno dei valori:
1686 \item[\errcode{EINVAL}] si è specificato un valore non valido per uno degli
1687 argomenti (ad esempio \param{count} è maggiore di \const{MAX\_IOVEC}).
1688 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
1689 di avere eseguito una qualunque lettura o scrittura.
1690 \item[\errcode{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e
1691 non ci sono dati in lettura.
1692 \item[\errcode{EOPNOTSUPP}] la coda delle richieste è momentaneamente piena.
1694 ed anche \errval{EISDIR}, \errval{EBADF}, \errval{ENOMEM}, \errval{EFAULT}
1695 (se non sono stati allocati correttamente i buffer specificati nei campi
1696 \var{iov\_base}), più gli eventuali errori delle funzioni di lettura e
1697 scrittura eseguite su \param{fd}.}
1700 Entrambe le funzioni usano una struttura \struct{iovec}, la cui definizione è
1701 riportata in fig.~\ref{fig:file_iovec}, che definisce dove i dati devono
1702 essere letti o scritti ed in che quantità. Il primo campo della struttura,
1703 \var{iov\_base}, contiene l'indirizzo del buffer ed il secondo,
1704 \var{iov\_len}, la dimensione dello stesso.
1706 \begin{figure}[!htb]
1707 \footnotesize \centering
1708 \begin{minipage}[c]{15cm}
1709 \includestruct{listati/iovec.h}
1712 \caption{La struttura \structd{iovec}, usata dalle operazioni di I/O
1714 \label{fig:file_iovec}
1717 La lista dei buffer da utilizzare viene indicata attraverso l'argomento
1718 \param{vector} che è un vettore di strutture \struct{iovec}, la cui lunghezza
1719 è specificata dall'argomento \param{count}. Ciascuna struttura dovrà essere
1720 inizializzata opportunamente per indicare i vari buffer da e verso i quali
1721 verrà eseguito il trasferimento dei dati. Essi verranno letti (o scritti)
1722 nell'ordine in cui li si sono specificati nel vettore \param{vector}.
1725 \subsection{File mappati in memoria}
1726 \label{sec:file_memory_map}
1728 \itindbeg{memory~mapping}
1729 Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
1730 rispetto a quella classica vista in cap.~\ref{cha:file_unix_interface}, è il
1731 cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della
1732 \textsl{paginazione} \index{paginazione} usato dalla memoria virtuale (vedi
1733 sez.~\ref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un
1734 file in una sezione dello spazio di indirizzi del processo.
1738 \includegraphics[width=10cm]{img/mmap_layout}
1739 \caption{Disposizione della memoria di un processo quando si esegue la
1740 mappatura in memoria di un file.}
1741 \label{fig:file_mmap_layout}
1744 Il meccanismo è illustrato in fig.~\ref{fig:file_mmap_layout}, una sezione del
1745 file viene \textsl{mappata} direttamente nello spazio degli indirizzi del
1746 programma. Tutte le operazioni di lettura e scrittura su variabili contenute
1747 in questa zona di memoria verranno eseguite leggendo e scrivendo dal contenuto
1748 del file attraverso il sistema della memoria virtuale \index{memoria~virtuale}
1749 che in maniera analoga a quanto avviene per le pagine che vengono salvate e
1750 rilette nella swap, si incaricherà di sincronizzare il contenuto di quel
1751 segmento di memoria con quello del file mappato su di esso. Per questo motivo
1752 si può parlare tanto di \textsl{file mappato in memoria}, quanto di
1753 \textsl{memoria mappata su file}.
1755 L'uso del \textit{memory-mapping} comporta una notevole semplificazione delle
1756 operazioni di I/O, in quanto non sarà più necessario utilizzare dei buffer
1757 intermedi su cui appoggiare i dati da traferire, poiché questi potranno essere
1758 acceduti direttamente nella sezione di memoria mappata; inoltre questa
1759 interfaccia è più efficiente delle usuali funzioni di I/O, in quanto permette
1760 di caricare in memoria solo le parti del file che sono effettivamente usate ad
1763 Infatti, dato che l'accesso è fatto direttamente attraverso la
1764 \index{memoria~virtuale} memoria virtuale, la sezione di memoria mappata su
1765 cui si opera sarà a sua volta letta o scritta sul file una pagina alla volta e
1766 solo per le parti effettivamente usate, il tutto in maniera completamente
1767 trasparente al processo; l'accesso alle pagine non ancora caricate avverrà
1768 allo stesso modo con cui vengono caricate in memoria le pagine che sono state
1771 Infine in situazioni in cui la memoria è scarsa, le pagine che mappano un file
1772 vengono salvate automaticamente, così come le pagine dei programmi vengono
1773 scritte sulla swap; questo consente di accedere ai file su dimensioni il cui
1774 solo limite è quello dello spazio di indirizzi disponibile, e non della
1775 memoria su cui possono esserne lette delle porzioni.
1777 L'interfaccia POSIX implementata da Linux prevede varie funzioni per la
1778 gestione del \textit{memory mapped I/O}, la prima di queste, che serve ad
1779 eseguire la mappatura in memoria di un file, è \funcd{mmap}; il suo prototipo
1784 \headdecl{sys/mman.h}
1786 \funcdecl{void * mmap(void * start, size\_t length, int prot, int flags, int
1789 Esegue la mappatura in memoria della sezione specificata del file \param{fd}.
1791 \bodydesc{La funzione restituisce il puntatore alla zona di memoria mappata
1792 in caso di successo, e \const{MAP\_FAILED} (-1) in caso di errore, nel
1793 qual caso \var{errno} assumerà uno dei valori:
1795 \item[\errcode{EBADF}] Il file descriptor non è valido, e non si è usato
1796 \const{MAP\_ANONYMOUS}.
1797 \item[\errcode{EACCES}] o \param{fd} non si riferisce ad un file regolare,
1798 o si è usato \const{MAP\_PRIVATE} ma \param{fd} non è aperto in lettura,
1799 o si è usato \const{MAP\_SHARED} e impostato \const{PROT\_WRITE} ed
1800 \param{fd} non è aperto in lettura/scrittura, o si è impostato
1801 \const{PROT\_WRITE} ed \param{fd} è in \textit{append-only}.
1802 \item[\errcode{EINVAL}] I valori di \param{start}, \param{length} o
1803 \param{offset} non sono validi (o troppo grandi o non allineati sulla
1804 dimensione delle pagine).
1805 \item[\errcode{ETXTBSY}] Si è impostato \const{MAP\_DENYWRITE} ma
1806 \param{fd} è aperto in scrittura.
1807 \item[\errcode{EAGAIN}] Il file è bloccato, o si è bloccata troppa memoria
1808 rispetto a quanto consentito dai limiti di sistema (vedi
1809 sez.~\ref{sec:sys_resource_limit}).
1810 \item[\errcode{ENOMEM}] Non c'è memoria o si è superato il limite sul
1811 numero di mappature possibili.
1812 \item[\errcode{ENODEV}] Il filesystem di \param{fd} non supporta il memory
1814 \item[\errcode{EPERM}] L'argomento \param{prot} ha richiesto
1815 \const{PROT\_EXEC}, ma il filesystem di \param{fd} è montato con
1816 l'opzione \texttt{noexec}.
1817 \item[\errcode{ENFILE}] Si è superato il limite del sistema sul numero di
1818 file aperti (vedi sez.~\ref{sec:sys_resource_limit}).
1823 La funzione richiede di mappare in memoria la sezione del file \param{fd} a
1824 partire da \param{offset} per \param{lenght} byte, preferibilmente
1825 all'indirizzo \param{start}. Il valore di \param{offset} deve essere un
1826 multiplo della dimensione di una pagina di memoria.
1832 \begin{tabular}[c]{|l|l|}
1834 \textbf{Valore} & \textbf{Significato} \\
1837 \const{PROT\_EXEC} & Le pagine possono essere eseguite.\\
1838 \const{PROT\_READ} & Le pagine possono essere lette.\\
1839 \const{PROT\_WRITE} & Le pagine possono essere scritte.\\
1840 \const{PROT\_NONE} & L'accesso alle pagine è vietato.\\
1843 \caption{Valori dell'argomento \param{prot} di \func{mmap}, relativi alla
1844 protezione applicate alle pagine del file mappate in memoria.}
1845 \label{tab:file_mmap_prot}
1849 Il valore dell'argomento \param{prot} indica la protezione\footnote{in Linux
1850 la memoria reale è divisa in pagine: ogni processo vede la sua memoria
1851 attraverso uno o più segmenti lineari di memoria virtuale. Per ciascuno di
1852 questi segmenti il kernel mantiene nella \itindex{page~table} \textit{page
1853 table} la mappatura sulle pagine di memoria reale, ed le modalità di
1854 accesso (lettura, esecuzione, scrittura); una loro violazione causa quella
1855 che si chiama una \textit{segment violation}, e la relativa emissione del
1856 segnale \const{SIGSEGV}.} da applicare al segmento di memoria e deve essere
1857 specificato come maschera binaria ottenuta dall'OR di uno o più dei valori
1858 riportati in tab.~\ref{tab:file_mmap_flag}; il valore specificato deve essere
1859 compatibile con la modalità di accesso con cui si è aperto il file.
1861 L'argomento \param{flags} specifica infine qual è il tipo di oggetto mappato,
1862 le opzioni relative alle modalità con cui è effettuata la mappatura e alle
1863 modalità con cui le modifiche alla memoria mappata vengono condivise o
1864 mantenute private al processo che le ha effettuate. Deve essere specificato
1865 come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in
1866 tab.~\ref{tab:file_mmap_flag}.
1871 \begin{tabular}[c]{|l|p{11cm}|}
1873 \textbf{Valore} & \textbf{Significato} \\
1876 \const{MAP\_FIXED} & Non permette di restituire un indirizzo diverso
1877 da \param{start}, se questo non può essere usato
1878 \func{mmap} fallisce. Se si imposta questo flag il
1879 valore di \param{start} deve essere allineato
1880 alle dimensioni di una pagina. \\
1881 \const{MAP\_SHARED} & I cambiamenti sulla memoria mappata vengono
1882 riportati sul file e saranno immediatamente
1883 visibili agli altri processi che mappano lo stesso
1884 file.\footnotemark Il file su disco però non sarà
1885 aggiornato fino alla chiamata di \func{msync} o
1886 \func{munmap}), e solo allora le modifiche saranno
1887 visibili per l'I/O convenzionale. Incompatibile
1888 con \const{MAP\_PRIVATE}. \\
1889 \const{MAP\_PRIVATE} & I cambiamenti sulla memoria mappata non vengono
1890 riportati sul file. Ne viene fatta una copia
1891 privata cui solo il processo chiamante ha
1892 accesso. Le modifiche sono mantenute attraverso
1893 il meccanismo del \textit{copy on
1894 write} \itindex{copy~on~write} e
1895 salvate su swap in caso di necessità. Non è
1896 specificato se i cambiamenti sul file originale
1897 vengano riportati sulla regione
1898 mappata. Incompatibile con \const{MAP\_SHARED}. \\
1899 \const{MAP\_DENYWRITE} & In Linux viene ignorato per evitare
1900 \textit{DoS} \itindex{Denial~of~Service~(DoS)}
1901 (veniva usato per segnalare che tentativi di
1902 scrittura sul file dovevano fallire con
1903 \errcode{ETXTBSY}).\\
1904 \const{MAP\_EXECUTABLE}& Ignorato. \\
1905 \const{MAP\_NORESERVE} & Si usa con \const{MAP\_PRIVATE}. Non riserva
1906 delle pagine di swap ad uso del meccanismo del
1907 \textit{copy on write} \itindex{copy~on~write}
1909 modifiche fatte alla regione mappata, in
1910 questo caso dopo una scrittura, se non c'è più
1911 memoria disponibile, si ha l'emissione di
1912 un \const{SIGSEGV}. \\
1913 \const{MAP\_LOCKED} & Se impostato impedisce lo swapping delle pagine
1915 \const{MAP\_GROWSDOWN} & Usato per gli \itindex{stack} stack. Indica
1916 che la mappatura deve essere effettuata con gli
1917 indirizzi crescenti verso il basso.\\
1918 \const{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
1919 argomenti \param{fd} e \param{offset} sono
1920 ignorati.\footnotemark\\
1921 \const{MAP\_ANON} & Sinonimo di \const{MAP\_ANONYMOUS}, deprecato.\\
1922 \const{MAP\_FILE} & Valore di compatibilità, ignorato.\\
1923 \const{MAP\_32BIT} & Esegue la mappatura sui primi 2GiB dello spazio
1924 degli indirizzi, viene supportato solo sulle
1925 piattaforme \texttt{x86-64} per compatibilità con
1926 le applicazioni a 32 bit. Viene ignorato se si è
1927 richiesto \const{MAP\_FIXED}.\\
1928 \const{MAP\_POPULATE} & Esegue il \itindex{prefaulting}
1929 \textit{prefaulting} delle pagine di memoria
1930 necessarie alla mappatura. \\
1931 \const{MAP\_NONBLOCK} & Esegue un \textit{prefaulting} più limitato che
1932 non causa I/O.\footnotemark \\
1933 % \const{MAP\_DONTEXPAND}& Non consente una successiva espansione dell'area
1934 % mappata con \func{mremap}, proposto ma pare non
1938 \caption{Valori possibili dell'argomento \param{flag} di \func{mmap}.}
1939 \label{tab:file_mmap_flag}
1943 Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere
1944 piuttosto complessi, essi si possono comprendere solo tenendo presente che
1945 tutto quanto è comunque basato sul meccanismo della \index{memoria~virtuale}
1946 memoria virtuale. Questo comporta allora una serie di conseguenze. La più
1947 ovvia è che se si cerca di scrivere su una zona mappata in sola lettura si
1948 avrà l'emissione di un segnale di violazione di accesso (\const{SIGSEGV}),
1949 dato che i permessi sul segmento di memoria relativo non consentono questo
1952 È invece assai diversa la questione relativa agli accessi al di fuori della
1953 regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe
1954 ritenere che anch'essi debbano generare un segnale di violazione di accesso;
1955 questo però non tiene conto del fatto che, essendo basata sul meccanismo della
1956 paginazione \index{paginazione}, la mappatura in memoria non può che essere
1957 eseguita su un segmento di dimensioni rigorosamente multiple di quelle di una
1958 pagina, ed in generale queste potranno non corrispondere alle dimensioni
1959 effettive del file o della sezione che si vuole mappare.
1961 \footnotetext[20]{Dato che tutti faranno riferimento alle stesse pagine di
1964 \footnotetext[21]{L'uso di questo flag con \const{MAP\_SHARED} è stato
1965 implementato in Linux a partire dai kernel della serie 2.4.x; esso consente
1966 di creare segmenti di memoria condivisa e torneremo sul suo utilizzo in
1967 sez.~\ref{sec:ipc_mmap_anonymous}.}
1969 \footnotetext{questo flag ed il precedente \const{MAP\_POPULATE} sono stati
1970 introdotti nel kernel 2.5.46 insieme alla mappatura non lineare di cui
1971 parleremo più avanti.}
1973 \begin{figure}[!htb]
1975 \includegraphics[width=12cm]{img/mmap_boundary}
1976 \caption{Schema della mappatura in memoria di una sezione di file di
1977 dimensioni non corrispondenti al bordo di una pagina.}
1978 \label{fig:file_mmap_boundary}
1982 Il caso più comune è quello illustrato in fig.~\ref{fig:file_mmap_boundary},
1983 in cui la sezione di file non rientra nei confini di una pagina: in tal caso
1984 verrà il file sarà mappato su un segmento di memoria che si estende fino al
1985 bordo della pagina successiva.
1987 In questo caso è possibile accedere a quella zona di memoria che eccede le
1988 dimensioni specificate da \param{lenght}, senza ottenere un \const{SIGSEGV}
1989 poiché essa è presente nello spazio di indirizzi del processo, anche se non è
1990 mappata sul file. Il comportamento del sistema è quello di restituire un
1991 valore nullo per quanto viene letto, e di non riportare su file quanto viene
1994 Un caso più complesso è quello che si viene a creare quando le dimensioni del
1995 file mappato sono più corte delle dimensioni della mappatura, oppure quando il
1996 file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a
1997 quella della mappatura in memoria.
1999 In questa situazione, per la sezione di pagina parzialmente coperta dal
2000 contenuto del file, vale esattamente quanto visto in precedenza; invece per la
2001 parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non
2002 sarà più possibile, ma il segnale emesso non sarà \const{SIGSEGV}, ma
2003 \const{SIGBUS}, come illustrato in fig.~\ref{fig:file_mmap_exceed}.
2005 Non tutti i file possono venire mappati in memoria, dato che, come illustrato
2006 in fig.~\ref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza
2007 biunivoca fra una sezione di un file ed una sezione di memoria. Questo
2008 comporta che ad esempio non è possibile mappare in memoria file descriptor
2009 relativi a pipe, socket e fifo, per i quali non ha senso parlare di
2010 \textsl{sezione}. Lo stesso vale anche per alcuni file di dispositivo, che non
2011 dispongono della relativa operazione \func{mmap} (si ricordi quanto esposto in
2012 sez.~\ref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi
2013 di dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe)
2014 che sono utilizzabili solo con questa interfaccia.
2018 \includegraphics[width=12cm]{img/mmap_exceed}
2019 \caption{Schema della mappatura in memoria di file di dimensioni inferiori
2020 alla lunghezza richiesta.}
2021 \label{fig:file_mmap_exceed}
2024 Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene
2025 copiato integralmente, i file mappati in memoria verranno ereditati in maniera
2026 trasparente dal processo figlio, mantenendo gli stessi attributi avuti nel
2027 padre; così se si è usato \const{MAP\_SHARED} padre e figlio accederanno allo
2028 stesso file in maniera condivisa, mentre se si è usato \const{MAP\_PRIVATE}
2029 ciascuno di essi manterrà una sua versione privata indipendente. Non c'è
2030 invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima
2031 sostituisce tutto lo spazio degli indirizzi di un processo con quello di un
2034 Quando si effettua la mappatura di un file vengono pure modificati i tempi ad
2035 esso associati (di cui si è trattato in sez.~\ref{sec:file_file_times}). Il
2036 valore di \var{st\_atime} può venir cambiato in qualunque istante a partire
2037 dal momento in cui la mappatura è stata effettuata: il primo riferimento ad
2038 una pagina mappata su un file aggiorna questo tempo. I valori di
2039 \var{st\_ctime} e \var{st\_mtime} possono venir cambiati solo quando si è
2040 consentita la scrittura sul file (cioè per un file mappato con
2041 \const{PROT\_WRITE} e \const{MAP\_SHARED}) e sono aggiornati dopo la scrittura
2042 o in corrispondenza di una eventuale \func{msync}.
2044 Dato per i file mappati in memoria le operazioni di I/O sono gestite
2045 direttamente dalla \index{memoria~virtuale}memoria virtuale, occorre essere
2046 consapevoli delle interazioni che possono esserci con operazioni effettuate
2047 con l'interfaccia standard dei file di cap.~\ref{cha:file_unix_interface}. Il
2048 problema è che una volta che si è mappato un file, le operazioni di lettura e
2049 scrittura saranno eseguite sulla memoria, e riportate su disco in maniera
2050 autonoma dal sistema della memoria virtuale.
2052 Pertanto se si modifica un file con l'interfaccia standard queste modifiche
2053 potranno essere visibili o meno a seconda del momento in cui la memoria
2054 virtuale trasporterà dal disco in memoria quella sezione del file, perciò è
2055 del tutto imprevedibile il risultato della modifica di un file nei confronti
2056 del contenuto della memoria su cui è mappato.
2058 Per questo, è sempre sconsigliabile eseguire scritture su file attraverso
2059 l'interfaccia standard, quando lo si è mappato in memoria, è invece possibile
2060 usare l'interfaccia standard per leggere un file mappato in memoria, purché si
2061 abbia una certa cura; infatti l'interfaccia dell'I/O mappato in memoria mette
2062 a disposizione la funzione \funcd{msync} per sincronizzare il contenuto della
2063 memoria mappata con il file su disco; il suo prototipo è:
2066 \headdecl{sys/mman.h}
2068 \funcdecl{int msync(const void *start, size\_t length, int flags)}
2070 Sincronizza i contenuti di una sezione di un file mappato in memoria.
2072 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2073 errore nel qual caso \var{errno} assumerà uno dei valori:
2075 \item[\errcode{EINVAL}] O \param{start} non è multiplo di
2076 \const{PAGE\_SIZE}, o si è specificato un valore non valido per
2078 \item[\errcode{EFAULT}] L'intervallo specificato non ricade in una zona
2079 precedentemente mappata.
2084 La funzione esegue la sincronizzazione di quanto scritto nella sezione di
2085 memoria indicata da \param{start} e \param{offset}, scrivendo le modifiche sul
2086 file (qualora questo non sia già stato fatto). Provvede anche ad aggiornare i
2087 relativi tempi di modifica. In questo modo si è sicuri che dopo l'esecuzione
2088 di \func{msync} le funzioni dell'interfaccia standard troveranno un contenuto
2089 del file aggiornato.
2094 \begin{tabular}[c]{|l|l|}
2096 \textbf{Valore} & \textbf{Significato} \\
2099 \const{MS\_ASYNC} & Richiede la sincronizzazione.\\
2100 \const{MS\_SYNC} & Attende che la sincronizzazione si eseguita.\\
2101 \const{MS\_INVALIDATE}& Richiede che le altre mappature dello stesso file
2105 \caption{Valori dell'argomento \param{flag} di \func{msync}.}
2106 \label{tab:file_mmap_rsync}
2109 L'argomento \param{flag} è specificato come maschera binaria composta da un OR
2110 dei valori riportati in tab.~\ref{tab:file_mmap_rsync}, di questi però
2111 \const{MS\_ASYNC} e \const{MS\_SYNC} sono incompatibili; con il primo valore
2112 infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al
2113 meccanismo della memoria virtuale, ritornando subito, mentre con il secondo
2114 attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo
2115 flag fa invalidare le pagine di cui si richiede la sincronizzazione per tutte
2116 le mappature dello stesso file, così che esse possano essere immediatamente
2117 aggiornate ai nuovi valori.
2119 Una volta che si sono completate le operazioni di I/O si può eliminare la
2120 mappatura della memoria usando la funzione \funcd{munmap}, il suo prototipo è:
2123 \headdecl{sys/mman.h}
2125 \funcdecl{int munmap(void *start, size\_t length)}
2127 Rilascia la mappatura sulla sezione di memoria specificata.
2129 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2130 errore nel qual caso \var{errno} assumerà uno dei valori:
2132 \item[\errcode{EINVAL}] L'intervallo specificato non ricade in una zona
2133 precedentemente mappata.
2138 La funzione cancella la mappatura per l'intervallo specificato con
2139 \param{start} e \param{length}; ogni successivo accesso a tale regione causerà
2140 un errore di accesso in memoria. L'argomento \param{start} deve essere
2141 allineato alle dimensioni di una pagina, e la mappatura di tutte le pagine
2142 contenute anche parzialmente nell'intervallo indicato, verrà rimossa.
2143 Indicare un intervallo che non contiene mappature non è un errore. Si tenga
2144 presente inoltre che alla conclusione di un processo ogni pagina mappata verrà
2145 automaticamente rilasciata, mentre la chiusura del file descriptor usato per
2146 il \textit{memory mapping} non ha alcun effetto su di esso.
2148 Lo standard POSIX prevede anche una funzione che permetta di cambiare le
2149 protezioni delle pagine di memoria; lo standard prevede che essa si applichi
2150 solo ai \textit{memory mapping} creati con \func{mmap}, ma nel caso di Linux
2151 la funzione può essere usata con qualunque pagina valida nella memoria
2152 virtuale. Questa funzione è \funcd{mprotect} ed il suo prototipo è:
2154 % \headdecl{unistd.h}
2155 \headdecl{sys/mman.h}
2157 \funcdecl{int mprotect(const void *addr, size\_t len, int prot)}
2159 Modifica le protezioni delle pagine di memoria comprese nell'intervallo
2162 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2163 errore nel qual caso \var{errno} assumerà uno dei valori:
2165 \item[\errcode{EINVAL}] il valore di \param{addr} non è valido o non è un
2166 multiplo di \const{PAGE\_SIZE}.
2167 \item[\errcode{EACCESS}] l'operazione non è consentita, ad esempio si è
2168 cercato di marcare con \const{PROT\_WRITE} un segmento di memoria cui si
2169 ha solo accesso in lettura.
2170 % \item[\errcode{ENOMEM}] non è stato possibile allocare le risorse
2171 % necessarie all'interno del kernel.
2172 % \item[\errcode{EFAULT}] si è specificato un indirizzo di memoria non
2175 ed inoltre \errval{ENOMEM} ed \errval{EFAULT}.
2180 La funzione prende come argomenti un indirizzo di partenza in \param{addr},
2181 allineato alle dimensioni delle pagine di memoria, ed una dimensione
2182 \param{size}. La nuova protezione deve essere specificata in \param{prot} con
2183 una combinazione dei valori di tab.~\ref{tab:file_mmap_prot}. La nuova
2184 protezione verrà applicata a tutte le pagine contenute, anche parzialmente,
2185 dall'intervallo fra \param{addr} e \param{addr}+\param{size}-1.
2187 Infine Linux supporta alcune operazioni specifiche non disponibili su altri
2188 kernel unix-like. La prima di queste è la possibilità di modificare un
2189 precedente \textit{memory mapping}, ad esempio per espanderlo o restringerlo.
2190 Questo è realizzato dalla funzione \funcd{mremap}, il cui prototipo è:
2193 \headdecl{sys/mman.h}
2195 \funcdecl{void * mremap(void *old\_address, size\_t old\_size , size\_t
2196 new\_size, unsigned long flags)}
2198 Restringe o allarga una mappatura in memoria di un file.
2200 \bodydesc{La funzione restituisce l'indirizzo alla nuova area di memoria in
2201 caso di successo od il valore \const{MAP\_FAILED} (pari a \texttt{(void *)
2202 -1}) in caso di errore, nel qual caso \var{errno} assumerà uno dei
2205 \item[\errcode{EINVAL}] il valore di \param{old\_address} non è un
2207 \item[\errcode{EFAULT}] ci sono indirizzi non validi nell'intervallo
2208 specificato da \param{old\_address} e \param{old\_size}, o ci sono altre
2209 mappature di tipo non corrispondente a quella richiesta.
2210 \item[\errcode{ENOMEM}] non c'è memoria sufficiente oppure l'area di
2211 memoria non può essere espansa all'indirizzo virtuale corrente, e non si
2212 è specificato \const{MREMAP\_MAYMOVE} nei flag.
2213 \item[\errcode{EAGAIN}] il segmento di memoria scelto è bloccato e non può
2219 La funzione richiede come argomenti \param{old\_address} (che deve essere
2220 allineato alle dimensioni di una pagina di memoria) che specifica il
2221 precedente indirizzo del \textit{memory mapping} e \param{old\_size}, che ne
2222 indica la dimensione. Con \param{new\_size} si specifica invece la nuova
2223 dimensione che si vuole ottenere. Infine l'argomento \param{flags} è una
2224 maschera binaria per i flag che controllano il comportamento della funzione.
2225 Il solo valore utilizzato è \const{MREMAP\_MAYMOVE}\footnote{per poter
2226 utilizzare questa costante occorre aver definito \macro{\_GNU\_SOURCE} prima
2227 di includere \file{sys/mman.h}.} che consente di eseguire l'espansione
2228 anche quando non è possibile utilizzare il precedente indirizzo. Per questo
2229 motivo, se si è usato questo flag, la funzione può restituire un indirizzo
2230 della nuova zona di memoria che non è detto coincida con \param{old\_address}.
2232 La funzione si appoggia al sistema della \index{memoria~virtuale} memoria
2233 virtuale per modificare l'associazione fra gli indirizzi virtuali del processo
2234 e le pagine di memoria, modificando i dati direttamente nella
2235 \itindex{page~table} \textit{page table} del processo. Come per
2236 \func{mprotect} la funzione può essere usata in generale, anche per pagine di
2237 memoria non corrispondenti ad un \textit{memory mapping}, e consente così di
2238 implementare la funzione \func{realloc} in maniera molto efficiente.
2240 Una caratteristica comune a tutti i sistemi unix-like è che la mappatura in
2241 memoria di un file viene eseguita in maniera lineare, cioè parti successive di
2242 un file vengono mappate linearmente su indirizzi successivi in memoria.
2243 Esistono però delle applicazioni\footnote{in particolare la tecnica è usata
2244 dai database o dai programmi che realizzano macchine virtuali.} in cui è
2245 utile poter mappare sezioni diverse di un file su diverse zone di memoria.
2247 Questo è ovviamente sempre possibile eseguendo ripetutamente la funzione
2248 \func{mmap} per ciascuna delle diverse aree del file che si vogliono mappare
2249 in sequenza non lineare,\footnote{ed in effetti è quello che veniva fatto
2250 anche con Linux prima che fossero introdotte queste estensioni.} ma questo
2251 approccio ha delle conseguenze molto pesanti in termini di prestazioni.
2252 Infatti per ciascuna mappatura in memoria deve essere definita nella
2253 \itindex{page~table} \textit{page table} del processo una nuova area di
2254 memoria virtuale\footnote{quella che nel gergo del kernel viene chiamata VMA
2255 (\textit{virtual memory area}).} che corrisponda alla mappatura, in modo che
2256 questa diventi visibile nello spazio degli indirizzi come illustrato in
2257 fig.~\ref{fig:file_mmap_layout}.
2259 Quando un processo esegue un gran numero di mappature diverse\footnote{si può
2260 arrivare anche a centinaia di migliaia.} per realizzare a mano una mappatura
2261 non-lineare si avrà un accrescimento eccessivo della sua \itindex{page~table}
2262 \textit{page table}, e lo stesso accadrà per tutti gli altri processi che
2263 utilizzano questa tecnica. In situazioni in cui le applicazioni hanno queste
2264 esigenze si avranno delle prestazioni ridotte, dato che il kernel dovrà
2265 impiegare molte risorse\footnote{sia in termini di memoria interna per i dati
2266 delle \itindex{page~table} \textit{page table}, che di CPU per il loro
2267 aggiornamento.} solo per mantenere i dati di una gran quantità di
2268 \textit{memory mapping}.
2270 Per questo motivo con il kernel 2.5.46 è stato introdotto, ad opera di Ingo
2271 Molnar, un meccanismo che consente la mappatura non-lineare. Anche questa è
2272 una caratteristica specifica di Linux, non presente in altri sistemi
2273 unix-like. Diventa così possibile utilizzare una sola mappatura
2274 iniziale\footnote{e quindi una sola \textit{virtual memory area} nella
2275 \itindex{page~table} \textit{page table} del processo.} e poi rimappare a
2276 piacere all'interno di questa i dati del file. Ciò è possibile grazie ad una
2277 nuova system call, \funcd{remap\_file\_pages}, il cui prototipo è:
2279 \headdecl{sys/mman.h}
2281 \funcdecl{int remap\_file\_pages(void *start, size\_t size, int prot,
2282 ssize\_t pgoff, int flags)}
2284 Permette di rimappare non linearmente un precedente \textit{memory mapping}.
2286 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2287 errore, nel qual caso \var{errno} assumerà uno dei valori:
2289 \item[\errcode{EINVAL}] Si è usato un valore non valido per uno degli
2290 argomenti o \param{start} non fa riferimento ad un \textit{memory
2291 mapping} valido creato con \const{MAP\_SHARED}.
2296 Per poter utilizzare questa funzione occorre anzitutto effettuare
2297 preliminarmente una chiamata a \func{mmap} con \const{MAP\_SHARED} per
2298 definire l'area di memoria che poi sarà rimappata non linearmente. Poi di
2299 chiamerà questa funzione per modificare le corrispondenze fra pagine di
2300 memoria e pagine del file; si tenga presente che \func{remap\_file\_pages}
2301 permette anche di mappare la stessa pagina di un file in più pagine della
2304 La funzione richiede che si identifichi la sezione del file che si vuole
2305 riposizionare all'interno del \textit{memory mapping} con gli argomenti
2306 \param{pgoff} e \param{size}; l'argomento \param{start} invece deve indicare
2307 un indirizzo all'interno dell'area definita dall'\func{mmap} iniziale, a
2308 partire dal quale la sezione di file indicata verrà rimappata. L'argomento
2309 \param{prot} deve essere sempre nullo, mentre \param{flags} prende gli stessi
2310 valori di \func{mmap} (quelli di tab.~\ref{tab:file_mmap_prot}) ma di tutti i
2311 flag solo \const{MAP\_NONBLOCK} non viene ignorato.
2313 Insieme alla funzione \func{remap\_file\_pages} nel kernel 2.5.46 con sono
2314 stati introdotti anche due nuovi flag per \func{mmap}: \const{MAP\_POPULATE} e
2315 \const{MAP\_NONBLOCK}. Il primo dei due consente di abilitare il meccanismo
2316 del \itindex{prefaulting} \textit{prefaulting}. Questo viene di nuovo in aiuto
2317 per migliorare le prestazioni in certe condizioni di utilizzo del
2318 \textit{memory mapping}.
2320 Il problema si pone tutte le volte che si vuole mappare in memoria un file di
2321 grosse dimensioni. Il comportamento normale del sistema della
2322 \index{memoria~virtuale} memoria virtuale è quello per cui la regione mappata
2323 viene aggiunta alla \itindex{page~table} \textit{page table} del processo, ma
2324 i dati verranno effettivamente utilizzati (si avrà cioè un
2325 \itindex{page~fault} \textit{page fault} che li trasferisce dal disco alla
2326 memoria) soltanto in corrispondenza dell'accesso a ciascuna delle pagine
2327 interessate dal \textit{memory mapping}.
2329 Questo vuol dire che il passaggio dei dati dal disco alla memoria avverrà una
2330 pagina alla volta con un gran numero di \itindex{page~fault} \textit{page
2331 fault}, chiaramente se si sa in anticipo che il file verrà utilizzato
2332 immediatamente, è molto più efficiente eseguire un \itindex{prefaulting}
2333 \textit{prefaulting} in cui tutte le pagine di memoria interessate alla
2334 mappatura vengono ``\textsl{popolate}'' in una sola volta, questo
2335 comportamento viene abilitato quando si usa con \func{mmap} il flag
2336 \const{MAP\_POPULATE}.
2338 Dato che l'uso di \const{MAP\_POPULATE} comporta dell'I/O su disco che può
2339 rallentare l'esecuzione di \func{mmap} è stato introdotto anche un secondo
2340 flag, \const{MAP\_NONBLOCK}, che esegue un \itindex{prefaulting}
2341 \textit{prefaulting} più limitato in cui vengono popolate solo le pagine della
2342 mappatura che già si trovano nella cache del kernel.\footnote{questo può
2343 essere utile per il linker dinamico, in particolare quando viene effettuato
2344 il \textit{prelink} delle applicazioni.}
2346 \itindend{memory~mapping}
2349 \subsection{L'I/O diretto fra file descriptor}
2350 \label{sec:file_sendfile_splice}
2354 NdA è da finire, sul perché non è abilitata fra file vedi:
2356 \href{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}
2357 {\texttt{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}}
2359 % TODO documentare la funzione sendfile
2360 % TODO documentare le funzioni tee e splice
2361 % http://kerneltrap.org/node/6505 e http://lwn.net/Articles/178199/ e
2362 % http://lwn.net/Articles/179492/
2363 % e http://en.wikipedia.org/wiki/Splice_(system_call)
2366 %\subsection{L'utilizzo delle porte di I/O}
2367 %\label{sec:file_io_port}
2369 % TODO l'I/O sulle porte di I/O
2370 % consultare le manpage di ioperm, iopl e outb
2375 \section{Il file locking}
2376 \label{sec:file_locking}
2378 \index{file!locking|(}
2380 In sez.~\ref{sec:file_sharing} abbiamo preso in esame le modalità in cui un
2381 sistema unix-like gestisce la condivisione dei file da parte di processi
2382 diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti
2383 in \itindex{append~mode} \textit{append mode}, quando più processi scrivono
2384 contemporaneamente sullo stesso file non è possibile determinare la sequenza
2385 in cui essi opereranno.
2387 Questo causa la possibilità di una \itindex{race~condition} \textit{race
2388 condition}; in generale le situazioni più comuni sono due: l'interazione fra
2389 un processo che scrive e altri che leggono, in cui questi ultimi possono
2390 leggere informazioni scritte solo in maniera parziale o incompleta; o quella
2391 in cui diversi processi scrivono, mescolando in maniera imprevedibile il loro
2394 In tutti questi casi il \textit{file locking} è la tecnica che permette di
2395 evitare le \textit{race condition} \itindex{race~condition}, attraverso una
2396 serie di funzioni che permettono di bloccare l'accesso al file da parte di
2397 altri processi, così da evitare le sovrapposizioni, e garantire la atomicità
2398 delle operazioni di scrittura.
2402 \subsection{L'\textit{advisory locking}}
2403 \label{sec:file_record_locking}
2405 La prima modalità di \textit{file locking} che è stata implementata nei
2406 sistemi unix-like è quella che viene usualmente chiamata \textit{advisory
2407 locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
2408 come al \textit{record locking}, dizione utilizzata anche dal manuale delle
2409 \acr{glibc}; nelle pagine di manuale si parla di \textit{discrectionary file
2410 lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
2411 mentre questo nome viene usato da Stevens per riferirsi al \textit{file
2412 locking} POSIX. Dato che la dizione \textit{record locking} è quantomeno
2413 ambigua, in quanto in un sistema Unix non esiste niente che possa fare
2414 riferimento al concetto di \textit{record}, alla fine si è scelto di
2415 mantenere il nome \textit{advisory locking}.} in quanto sono i singoli
2416 processi, e non il sistema, che si incaricano di asserire e verificare se
2417 esistono delle condizioni di blocco per l'accesso ai file. Questo significa
2418 che le funzioni \func{read} o \func{write} vengono eseguite comunque e non
2419 risentono affatto della presenza di un eventuale \textit{lock}; pertanto è
2420 sempre compito dei vari processi che intendono usare il file locking,
2421 controllare esplicitamente lo stato dei file condivisi prima di accedervi,
2422 utilizzando le relative funzioni.
2424 In generale si distinguono due tipologie di \textit{file lock}:\footnote{di
2425 seguito ci riferiremo sempre ai blocchi di accesso ai file con la
2426 nomenclatura inglese di \textit{file lock}, o più brevemente con
2427 \textit{lock}, per evitare confusioni linguistiche con il blocco di un
2428 processo (cioè la condizione in cui il processo viene posto in stato di
2429 \textit{sleep}).} la prima è il cosiddetto \textit{shared lock}, detto anche
2430 \textit{read lock} in quanto serve a bloccare l'accesso in scrittura su un
2431 file affinché il suo contenuto non venga modificato mentre lo si legge. Si
2432 parla appunto di \textsl{blocco condiviso} in quanto più processi possono
2433 richiedere contemporaneamente uno \textit{shared lock} su un file per
2434 proteggere il loro accesso in lettura.
2436 La seconda tipologia è il cosiddetto \textit{exclusive lock}, detto anche
2437 \textit{write lock} in quanto serve a bloccare l'accesso su un file (sia in
2438 lettura che in scrittura) da parte di altri processi mentre lo si sta
2439 scrivendo. Si parla di \textsl{blocco esclusivo} appunto perché un solo
2440 processo alla volta può richiedere un \textit{exclusive lock} su un file per
2441 proteggere il suo accesso in scrittura.
2446 \begin{tabular}[c]{|l|c|c|c|}
2448 \textbf{Richiesta} & \multicolumn{3}{|c|}{\textbf{Stato del file}}\\
2450 &Nessun lock&\textit{Read lock}&\textit{Write lock}\\
2453 \textit{Read lock} & SI & SI & NO \\
2454 \textit{Write lock}& SI & NO & NO \\
2457 \caption{Tipologie di file locking.}
2458 \label{tab:file_file_lock}
2461 In Linux sono disponibili due interfacce per utilizzare l'\textit{advisory
2462 locking}, la prima è quella derivata da BSD, che è basata sulla funzione
2463 \func{flock}, la seconda è quella standardizzata da POSIX.1 (derivata da
2464 System V), che è basata sulla funzione \func{fcntl}. I \textit{file lock}
2465 sono implementati in maniera completamente indipendente nelle due interfacce,
2466 che pertanto possono coesistere senza interferenze.
2468 Entrambe le interfacce prevedono la stessa procedura di funzionamento: si
2469 inizia sempre con il richiedere l'opportuno \textit{file lock} (un
2470 \textit{exclusive lock} per una scrittura, uno \textit{shared lock} per una
2471 lettura) prima di eseguire l'accesso ad un file. Se il lock viene acquisito
2472 il processo prosegue l'esecuzione, altrimenti (a meno di non aver richiesto un
2473 comportamento non bloccante) viene posto in stato di sleep. Una volta finite
2474 le operazioni sul file si deve provvedere a rimuovere il lock. La situazione
2475 delle varie possibilità è riassunta in tab.~\ref{tab:file_file_lock}, dove si
2476 sono riportati, per le varie tipologie di lock presenti su un file, il
2477 risultato che si ha in corrispondenza alle due tipologie di \textit{file lock}
2478 menzionate, nel successo della richiesta.
2480 Si tenga presente infine che il controllo di accesso e la gestione dei
2481 permessi viene effettuata quando si apre un file, l'unico controllo residuo
2482 che si può avere riguardo il \textit{file locking} è che il tipo di lock che
2483 si vuole ottenere su un file deve essere compatibile con le modalità di
2484 apertura dello stesso (in lettura per un read lock e in scrittura per un write
2488 %% la condizione per acquisire uno \textit{shared lock} è che il file non abbia
2489 %% già un \textit{exclusive lock} attivo, mentre per acquisire un
2490 %% \textit{exclusive lock} non deve essere presente nessun tipo di blocco.
2493 \subsection{La funzione \func{flock}}
2494 \label{sec:file_flock}
2496 La prima interfaccia per il file locking, quella derivata da BSD, permette di
2497 eseguire un blocco solo su un intero file; la funzione usata per richiedere e
2498 rimuovere un \textit{file lock} è \funcd{flock}, ed il suo prototipo è:
2499 \begin{prototype}{sys/file.h}{int flock(int fd, int operation)}
2501 Applica o rimuove un \textit{file lock} sul file \param{fd}.
2503 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2504 errore, nel qual caso \var{errno} assumerà uno dei valori:
2506 \item[\errcode{EWOULDBLOCK}] Il file ha già un blocco attivo, e si è
2507 specificato \const{LOCK\_NB}.
2512 La funzione può essere usata per acquisire o rilasciare un \textit{file lock}
2513 a seconda di quanto specificato tramite il valore dell'argomento
2514 \param{operation}, questo viene interpretato come maschera binaria, e deve
2515 essere passato utilizzando le costanti riportate in
2516 tab.~\ref{tab:file_flock_operation}.
2521 \begin{tabular}[c]{|l|l|}
2523 \textbf{Valore} & \textbf{Significato} \\
2526 \const{LOCK\_SH} & Asserisce uno \textit{shared lock} sul file.\\
2527 \const{LOCK\_EX} & Asserisce un \textit{esclusive lock} sul file.\\
2528 \const{LOCK\_UN} & Rilascia il \textit{file lock}.\\
2529 \const{LOCK\_NB} & Impedisce che la funzione si blocchi nella
2530 richiesta di un \textit{file lock}.\\
2533 \caption{Valori dell'argomento \param{operation} di \func{flock}.}
2534 \label{tab:file_flock_operation}
2537 I primi due valori, \const{LOCK\_SH} e \const{LOCK\_EX} permettono di
2538 richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera
2539 alternativa. Se si specifica anche \const{LOCK\_NB} la funzione non si
2540 bloccherà qualora il lock non possa essere acquisito, ma ritornerà subito con
2541 un errore di \errcode{EWOULDBLOCK}. Per rilasciare un lock si dovrà invece
2542 usare \const{LOCK\_UN}.
2544 La semantica del file locking di BSD è diversa da quella del file locking
2545 POSIX, in particolare per quanto riguarda il comportamento dei lock nei
2546 confronti delle due funzioni \func{dup} e \func{fork}. Per capire queste
2547 differenze occorre descrivere con maggiore dettaglio come viene realizzato il
2548 file locking nel kernel in entrambe le interfacce.
2550 In fig.~\ref{fig:file_flock_struct} si è riportato uno schema essenziale
2551 dell'implementazione del file locking in stile BSD in Linux; il punto
2552 fondamentale da capire è che un lock, qualunque sia l'interfaccia che si usa,
2553 anche se richiesto attraverso un file descriptor, agisce sempre su un file;
2554 perciò le informazioni relative agli eventuali \textit{file lock} sono
2555 mantenute a livello di inode\index{inode},\footnote{in particolare, come
2556 accennato in fig.~\ref{fig:file_flock_struct}, i \textit{file lock} sono
2557 mantenuti in una \itindex{linked~list} \textit{linked list} di strutture
2558 \struct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
2559 mantenuto dal campo \var{i\_flock} della struttura \struct{inode} (per le
2560 definizioni esatte si faccia riferimento al file \file{fs.h} nei sorgenti
2561 del kernel). Un bit del campo \var{fl\_flags} di specifica se si tratta di
2562 un lock in semantica BSD (\const{FL\_FLOCK}) o POSIX (\const{FL\_POSIX}).}
2563 dato che questo è l'unico riferimento in comune che possono avere due processi
2564 diversi che aprono lo stesso file.
2568 \includegraphics[width=14cm]{img/file_flock}
2569 \caption{Schema dell'architettura del file locking, nel caso particolare
2570 del suo utilizzo da parte dalla funzione \func{flock}.}
2571 \label{fig:file_flock_struct}
2574 La richiesta di un file lock prevede una scansione della lista per determinare
2575 se l'acquisizione è possibile, ed in caso positivo l'aggiunta di un nuovo
2576 elemento.\footnote{cioè una nuova struttura \struct{file\_lock}.} Nel caso
2577 dei lock creati con \func{flock} la semantica della funzione prevede che sia
2578 \func{dup} che \func{fork} non creino ulteriori istanze di un file lock quanto
2579 piuttosto degli ulteriori riferimenti allo stesso. Questo viene realizzato dal
2580 kernel secondo lo schema di fig.~\ref{fig:file_flock_struct}, associando ad
2581 ogni nuovo \textit{file lock} un puntatore\footnote{il puntatore è mantenuto
2582 nel campo \var{fl\_file} di \struct{file\_lock}, e viene utilizzato solo per
2583 i lock creati con la semantica BSD.} alla voce nella \itindex{file~table}
2584 \textit{file table} da cui si è richiesto il lock, che così ne identifica il
2587 Questa struttura prevede che, quando si richiede la rimozione di un file lock,
2588 il kernel acconsenta solo se la richiesta proviene da un file descriptor che
2589 fa riferimento ad una voce nella \itindex{file~table} \textit{file table}
2590 corrispondente a quella registrata nel lock. Allora se ricordiamo quanto
2591 visto in sez.~\ref{sec:file_dup} e sez.~\ref{sec:file_sharing}, e cioè che i
2592 file descriptor duplicati e quelli ereditati in un processo figlio puntano
2593 sempre alla stessa voce nella \itindex{file~table} \textit{file table}, si può
2594 capire immediatamente quali sono le conseguenze nei confronti delle funzioni
2595 \func{dup} e \func{fork}.
2597 Sarà così possibile rimuovere un file lock attraverso uno qualunque dei file
2598 descriptor che fanno riferimento alla stessa voce nella \itindex{file~table}
2599 \textit{file table}, anche se questo è diverso da quello con cui lo si è
2600 creato,\footnote{attenzione, questo non vale se il file descriptor fa
2601 riferimento allo stesso file, ma attraverso una voce diversa della
2602 \itindex{file~table} \textit{file table}, come accade tutte le volte che si
2603 apre più volte lo stesso file.} o se si esegue la rimozione in un processo
2604 figlio; inoltre una volta tolto un file lock, la rimozione avrà effetto su
2605 tutti i file descriptor che condividono la stessa voce nella
2606 \itindex{file~table} \textit{file table}, e quindi, nel caso di file
2607 descriptor ereditati attraverso una \func{fork}, anche su processi diversi.
2609 Infine, per evitare che la terminazione imprevista di un processo lasci attivi
2610 dei file lock, quando un file viene chiuso il kernel provveda anche a
2611 rimuovere tutti i lock ad esso associati. Anche in questo caso occorre tenere
2612 presente cosa succede quando si hanno file descriptor duplicati; in tal caso
2613 infatti il file non verrà effettivamente chiuso (ed il lock rimosso) fintanto
2614 che non viene rilasciata la relativa voce nella \itindex{file~table}
2615 \textit{file table}; e questo avverrà solo quando tutti i file descriptor che
2616 fanno riferimento alla stessa voce sono stati chiusi. Quindi, nel caso ci
2617 siano duplicati o processi figli che mantengono ancora aperto un file
2618 descriptor, il lock non viene rilasciato.
2620 Si tenga presente infine che \func{flock} non è in grado di funzionare per i
2621 file mantenuti su NFS, in questo caso, se si ha la necessità di eseguire il
2622 \textit{file locking}, occorre usare l'interfaccia basata su \func{fcntl} che
2623 può funzionare anche attraverso NFS, a condizione che sia il client che il
2624 server supportino questa funzionalità.
2627 \subsection{Il file locking POSIX}
2628 \label{sec:file_posix_lock}
2630 La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
2631 quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo
2632 già trattato questa funzione nelle sue molteplici possibilità di utilizzo in
2633 sez.~\ref{sec:file_fcntl}. Quando la si impiega per il \textit{file locking}
2634 essa viene usata solo secondo il prototipo:
2635 \begin{prototype}{fcntl.h}{int fcntl(int fd, int cmd, struct flock *lock)}
2637 Applica o rimuove un \textit{file lock} sul file \param{fd}.
2639 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2640 errore, nel qual caso \var{errno} assumerà uno dei valori:
2642 \item[\errcode{EACCES}] L'operazione è proibita per la presenza di
2643 \textit{file lock} da parte di altri processi.
2644 \item[\errcode{ENOLCK}] Il sistema non ha le risorse per il locking: ci
2645 sono troppi segmenti di lock aperti, si è esaurita la tabella dei lock,
2646 o il protocollo per il locking remoto è fallito.
2647 \item[\errcode{EDEADLK}] Si è richiesto un lock su una regione bloccata da
2648 un altro processo che è a sua volta in attesa dello sblocco di un lock
2649 mantenuto dal processo corrente; si avrebbe pertanto un
2650 \itindex{deadlock} \textit{deadlock}. Non è garantito che il sistema
2651 riconosca sempre questa situazione.
2652 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale prima
2653 di poter acquisire un lock.
2655 ed inoltre \errval{EBADF}, \errval{EFAULT}.
2659 Al contrario di quanto avviene con l'interfaccia basata su \func{flock} con
2660 \func{fcntl} è possibile bloccare anche delle singole sezioni di un file, fino
2661 al singolo byte. Inoltre la funzione permette di ottenere alcune informazioni
2662 relative agli eventuali lock preesistenti. Per poter fare tutto questo la
2663 funzione utilizza come terzo argomento una apposita struttura \struct{flock}
2664 (la cui definizione è riportata in fig.~\ref{fig:struct_flock}) nella quale
2665 inserire tutti i dati relativi ad un determinato lock. Si tenga presente poi
2666 che un lock fa sempre riferimento ad una regione, per cui si potrà avere un
2667 conflitto anche se c'è soltanto una sovrapposizione parziale con un'altra
2670 \begin{figure}[!bht]
2671 \footnotesize \centering
2672 \begin{minipage}[c]{15cm}
2673 \includestruct{listati/flock.h}
2676 \caption{La struttura \structd{flock}, usata da \func{fcntl} per il file
2678 \label{fig:struct_flock}
2682 I primi tre campi della struttura, \var{l\_whence}, \var{l\_start} e
2683 \var{l\_len}, servono a specificare la sezione del file a cui fa riferimento
2684 il lock: \var{l\_start} specifica il byte di partenza, \var{l\_len} la
2685 lunghezza della sezione e infine \var{l\_whence} imposta il riferimento da cui
2686 contare \var{l\_start}. Il valore di \var{l\_whence} segue la stessa semantica
2687 dell'omonimo argomento di \func{lseek}, coi tre possibili valori
2688 \const{SEEK\_SET}, \const{SEEK\_CUR} e \const{SEEK\_END}, (si vedano le
2689 relative descrizioni in sez.~\ref{sec:file_lseek}).
2691 Si tenga presente che un lock può essere richiesto anche per una regione al di
2692 là della corrente fine del file, così che una eventuale estensione dello
2693 stesso resti coperta dal blocco. Inoltre se si specifica un valore nullo per
2694 \var{l\_len} il blocco si considera esteso fino alla dimensione massima del
2695 file; in questo modo è possibile bloccare una qualunque regione a partire da
2696 un certo punto fino alla fine del file, coprendo automaticamente quanto
2697 eventualmente aggiunto in coda allo stesso.
2702 \begin{tabular}[c]{|l|l|}
2704 \textbf{Valore} & \textbf{Significato} \\
2707 \const{F\_RDLCK} & Richiede un blocco condiviso (\textit{read lock}).\\
2708 \const{F\_WRLCK} & Richiede un blocco esclusivo (\textit{write lock}).\\
2709 \const{F\_UNLCK} & Richiede l'eliminazione di un file lock.\\
2712 \caption{Valori possibili per il campo \var{l\_type} di \struct{flock}.}
2713 \label{tab:file_flock_type}
2716 Il tipo di file lock richiesto viene specificato dal campo \var{l\_type}, esso
2717 può assumere i tre valori definiti dalle costanti riportate in
2718 tab.~\ref{tab:file_flock_type}, che permettono di richiedere rispettivamente
2719 uno \textit{shared lock}, un \textit{esclusive lock}, e la rimozione di un
2720 lock precedentemente acquisito. Infine il campo \var{l\_pid} viene usato solo
2721 in caso di lettura, quando si chiama \func{fcntl} con \const{F\_GETLK}, e
2722 riporta il \acr{pid} del processo che detiene il lock.
2724 Oltre a quanto richiesto tramite i campi di \struct{flock}, l'operazione
2725 effettivamente svolta dalla funzione è stabilita dal valore dall'argomento
2726 \param{cmd} che, come già riportato in sez.~\ref{sec:file_fcntl}, specifica
2727 l'azione da compiere; i valori relativi al file locking sono tre:
2728 \begin{basedescript}{\desclabelwidth{2.0cm}}
2729 \item[\const{F\_GETLK}] verifica se il file lock specificato dalla struttura
2730 puntata da \param{lock} può essere acquisito: in caso negativo sovrascrive
2731 la struttura \param{flock} con i valori relativi al lock già esistente che
2732 ne blocca l'acquisizione, altrimenti si limita a impostarne il campo
2733 \var{l\_type} con il valore \const{F\_UNLCK}.
2734 \item[\const{F\_SETLK}] se il campo \var{l\_type} della struttura puntata da
2735 \param{lock} è \const{F\_RDLCK} o \const{F\_WRLCK} richiede il
2736 corrispondente file lock, se è \const{F\_UNLCK} lo rilascia. Nel caso la
2737 richiesta non possa essere soddisfatta a causa di un lock preesistente la
2738 funzione ritorna immediatamente con un errore di \errcode{EACCES} o di
2740 \item[\const{F\_SETLKW}] è identica a \const{F\_SETLK}, ma se la richiesta di
2741 non può essere soddisfatta per la presenza di un altro lock, mette il
2742 processo in stato di attesa fintanto che il lock precedente non viene
2743 rilasciato. Se l'attesa viene interrotta da un segnale la funzione ritorna
2744 con un errore di \errcode{EINTR}.
2747 Si noti che per quanto detto il comando \const{F\_GETLK} non serve a rilevare
2748 una presenza generica di lock su un file, perché se ne esistono altri
2749 compatibili con quello richiesto, la funzione ritorna comunque impostando
2750 \var{l\_type} a \const{F\_UNLCK}. Inoltre a seconda del valore di
2751 \var{l\_type} si potrà controllare o l'esistenza di un qualunque tipo di lock
2752 (se è \const{F\_WRLCK}) o di write lock (se è \const{F\_RDLCK}). Si consideri
2753 poi che può esserci più di un lock che impedisce l'acquisizione di quello
2754 richiesto (basta che le regioni si sovrappongano), ma la funzione ne riporterà
2755 sempre soltanto uno, impostando \var{l\_whence} a \const{SEEK\_SET} ed i
2756 valori \var{l\_start} e \var{l\_len} per indicare quale è la regione bloccata.
2758 Infine si tenga presente che effettuare un controllo con il comando
2759 \const{F\_GETLK} e poi tentare l'acquisizione con \const{F\_SETLK} non è una
2760 operazione atomica (un altro processo potrebbe acquisire un lock fra le due
2761 chiamate) per cui si deve sempre verificare il codice di ritorno di
2762 \func{fcntl}\footnote{controllare il codice di ritorno delle funzioni invocate
2763 è comunque una buona norma di programmazione, che permette di evitare un
2764 sacco di errori difficili da tracciare proprio perché non vengono rilevati.}
2765 quando la si invoca con \const{F\_SETLK}, per controllare che il lock sia
2766 stato effettivamente acquisito.
2769 \centering \includegraphics[width=9cm]{img/file_lock_dead}
2770 \caption{Schema di una situazione di \itindex{deadlock} \textit{deadlock}.}
2771 \label{fig:file_flock_dead}
2774 Non operando a livello di interi file, il file locking POSIX introduce
2775 un'ulteriore complicazione; consideriamo la situazione illustrata in
2776 fig.~\ref{fig:file_flock_dead}, in cui il processo A blocca la regione 1 e il
2777 processo B la regione 2. Supponiamo che successivamente il processo A richieda
2778 un lock sulla regione 2 che non può essere acquisito per il preesistente lock
2779 del processo 2; il processo 1 si bloccherà fintanto che il processo 2 non
2780 rilasci il blocco. Ma cosa accade se il processo 2 nel frattempo tenta a sua
2781 volta di ottenere un lock sulla regione A? Questa è una tipica situazione che
2782 porta ad un \itindex{deadlock} \textit{deadlock}, dato che a quel punto anche
2783 il processo 2 si bloccherebbe, e niente potrebbe sbloccare l'altro processo.
2784 Per questo motivo il kernel si incarica di rilevare situazioni di questo tipo,
2785 ed impedirle restituendo un errore di \errcode{EDEADLK} alla funzione che
2786 cerca di acquisire un lock che porterebbe ad un \itindex{deadlock}
2789 \begin{figure}[!bht]
2790 \centering \includegraphics[width=13cm]{img/file_posix_lock}
2791 \caption{Schema dell'architettura del file locking, nel caso particolare
2792 del suo utilizzo secondo l'interfaccia standard POSIX.}
2793 \label{fig:file_posix_lock}
2797 Per capire meglio il funzionamento del file locking in semantica POSIX (che
2798 differisce alquanto rispetto da quello di BSD, visto
2799 sez.~\ref{sec:file_flock}) esaminiamo più in dettaglio come viene gestito dal
2800 kernel. Lo schema delle strutture utilizzate è riportato in
2801 fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
2802 di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si
2803 sono evidenziati solo i campi di \struct{file\_lock} significativi per la
2804 semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
2805 \acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene
2806 bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è
2807 comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
2808 impostato il bit \const{FL\_POSIX} ed il campo \var{fl\_file} non viene
2809 usato.} il lock è sempre associato \index{inode} all'inode, solo che in
2810 questo caso la titolarità non viene identificata con il riferimento ad una
2811 voce nella \itindex{file~table} \textit{file table}, ma con il valore del
2812 \acr{pid} del processo.
2814 Quando si richiede un lock il kernel effettua una scansione di tutti i lock
2815 presenti sul file\footnote{scandisce cioè la \itindex{linked~list}
2816 \textit{linked list} delle strutture \struct{file\_lock}, scartando
2817 automaticamente quelle per cui \var{fl\_flags} non è \const{FL\_POSIX}, così
2818 che le due interfacce restano ben separate.} per verificare se la regione
2819 richiesta non si sovrappone ad una già bloccata, in caso affermativo decide in
2820 base al tipo di lock, in caso negativo il nuovo lock viene comunque acquisito
2821 ed aggiunto alla lista.
2823 Nel caso di rimozione invece questa viene effettuata controllando che il
2824 \acr{pid} del processo richiedente corrisponda a quello contenuto nel lock.
2825 Questa diversa modalità ha delle conseguenze precise riguardo il comportamento
2826 dei lock POSIX. La prima conseguenza è che un lock POSIX non viene mai
2827 ereditato attraverso una \func{fork}, dato che il processo figlio avrà un
2828 \acr{pid} diverso, mentre passa indenne attraverso una \func{exec} in quanto
2829 il \acr{pid} resta lo stesso. Questo comporta che, al contrario di quanto
2830 avveniva con la semantica BSD, quando processo termina tutti i file lock da
2831 esso detenuti vengono immediatamente rilasciati.
2833 La seconda conseguenza è che qualunque file descriptor che faccia riferimento
2834 allo stesso file (che sia stato ottenuto con una \func{dup} o con una
2835 \func{open} in questo caso non fa differenza) può essere usato per rimuovere
2836 un lock, dato che quello che conta è solo il \acr{pid} del processo. Da questo
2837 deriva una ulteriore sottile differenza di comportamento: dato che alla
2838 chiusura di un file i lock ad esso associati vengono rimossi, nella semantica
2839 POSIX basterà chiudere un file descriptor qualunque per cancellare tutti i
2840 lock relativi al file cui esso faceva riferimento, anche se questi fossero
2841 stati creati usando altri file descriptor che restano aperti.
2843 Dato che il controllo sull'accesso ai lock viene eseguito sulla base del
2844 \acr{pid} del processo, possiamo anche prendere in considerazione un altro
2845 degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
2846 richiedono dei lock su regioni che si sovrappongono fra loro all'interno
2847 stesso processo. Siccome il controllo, come nel caso della rimozione, si basa
2848 solo sul \acr{pid} del processo che chiama la funzione, queste richieste
2849 avranno sempre successo.
2851 Nel caso della semantica BSD, essendo i lock relativi a tutto un file e non
2852 accumulandosi,\footnote{questa ultima caratteristica è vera in generale, se
2853 cioè si richiede più volte lo stesso file lock, o più lock sulla stessa
2854 sezione di file, le richieste non si cumulano e basta una sola richiesta di
2855 rilascio per cancellare il lock.} la cosa non ha alcun effetto; la funzione
2856 ritorna con successo, senza che il kernel debba modificare la lista dei lock.
2857 In questo caso invece si possono avere una serie di situazioni diverse: ad
2858 esempio è possibile rimuovere con una sola chiamata più lock distinti
2859 (indicando in una regione che si sovrapponga completamente a quelle di questi
2860 ultimi), o rimuovere solo una parte di un lock preesistente (indicando una
2861 regione contenuta in quella di un altro lock), creando un buco, o coprire con
2862 un nuovo lock altri lock già ottenuti, e così via, a secondo di come si
2863 sovrappongono le regioni richieste e del tipo di operazione richiesta. Il
2864 comportamento seguito in questo caso che la funzione ha successo ed esegue
2865 l'operazione richiesta sulla regione indicata; è compito del kernel
2866 preoccuparsi di accorpare o dividere le voci nella lista dei lock per far si
2867 che le regioni bloccate da essa risultanti siano coerenti con quanto
2868 necessario a soddisfare l'operazione richiesta.
2870 \begin{figure}[!htb]
2871 \footnotesize \centering
2872 \begin{minipage}[c]{15cm}
2873 \includecodesample{listati/Flock.c}
2876 \caption{Sezione principale del codice del programma \file{Flock.c}.}
2877 \label{fig:file_flock_code}
2880 Per fare qualche esempio sul file locking si è scritto un programma che
2881 permette di bloccare una sezione di un file usando la semantica POSIX, o un
2882 intero file usando la semantica BSD; in fig.~\ref{fig:file_flock_code} è
2883 riportata il corpo principale del codice del programma, (il testo completo è
2884 allegato nella directory dei sorgenti).
2886 La sezione relativa alla gestione delle opzioni al solito si è omessa, come la
2887 funzione che stampa le istruzioni per l'uso del programma, essa si cura di
2888 impostare le variabili \var{type}, \var{start} e \var{len}; queste ultime due
2889 vengono inizializzate al valore numerico fornito rispettivamente tramite gli
2890 switch \code{-s} e \cmd{-l}, mentre il valore della prima viene impostato con
2891 le opzioni \cmd{-w} e \cmd{-r} si richiede rispettivamente o un write lock o
2892 read lock (i due valori sono esclusivi, la variabile assumerà quello che si è
2893 specificato per ultimo). Oltre a queste tre vengono pure impostate la
2894 variabile \var{bsd}, che abilita la semantica omonima quando si invoca
2895 l'opzione \cmd{-f} (il valore preimpostato è nullo, ad indicare la semantica
2896 POSIX), e la variabile \var{cmd} che specifica la modalità di richiesta del
2897 lock (bloccante o meno), a seconda dell'opzione \cmd{-b}.
2899 Il programma inizia col controllare (\texttt{\small 11--14}) che venga passato
2900 un argomento (il file da bloccare), che sia stato scelto (\texttt{\small
2901 15--18}) il tipo di lock, dopo di che apre (\texttt{\small 19}) il file,
2902 uscendo (\texttt{\small 20--23}) in caso di errore. A questo punto il
2903 comportamento dipende dalla semantica scelta; nel caso sia BSD occorre
2904 reimpostare il valore di \var{cmd} per l'uso con \func{flock}; infatti il
2905 valore preimpostato fa riferimento alla semantica POSIX e vale rispettivamente
2906 \const{F\_SETLKW} o \const{F\_SETLK} a seconda che si sia impostato o meno la
2909 Nel caso si sia scelta la semantica BSD (\texttt{\small 25--34}) prima si
2910 controlla (\texttt{\small 27--31}) il valore di \var{cmd} per determinare se
2911 si vuole effettuare una chiamata bloccante o meno, reimpostandone il valore
2912 opportunamente, dopo di che a seconda del tipo di lock al valore viene
2913 aggiunta la relativa opzione (con un OR aritmetico, dato che \func{flock}
2914 vuole un argomento \param{operation} in forma di maschera binaria. Nel caso
2915 invece che si sia scelta la semantica POSIX le operazioni sono molto più
2916 immediate, si prepara (\texttt{\small 36--40}) la struttura per il lock, e lo
2917 esegue (\texttt{\small 41}).
2919 In entrambi i casi dopo aver richiesto il lock viene controllato il risultato
2920 uscendo (\texttt{\small 44--46}) in caso di errore, o stampando un messaggio
2921 (\texttt{\small 47--49}) in caso di successo. Infine il programma si pone in
2922 attesa (\texttt{\small 50}) finché un segnale (ad esempio un \cmd{C-c} dato da
2923 tastiera) non lo interrompa; in questo caso il programma termina, e tutti i
2924 lock vengono rilasciati.
2926 Con il programma possiamo fare varie verifiche sul funzionamento del file
2927 locking; cominciamo con l'eseguire un read lock su un file, ad esempio usando
2928 all'interno di un terminale il seguente comando:
2931 \begin{minipage}[c]{12cm}
2933 [piccardi@gont sources]$ ./flock -r Flock.c
2936 \end{minipage}\vspace{1mm}
2938 il programma segnalerà di aver acquisito un lock e si bloccherà; in questo
2939 caso si è usato il file locking POSIX e non avendo specificato niente riguardo
2940 alla sezione che si vuole bloccare sono stati usati i valori preimpostati che
2941 bloccano tutto il file. A questo punto se proviamo ad eseguire lo stesso
2942 comando in un altro terminale, e avremo lo stesso risultato. Se invece
2943 proviamo ad eseguire un write lock avremo:
2946 \begin{minipage}[c]{12cm}
2948 [piccardi@gont sources]$ ./flock -w Flock.c
2949 Failed lock: Resource temporarily unavailable
2951 \end{minipage}\vspace{1mm}
2953 come ci aspettiamo il programma terminerà segnalando l'indisponibilità del
2954 lock, dato che il file è bloccato dal precedente read lock. Si noti che il
2955 risultato è lo stesso anche se si richiede il blocco su una sola parte del
2956 file con il comando:
2959 \begin{minipage}[c]{12cm}
2961 [piccardi@gont sources]$ ./flock -w -s0 -l10 Flock.c
2962 Failed lock: Resource temporarily unavailable
2964 \end{minipage}\vspace{1mm}
2966 se invece blocchiamo una regione con:
2969 \begin{minipage}[c]{12cm}
2971 [piccardi@gont sources]$ ./flock -r -s0 -l10 Flock.c
2974 \end{minipage}\vspace{1mm}
2976 una volta che riproviamo ad acquisire il write lock i risultati dipenderanno
2977 dalla regione richiesta; ad esempio nel caso in cui le due regioni si
2978 sovrappongono avremo che:
2981 \begin{minipage}[c]{12cm}
2983 [piccardi@gont sources]$ ./flock -w -s5 -l15 Flock.c
2984 Failed lock: Resource temporarily unavailable
2986 \end{minipage}\vspace{1mm}
2988 ed il lock viene rifiutato, ma se invece si richiede una regione distinta
2992 \begin{minipage}[c]{12cm}
2994 [piccardi@gont sources]$ ./flock -w -s11 -l15 Flock.c
2997 \end{minipage}\vspace{1mm}
2999 ed il lock viene acquisito. Se a questo punto si prova ad eseguire un read
3000 lock che comprende la nuova regione bloccata in scrittura:
3003 \begin{minipage}[c]{12cm}
3005 [piccardi@gont sources]$ ./flock -r -s10 -l20 Flock.c
3006 Failed lock: Resource temporarily unavailable
3008 \end{minipage}\vspace{1mm}
3010 come ci aspettiamo questo non sarà consentito.
3012 Il programma di norma esegue il tentativo di acquisire il lock in modalità non
3013 bloccante, se però usiamo l'opzione \cmd{-b} possiamo impostare la modalità
3014 bloccante, riproviamo allora a ripetere le prove precedenti con questa
3018 \begin{minipage}[c]{12cm}
3020 [piccardi@gont sources]$ ./flock -r -b -s0 -l10 Flock.c Lock acquired
3022 \end{minipage}\vspace{1mm}
3024 il primo comando acquisisce subito un read lock, e quindi non cambia nulla, ma
3025 se proviamo adesso a richiedere un write lock che non potrà essere acquisito
3029 \begin{minipage}[c]{12cm}
3031 [piccardi@gont sources]$ ./flock -w -s0 -l10 Flock.c
3033 \end{minipage}\vspace{1mm}
3035 il programma cioè si bloccherà nella chiamata a \func{fcntl}; se a questo
3036 punto rilasciamo il precedente lock (terminando il primo comando un
3037 \texttt{C-c} sul terminale) potremo verificare che sull'altro terminale il
3038 lock viene acquisito, con la comparsa di una nuova riga:
3041 \begin{minipage}[c]{12cm}
3043 [piccardi@gont sources]$ ./flock -w -s0 -l10 Flock.c
3046 \end{minipage}\vspace{3mm}
3049 Un'altra cosa che si può controllare con il nostro programma è l'interazione
3050 fra i due tipi di lock; se ripartiamo dal primo comando con cui si è ottenuto
3051 un lock in lettura sull'intero file, possiamo verificare cosa succede quando
3052 si cerca di ottenere un lock in scrittura con la semantica BSD:
3055 \begin{minipage}[c]{12cm}
3057 [root@gont sources]# ./flock -f -w Flock.c
3060 \end{minipage}\vspace{1mm}
3062 che ci mostra come i due tipi di lock siano assolutamente indipendenti; per
3063 questo motivo occorre sempre tenere presente quale fra le due semantiche
3064 disponibili stanno usando i programmi con cui si interagisce, dato che i lock
3065 applicati con l'altra non avrebbero nessun effetto.
3069 \subsection{La funzione \func{lockf}}
3070 \label{sec:file_lockf}
3072 Abbiamo visto come l'interfaccia POSIX per il file locking sia molto più
3073 potente e flessibile di quella di BSD, questo comporta anche una maggiore
3074 complessità per via delle varie opzioni da passare a \func{fcntl}. Per questo
3075 motivo è disponibile anche una interfaccia semplificata (ripresa da System V)
3076 che utilizza la funzione \funcd{lockf}, il cui prototipo è:
3077 \begin{prototype}{sys/file.h}{int lockf(int fd, int cmd, off\_t len)}
3079 Applica, controlla o rimuove un \textit{file lock} sul file \param{fd}.
3081 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
3082 errore, nel qual caso \var{errno} assumerà uno dei valori:
3084 \item[\errcode{EWOULDBLOCK}] Non è possibile acquisire il lock, e si è
3085 selezionato \const{LOCK\_NB}, oppure l'operazione è proibita perché il
3086 file è mappato in memoria.
3087 \item[\errcode{ENOLCK}] Il sistema non ha le risorse per il locking: ci
3088 sono troppi segmenti di lock aperti, si è esaurita la tabella dei lock.
3090 ed inoltre \errval{EBADF}, \errval{EINVAL}.
3094 Il comportamento della funzione dipende dal valore dell'argomento \param{cmd},
3095 che specifica quale azione eseguire; i valori possibili sono riportati in
3096 tab.~\ref{tab:file_lockf_type}.
3101 \begin{tabular}[c]{|l|p{7cm}|}
3103 \textbf{Valore} & \textbf{Significato} \\
3106 \const{LOCK\_SH}& Richiede uno \textit{shared lock}. Più processi possono
3107 mantenere un lock condiviso sullo stesso file.\\
3108 \const{LOCK\_EX}& Richiede un \textit{exclusive lock}. Un solo processo
3109 alla volta può mantenere un lock esclusivo su un file. \\
3110 \const{LOCK\_UN}& Sblocca il file.\\
3111 \const{LOCK\_NB}& Non blocca la funzione quando il lock non è disponibile,
3112 si specifica sempre insieme ad una delle altre operazioni
3113 con un OR aritmetico dei valori.\\
3116 \caption{Valori possibili per l'argomento \param{cmd} di \func{lockf}.}
3117 \label{tab:file_lockf_type}
3120 Qualora il lock non possa essere acquisito, a meno di non aver specificato
3121 \const{LOCK\_NB}, la funzione si blocca fino alla disponibilità dello stesso.
3122 Dato che la funzione è implementata utilizzando \func{fcntl} la semantica
3123 delle operazioni è la stessa di quest'ultima (pertanto la funzione non è
3124 affatto equivalente a \func{flock}).
3128 \subsection{Il \textit{mandatory locking}}
3129 \label{sec:file_mand_locking}
3131 \itindbeg{mandatory~locking|(}
3133 Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
3134 per introdurre un file locking che, come dice il nome, fosse effettivo
3135 indipendentemente dai controlli eseguiti da un processo. Con il
3136 \textit{mandatory locking} infatti è possibile far eseguire il blocco del file
3137 direttamente al sistema, così che, anche qualora non si predisponessero le
3138 opportune verifiche nei processi, questo verrebbe comunque rispettato.
3140 Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
3141 utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid}. Se si ricorda
3142 quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma
3143 utilizzato per cambiare il group-ID effettivo con cui viene eseguito un
3144 programma, ed è pertanto sempre associato alla presenza del permesso di
3145 esecuzione per il gruppo. Impostando questo bit su un file senza permesso di
3146 esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che
3147 quest'ultimo venga attivato per il file in questione. In questo modo una
3148 combinazione dei permessi originariamente non contemplata, in quanto senza
3149 significato, diventa l'indicazione della presenza o meno del \textit{mandatory
3150 locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in
3151 sez.~\ref{sec:file_perm_management} e cioè che il bit \acr{sgid} viene
3152 cancellato (come misura di sicurezza) quando di scrive su un file, questo
3153 non vale quando esso viene utilizzato per attivare il \textit{mandatory
3156 L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che
3157 neanche l'amministratore può passare sopra ad un lock; pertanto un processo
3158 che blocchi un file cruciale può renderlo completamente inaccessibile,
3159 rendendo completamente inutilizzabile il sistema\footnote{il problema si
3160 potrebbe risolvere rimuovendo il bit \itindex{sgid~bit} \acr{sgid}, ma non è
3161 detto che sia così facile fare questa operazione con un sistema bloccato.}
3162 inoltre con il \textit{mandatory locking} si può bloccare completamente un
3163 server NFS richiedendo una lettura su un file su cui è attivo un lock. Per
3164 questo motivo l'abilitazione del mandatory locking è di norma disabilitata, e
3165 deve essere attivata filesystem per filesystem in fase di montaggio
3166 (specificando l'apposita opzione di \func{mount} riportata in
3167 tab.~\ref{tab:sys_mount_flags}, o con l'opzione \code{-o mand} per il comando
3170 Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
3171 sull'interfaccia POSIX di \func{fcntl}. Questo ha due conseguenze: che non si
3172 ha nessun effetto sui lock richiesti con l'interfaccia di \func{flock}, e che
3173 la granularità del lock è quella del singolo byte, come per \func{fcntl}.
3175 La sintassi di acquisizione dei lock è esattamente la stessa vista in
3176 precedenza per \func{fcntl} e \func{lockf}, la differenza è che in caso di
3177 mandatory lock attivato non è più necessario controllare la disponibilità di
3178 accesso al file, ma si potranno usare direttamente le ordinarie funzioni di
3179 lettura e scrittura e sarà compito del kernel gestire direttamente il file
3182 Questo significa che in caso di read lock la lettura dal file potrà avvenire
3183 normalmente con \func{read}, mentre una \func{write} si bloccherà fino al
3184 rilascio del lock, a meno di non aver aperto il file con \const{O\_NONBLOCK},
3185 nel qual caso essa ritornerà immediatamente con un errore di \errcode{EAGAIN}.
3187 Se invece si è acquisito un write lock tutti i tentativi di leggere o scrivere
3188 sulla regione del file bloccata fermeranno il processo fino al rilascio del
3189 lock, a meno che il file non sia stato aperto con \const{O\_NONBLOCK}, nel
3190 qual caso di nuovo si otterrà un ritorno immediato con l'errore di
3193 Infine occorre ricordare che le funzioni di lettura e scrittura non sono le
3194 sole ad operare sui contenuti di un file, e che sia \func{creat} che
3195 \func{open} (quando chiamata con \const{O\_TRUNC}) effettuano dei cambiamenti,
3196 così come \func{truncate}, riducendone le dimensioni (a zero nei primi due
3197 casi, a quanto specificato nel secondo). Queste operazioni sono assimilate a
3198 degli accessi in scrittura e pertanto non potranno essere eseguite (fallendo
3199 con un errore di \errcode{EAGAIN}) su un file su cui sia presente un qualunque
3200 lock (le prime due sempre, la terza solo nel caso che la riduzione delle
3201 dimensioni del file vada a sovrapporsi ad una regione bloccata).
3203 L'ultimo aspetto della interazione del \textit{mandatory locking} con le
3204 funzioni di accesso ai file è quello relativo ai file mappati in memoria (che
3205 abbiamo trattato in sez.~\ref{sec:file_memory_map}); anche in tal caso infatti,
3206 quando si esegue la mappatura con l'opzione \const{MAP\_SHARED}, si ha un
3207 accesso al contenuto del file. Lo standard SVID prevede che sia impossibile
3208 eseguire il memory mapping di un file su cui sono presenti dei
3209 lock\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
3210 impediscono anche in caso di \textit{advisory locking}, anche se questo
3211 comportamento non ha molto senso, dato che comunque qualunque accesso
3212 diretto al file è consentito.} in Linux è stata però fatta la scelta
3213 implementativa\footnote{per i dettagli si possono leggere le note relative
3214 all'implementazione, mantenute insieme ai sorgenti del kernel nel file
3215 \file{Documentation/mandatory.txt}.} di seguire questo comportamento
3216 soltanto quando si chiama \func{mmap} con l'opzione \const{MAP\_SHARED} (nel
3217 qual caso la funzione fallisce con il solito \errcode{EAGAIN}) che comporta la
3218 possibilità di modificare il file.
3220 \index{file!locking|)}
3222 \itindend{mandatory~locking|(}
3225 % LocalWords: dell'I locking multiplexing cap dell' sez system call socket BSD
3226 % LocalWords: descriptor client deadlock NONBLOCK EAGAIN polling select kernel
3227 % LocalWords: pselect like sys unistd int fd readfds writefds exceptfds struct
3228 % LocalWords: timeval errno EBADF EINTR EINVAL ENOMEM sleep tab signal void of
3229 % LocalWords: CLR ISSET SETSIZE POSIX read NULL nell'header l'header glibc fig
3230 % LocalWords: libc header psignal sigmask SOURCE XOPEN timespec sigset race DN
3231 % LocalWords: condition sigprocmask tut self trick oldmask poll XPG pollfd l'I
3232 % LocalWords: ufds unsigned nfds RLIMIT NOFILE EFAULT ndfs events revents hung
3233 % LocalWords: POLLIN POLLRDNORM POLLRDBAND POLLPRI POLLOUT POLLWRNORM POLLERR
3234 % LocalWords: POLLWRBAND POLLHUP POLLNVAL POLLMSG SysV stream ASYNC SETOWN FAQ
3235 % LocalWords: GETOWN fcntl SETFL SIGIO SETSIG Stevens driven siginfo sigaction
3236 % LocalWords: all'I nell'I Frequently Unanswered Question SIGHUP lease holder
3237 % LocalWords: breaker truncate write SETLEASE arg RDLCK WRLCK UNLCK GETLEASE
3238 % LocalWords: uid capabilities capability EWOULDBLOCK notify dall'OR ACCESS st
3239 % LocalWords: pread readv MODIFY pwrite writev ftruncate creat mknod mkdir buf
3240 % LocalWords: symlink rename DELETE unlink rmdir ATTRIB chown chmod utime lio
3241 % LocalWords: MULTISHOT thread linkando librt layer aiocb asyncronous control
3242 % LocalWords: block ASYNCHRONOUS lseek fildes nbytes reqprio PRIORITIZED sigev
3243 % LocalWords: PRIORITY SCHEDULING opcode listio sigevent signo value function
3244 % LocalWords: aiocbp ENOSYS append error const EINPROGRESS fsync return ssize
3245 % LocalWords: DSYNC fdatasync SYNC cancel ECANCELED ALLDONE CANCELED suspend
3246 % LocalWords: NOTCANCELED list nent timout sig NOP WAIT NOWAIT size count iov
3247 % LocalWords: iovec vector EOPNOTSUPP EISDIR len memory mapping mapped swap NB
3248 % LocalWords: mmap length prot flags off MAP FAILED ANONYMOUS EACCES SHARED SH
3249 % LocalWords: only ETXTBSY DENYWRITE ENODEV filesystem EPERM EXEC noexec table
3250 % LocalWords: ENFILE lenght segment violation SIGSEGV FIXED msync munmap copy
3251 % LocalWords: DoS Denial Service EXECUTABLE NORESERVE LOCKED swapping stack fs
3252 % LocalWords: GROWSDOWN ANON GiB POPULATE prefaulting SIGBUS fifo VME fork old
3253 % LocalWords: exec atime ctime mtime mprotect addr EACCESS mremap address new
3254 % LocalWords: long MAYMOVE realloc VMA virtual Ingo Molnar remap pages pgoff
3255 % LocalWords: dall' fault cache linker prelink advisory discrectionary lock fl
3256 % LocalWords: flock shared exclusive operation dup inode linked NFS cmd ENOLCK
3257 % LocalWords: EDEADLK whence SEEK CUR type pid GETLK SETLK SETLKW all'inode HP
3258 % LocalWords: switch bsd lockf mandatory SVr sgid group root mount mand TRUNC
3259 % LocalWords: SVID UX Documentation sendfile dnotify inotify NdA ppoll fds add
3260 % LocalWords: init EMFILE FIONREAD ioctl watch char pathname uint mask ENOSPC
3261 % LocalWords: dell'inode CLOSE NOWRITE MOVE MOVED FROM TO rm wd event page ctl
3262 % LocalWords: attribute Universe epoll Solaris kqueue level triggered Jonathan
3263 % LocalWords: Lemon BSDCON edge Libenzi kevent backporting epfd EEXIST ENOENT
3267 %%% Local Variables:
3269 %%% TeX-master: "gapil"