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|p{8cm}|}
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}, in
671 \param{event} devono essere specificate le
672 modalità di osservazione.\\
673 \const{EPOLL\_CTL\_MOD}& modifica le modalità di osservazione del file
674 descriptor \param{fd} secondo il contenuto di
676 \const{EPOLL\_CTL\_DEL}& rimuove il file descriptor \param{fd} dalla lista
677 dei file controllati tramite \param{epfd}.\\
680 \caption{Valori dell'argomento \param{op} che consentono di scegliere quale
681 operazione di controllo effettuare con la funzione \func{epoll\_ctl}.}
682 \label{tab:epoll_ctl_operation}
685 La funzione prende sempre come primo argomento un file descriptor di
686 \textit{epoll}, \param{epfd}, che deve essere stato ottenuto in precedenza con
687 una chiamata a \func{epoll\_create}. L'argomento \param{fd} indica invece il
688 file descriptor che si vuole tenere sotto controllo, quest'ultimo può essere
689 un qualunque file descriptor utilizzabile con \func{poll}, ed anche un altro
690 file descriptor di \textit{epoll}, ma non lo stesso \param{epfd}.
692 L'ultimo argomento, \param{event}, deve essere un puntatore ad una struttura
693 di tipo \struct{epoll\_event}, ed ha significato solo con le operazioni
694 \const{EPOLL\_CTL\_MOD} e \const{EPOLL\_CTL\_ADD} per le quali serve ad
695 indicare quale tipo di evento relativo ad \param{fd} si vuole che sia tenuto
696 sotto controllo. L'argomento viene ignorato con
697 \const{EPOLL\_CTL\_DEL}.\footnote{fino al kernel 2.6.9 era comunque richiesto
698 che questo fosse un puntatore valido, anche se poi veniva ignorato, a
699 partire dal 2.6.9 si può specificare anche anche un valore \texttt{NULL}.}
702 \footnotesize \centering
703 \begin{minipage}[c]{15cm}
704 \includestruct{listati/epoll_event.h}
707 \caption{La struttura \structd{epoll\_event}, che consente di specificare
708 gli eventi associati ad un file descriptor controllato con
710 \label{fig:epoll_event}
714 La struttura \struct{epoll\_event} è l'analoga di \struct{pollfd} e serve da
715 una parte ad impostare quali eventi osservare, dall'altra a ricevere le
716 notifiche degli eventi avvenuti. La sua definizione è riportata in
717 fig.~\ref{fig:epoll_event}; il primo campo, \var{events}, è una maschera
718 binaria in cui ciascun bit corrisponde o ad un tipo di evento, o una modalità
719 di notifica. Detto campo deve essere specificato come OR aritmetico delle
720 costanti riportate in tab.~\ref{tab:epoll_events}. Il secondo campo,
721 \var{data}, serve ad indicare a quale file descriptor si intende fare
722 riferimento, ed in astratto può contenere un valore qualsiasi che permetta di
723 identificarlo, di norma comunque si usa come valore lo stesso \param{fd}.
728 \begin{tabular}[c]{|l|p{8cm}|}
730 \textbf{Valore} & \textbf{Significato} \\
733 \const{EPOLLIN} & Il file è pronto per le operazioni di lettura
734 (analogo di \const{POLLIN}).\\
735 \const{EPOLLOUT} & Il file è pronto per le operazioni di scrittura
736 (analogo di \const{POLLOUT}).\\
737 \const{EPOLLRDHUP} & .\\
738 \const{EPOLLPRI} & Ci sono \itindex{out-of-band} dati urgenti
739 disponibili in lettura (analogo di
741 \const{EPOLLERR} & Si è verificata una condizione di errore
742 (analogo di \const{POLLERR}).\\
743 \const{EPOLLHUP} & Si è verificata una condizione di hung-up.\\
744 \const{EPOLLET} & .\\
745 \const{EPOLLONESHOT}& .\\
748 \caption{Valori del campo \param{events} di \struct{epoll\_event}.}
749 \label{tab:epoll_events}
758 La funzione che consente di attendere è \funcd{epoll\_wait}, il cui prototipo
760 \begin{prototype}{sys/epoll.h}
761 {int epoll\_wait(int epfd, struct epoll\_event * events, int maxevents, int
764 Attende che uno dei file descriptor osservati sia pronto.
766 \bodydesc{La funzione restituisce il numero di file descriptor pronti in
767 caso di successo o $-1$ in caso di errore, nel qual caso \var{errno}
768 assumerà uno dei valori:
770 \item[\errcode{EBADF}] il file descriptor \param{epfd} non è valido.
771 \item[\errcode{EFAULT}] il puntatore \param{events} non è valido.
772 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima
773 della scadenza di \param{timeout}.
774 \item[\errcode{EINVAL}] il file descriptor \param{epfd} non è stato ottenuto
775 con \func{epoll\_create}, o \param{fd} è lo stesso \param{epfd} o
776 l'operazione richiesta con \param{op} non è supportata.
786 \section{L'accesso \textsl{asincrono} ai file}
787 \label{sec:file_asyncronous_access}
789 Benché l'\textit{I/O multiplexing} sia stata la prima, e sia tutt'ora una fra
790 le più diffuse modalità di gestire l'I/O in situazioni complesse in cui si
791 debba operare su più file contemporaneamente, esistono altre modalità di
792 gestione delle stesse problematiche. In particolare sono importanti in questo
793 contesto le modalità di accesso ai file eseguibili in maniera
794 \textsl{asincrona}, quelle cioè in cui un processo non deve bloccarsi in
795 attesa della disponibilità dell'accesso al file, ma può proseguire
796 nell'esecuzione utilizzando invece un meccanismo di notifica asincrono (di
797 norma un segnale), per essere avvisato della possibilità di eseguire le
798 operazioni di I/O volute.
801 \subsection{Operazioni asincrone sui file}
802 \label{sec:file_asyncronous_operation}
804 Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso l'uso
805 del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e dei
806 comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è specifico
807 di Linux e BSD.} aprire un file in modalità asincrona, così come è possibile
808 attivare in un secondo tempo questa modalità impostando questo flag attraverso
809 l'uso di \func{fcntl} con il comando \const{F\_SETFL} (vedi
810 sez.~\ref{sec:file_fcntl}).
812 In realtà in questo caso non si tratta di eseguire delle operazioni di lettura
813 o scrittura del file in modo asincrono (tratteremo questo, che più
814 propriamente è detto \textsl{I/O asincrono} in
815 sez.~\ref{sec:file_asyncronous_io}), quanto di un meccanismo asincrono di
816 notifica delle variazione dello stato del file descriptor aperto in questo
819 Quello che succede in questo caso è che il sistema genera un segnale
820 (normalmente \const{SIGIO}, ma è possibile usarne altri con il comando
821 \const{F\_SETSIG} di \func{fcntl}) tutte le volte che diventa possibile
822 leggere o scrivere dal file descriptor che si è posto in questa modalità. Si
823 può inoltre selezionare, con il comando \const{F\_SETOWN} di \func{fcntl},
824 quale processo (o gruppo di processi) riceverà il segnale. Se pertanto si
825 effettuano le operazioni di I/O in risposta alla ricezione del segnale non ci
826 sarà più la necessità di restare bloccati in attesa della disponibilità di
827 accesso ai file; per questo motivo Stevens chiama questa modalità
828 \textit{signal driven I/O}.
830 Questa è un'altra modalità di gestione I/O, alternativa all'uso di
831 \itindex{epoll} \textit{epoll}, che consente di evitare l'uso delle funzioni
832 \func{poll} o \func{select} che, come illustrato in sez.~\ref{sec:file_epoll},
833 quando vengono usate con un numero molto grande di file descriptor, non hanno
836 Tuttavia con l'implementazione classica dei segnali questa modalità di I/O
837 presenta notevoli problemi, dato che non è possibile determinare, quando i
838 file descriptor sono più di uno, qual è quello responsabile dell'emissione del
839 segnale. Inoltre dato che i segnali normali non si accodano (si ricordi quanto
840 illustrato in sez.~\ref{sec:sig_notification}), in presenza di più file
841 descriptor attivi contemporaneamente, più segnali emessi nello stesso momento
842 verrebbero notificati una volta sola.
844 Linux però supporta le estensioni POSIX.1b dei segnali real-time, che vengono
845 accodati e che permettono di riconoscere il file descriptor che li ha emessi.
846 In questo caso infatti si può fare ricorso alle informazioni aggiuntive
847 restituite attraverso la struttura \struct{siginfo\_t}, utilizzando la forma
848 estesa \var{sa\_sigaction} del gestore installata con il flag
849 \const{SA\_SIGINFO} (si riveda quanto illustrato in
850 sez.~\ref{sec:sig_sigaction}).
852 Per far questo però occorre utilizzare le funzionalità dei segnali real-time
853 (vedi sez.~\ref{sec:sig_real_time}) impostando esplicitamente con il comando
854 \const{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
855 I/O asincrono (il segnale predefinito è \const{SIGIO}). In questo caso il
856 gestore, tutte le volte che riceverà \const{SI\_SIGIO} come valore del
857 campo \var{si\_code}\footnote{il valore resta \const{SI\_SIGIO} qualunque sia
858 il segnale che si è associato all'I/O asincrono, ed indica appunto che il
859 segnale è stato generato a causa di attività nell'I/O asincrono.} di
860 \struct{siginfo\_t}, troverà nel campo \var{si\_fd} il valore del file
861 descriptor che ha generato il segnale.
863 Un secondo vantaggio dell'uso dei segnali real-time è che essendo questi
864 ultimi dotati di una coda di consegna ogni segnale sarà associato ad uno solo
865 file descriptor; inoltre sarà possibile stabilire delle priorità nella
866 risposta a seconda del segnale usato, dato che i segnali real-time supportano
867 anche questa funzionalità. In questo modo si può identificare immediatamente
868 un file su cui l'accesso è diventato possibile evitando completamente l'uso di
869 funzioni come \func{poll} e \func{select}, almeno fintanto che non si satura
872 Se infatti si eccedono le dimensioni di quest'ultima, il kernel, non potendo
873 più assicurare il comportamento corretto per un segnale real-time, invierà al
874 suo posto un solo \const{SIGIO}, su cui si saranno accumulati tutti i segnali
875 in eccesso, e si dovrà allora determinare con un ciclo quali sono i file
878 % TODO fare esempio che usa O_ASYNC
881 \subsection{I meccanismi di notifica asincrona.}
882 \label{sec:file_asyncronous_lease}
884 Una delle domande più frequenti nella programmazione in ambiente unix-like è
885 quella di come fare a sapere quando un file viene modificato. La
886 risposta\footnote{o meglio la non risposta, tanto che questa nelle Unix FAQ
887 \cite{UnixFAQ} viene anche chiamata una \textit{Frequently Unanswered
888 Question}.} è che nell'architettura classica di Unix questo non è
889 possibile. Al contrario di altri sistemi operativi infatti un kernel unix-like
890 non prevede alcun meccanismo per cui un processo possa essere
891 \textsl{notificato} di eventuali modifiche avvenute su un file. Questo è il
892 motivo per cui i demoni devono essere \textsl{avvisati} in qualche
893 modo\footnote{in genere questo vien fatto inviandogli un segnale di
894 \const{SIGHUP} che, per convenzione adottata dalla gran parte di detti
895 programmi, causa la rilettura della configurazione.} se il loro file di
896 configurazione è stato modificato, perché possano rileggerlo e riconoscere le
899 Questa scelta è stata fatta perché provvedere un simile meccanismo a livello
900 generale comporterebbe un notevole aumento di complessità dell'architettura
901 della gestione dei file, per fornire una funzionalità necessaria soltanto in
902 casi particolari. Dato che all'origine di Unix i soli programmi che potevano
903 avere una tale esigenza erano i demoni, attenendosi a uno dei criteri base
904 della progettazione, che era di far fare al kernel solo le operazioni
905 strettamente necessarie e lasciare tutto il resto a processi in user space,
906 non era stata prevista nessuna funzionalità di notifica.
908 Visto però il crescente interesse nei confronti di una funzionalità di questo
909 tipo (molto richiesta specialmente nello sviluppo dei programmi ad interfaccia
910 grafica) sono state successivamente introdotte delle estensioni che
911 permettessero la creazione di meccanismi di notifica più efficienti dell'unica
912 soluzione disponibile con l'interfaccia tradizionale, che è quella del
913 \itindex{polling} \textit{polling}.
915 Queste nuove funzionalità sono delle estensioni specifiche, non
916 standardizzate, che sono disponibili soltanto su Linux (anche se altri kernel
917 supportano meccanismi simili). Alcune di esse sono realizzate, e solo a
918 partire dalla versione 2.4 del kernel, attraverso l'uso di alcuni
919 \textsl{comandi} aggiuntivi per la funzione \func{fcntl} (vedi
920 sez.~\ref{sec:file_fcntl}), che divengono disponibili soltanto se si è
921 definita la macro \macro{\_GNU\_SOURCE} prima di includere \file{fcntl.h}.
925 La prima di queste funzionalità è quella del cosiddetto \textit{file lease};
926 questo è un meccanismo che consente ad un processo, detto \textit{lease
927 holder}, di essere notificato quando un altro processo, chiamato a sua volta
928 \textit{lease breaker}, cerca di eseguire una \func{open} o una
929 \func{truncate} sul file del quale l'\textit{holder} detiene il
932 La notifica avviene in maniera analoga a come illustrato in precedenza per
933 l'uso di \const{O\_ASYNC}: di default viene inviato al \textit{lease holder}
934 il segnale \const{SIGIO}, ma questo segnale può essere modificato usando il
935 comando \const{F\_SETSIG} di \func{fcntl}.\footnote{anche in questo caso si
936 può rispecificare lo stesso \const{SIGIO}.} Se si è fatto questo\footnote{è
937 in genere è opportuno farlo, come in precedenza, per utilizzare segnali
938 real-time.} e si è installato il gestore del segnale con \const{SA\_SIGINFO}
939 si riceverà nel campo \var{si\_fd} della struttura \struct{siginfo\_t} il
940 valore del file descriptor del file sul quale è stato compiuto l'accesso; in
941 questo modo un processo può mantenere anche più di un \textit{file lease}.
943 Esistono due tipi di \textit{file lease}: di lettura (\textit{read lease}) e
944 di scrittura (\textit{write lease}). Nel primo caso la notifica avviene quando
945 un altro processo esegue l'apertura del file in scrittura o usa
946 \func{truncate} per troncarlo. Nel secondo caso la notifica avviene anche se
947 il file viene aperto il lettura; in quest'ultimo caso però il \textit{lease}
948 può essere ottenuto solo se nessun altro processo ha aperto lo stesso file.
950 Come accennato in sez.~\ref{sec:file_fcntl} il comando di \func{fcntl} che
951 consente di acquisire un \textit{file lease} è \const{F\_SETLEASE}, che viene
952 utilizzato anche per rilasciarlo. In tal caso il file descriptor \param{fd}
953 passato a \func{fcntl} servirà come riferimento per il file su cui si vuole
954 operare, mentre per indicare il tipo di operazione (acquisizione o rilascio)
955 occorrerà specificare come valore dell'argomento \param{arg} di \func{fcntl}
956 uno dei tre valori di tab.~\ref{tab:file_lease_fctnl}.
961 \begin{tabular}[c]{|l|l|}
963 \textbf{Valore} & \textbf{Significato} \\
966 \const{F\_RDLCK} & Richiede un \textit{read lease}.\\
967 \const{F\_WRLCK} & Richiede un \textit{write lease}.\\
968 \const{F\_UNLCK} & Rilascia un \textit{file lease}.\\
971 \caption{Costanti per i tre possibili valori dell'argomento \param{arg} di
972 \func{fcntl} quando usata con i comandi \const{F\_SETLEASE} e
973 \const{F\_GETLEASE}.}
974 \label{tab:file_lease_fctnl}
977 Se invece si vuole conoscere lo stato di eventuali \textit{file lease}
978 occorrerà chiamare \func{fcntl} sul relativo file descriptor \param{fd} con il
979 comando \const{F\_GETLEASE}, e si otterrà indietro nell'argomento \param{arg}
980 uno dei valori di tab.~\ref{tab:file_lease_fctnl}, che indicheranno la
981 presenza del rispettivo tipo di \textit{lease}, o, nel caso di
982 \const{F\_UNLCK}, l'assenza di qualunque \textit{file lease}.
984 Si tenga presente che un processo può mantenere solo un tipo di \textit{lease}
985 su un file, e che un \textit{lease} può essere ottenuto solo su file di dati
986 (pipe e dispositivi sono quindi esclusi). Inoltre un processo non privilegiato
987 può ottenere un \textit{lease} soltanto per un file appartenente ad un
988 \acr{uid} corrispondente a quello del processo. Soltanto un processo con
989 privilegi di amministratore (cioè con la \itindex{capabilities} capability
990 \const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può acquisire
991 \textit{lease} su qualunque file.
993 Se su un file è presente un \textit{lease} quando il \textit{lease breaker}
994 esegue una \func{truncate} o una \func{open} che confligge con
995 esso,\footnote{in realtà \func{truncate} confligge sempre, mentre \func{open},
996 se eseguita in sola lettura, non confligge se si tratta di un \textit{read
997 lease}.} la funzione si blocca\footnote{a meno di non avere aperto il file
998 con \const{O\_NONBLOCK}, nel qual caso \func{open} fallirebbe con un errore
999 di \errcode{EWOULDBLOCK}.} e viene eseguita la notifica al \textit{lease
1000 holder}, così che questo possa completare le sue operazioni sul file e
1001 rilasciare il \textit{lease}. In sostanza con un \textit{read lease} si
1002 rilevano i tentativi di accedere al file per modificarne i dati da parte di un
1003 altro processo, mentre con un \textit{write lease} si rilevano anche i
1004 tentativi di accesso in lettura. Si noti comunque che le operazioni di
1005 notifica avvengono solo in fase di apertura del file e non sulle singole
1006 operazioni di lettura e scrittura.
1008 L'utilizzo dei \textit{file lease} consente al \textit{lease holder} di
1009 assicurare la consistenza di un file, a seconda dei due casi, prima che un
1010 altro processo inizi con le sue operazioni di scrittura o di lettura su di
1011 esso. In genere un \textit{lease holder} che riceve una notifica deve
1012 provvedere a completare le necessarie operazioni (ad esempio scaricare
1013 eventuali buffer), per poi rilasciare il \textit{lease} così che il
1014 \textit{lease breaker} possa eseguire le sue operazioni. Questo si fa con il
1015 comando \const{F\_SETLEASE}, o rimuovendo il \textit{lease} con
1016 \const{F\_UNLCK}, o, nel caso di \textit{write lease} che confligge con una
1017 operazione di lettura, declassando il \textit{lease} a lettura con
1020 Se il \textit{lease holder} non provvede a rilasciare il \textit{lease} entro
1021 il numero di secondi specificato dal parametro di sistema mantenuto in
1022 \file{/proc/sys/fs/lease-break-time} sarà il kernel stesso a rimuoverlo (o
1023 declassarlo) automaticamente.\footnote{questa è una misura di sicurezza per
1024 evitare che un processo blocchi indefinitamente l'accesso ad un file
1025 acquisendo un \textit{lease}.} Una volta che un \textit{lease} è stato
1026 rilasciato o declassato (che questo sia fatto dal \textit{lease holder} o dal
1027 kernel è lo stesso) le chiamate a \func{open} o \func{truncate} eseguite dal
1028 \textit{lease breaker} rimaste bloccate proseguono automaticamente.
1031 \index{file!dnotify|(}
1033 Benché possa risultare utile per sincronizzare l'accesso ad uno stesso file da
1034 parte di più processi, l'uso dei \textit{file lease} non consente comunque di
1035 risolvere il problema di rilevare automaticamente quando un file o una
1036 directory vengono modificati, che è quanto necessario ad esempio ai programma
1037 di gestione dei file dei vari desktop grafici.
1039 Per risolvere questo problema è stata allora creata un'altra interfaccia,
1040 chiamata \textit{dnotify}, che consente di richiedere una notifica quando una
1041 directory, o di uno qualunque dei file in essa contenuti, viene modificato.
1042 Come per i \textit{file lease} la notifica avviene di default attraverso il
1043 segnale \const{SIGIO}, ma se ne può utilizzare un altro. Inoltre si potrà
1044 ottenere nel gestore del segnale il file descriptor che è stato modificato
1045 tramite il contenuto della struttura \struct{siginfo\_t}.
1047 \index{file!lease|)}
1052 \begin{tabular}[c]{|l|p{8cm}|}
1054 \textbf{Valore} & \textbf{Significato} \\
1057 \const{DN\_ACCESS} & Un file è stato acceduto, con l'esecuzione di una fra
1058 \func{read}, \func{pread}, \func{readv}.\\
1059 \const{DN\_MODIFY} & Un file è stato modificato, con l'esecuzione di una
1060 fra \func{write}, \func{pwrite}, \func{writev},
1061 \func{truncate}, \func{ftruncate}.\\
1062 \const{DN\_CREATE} & È stato creato un file nella directory, con
1063 l'esecuzione di una fra \func{open}, \func{creat},
1064 \func{mknod}, \func{mkdir}, \func{link},
1065 \func{symlink}, \func{rename} (da un'altra
1067 \const{DN\_DELETE} & È stato cancellato un file dalla directory con
1068 l'esecuzione di una fra \func{unlink}, \func{rename}
1069 (su un'altra directory), \func{rmdir}.\\
1070 \const{DN\_RENAME} & È stato rinominato un file all'interno della
1071 directory (con \func{rename}).\\
1072 \const{DN\_ATTRIB} & È stato modificato un attributo di un file con
1073 l'esecuzione di una fra \func{chown}, \func{chmod},
1075 \const{DN\_MULTISHOT}& richiede una notifica permanente di tutti gli
1079 \caption{Le costanti che identificano le varie classi di eventi per i quali
1080 si richiede la notifica con il comando \const{F\_NOTIFY} di \func{fcntl}.}
1081 \label{tab:file_notify}
1084 Ci si può registrare per le notifiche dei cambiamenti al contenuto di una
1085 certa directory eseguendo la funzione \func{fcntl} su un file descriptor
1086 associato alla stessa con il comando \const{F\_NOTIFY}. In questo caso
1087 l'argomento \param{arg} di \func{fcntl} serve ad indicare per quali classi
1088 eventi si vuole ricevere la notifica, e prende come valore una maschera
1089 binaria composta dall'OR aritmetico di una o più delle costanti riportate in
1090 tab.~\ref{tab:file_notify}.
1092 A meno di non impostare in maniera esplicita una notifica permanente usando il
1093 valore \const{DN\_MULTISHOT}, la notifica è singola: viene cioè inviata una
1094 sola volta quando si verifica uno qualunque fra gli eventi per i quali la si è
1095 richiesta. Questo significa che un programma deve registrarsi un'altra volta
1096 se desidera essere notificato di ulteriori cambiamenti. Se si eseguono diverse
1097 chiamate con \const{F\_NOTIFY} e con valori diversi per \param{arg} questi
1098 ultimi si \textsl{accumulano}; cioè eventuali nuovi classi di eventi
1099 specificate in chiamate successive vengono aggiunte a quelle già impostate
1100 nelle precedenti. Se si vuole rimuovere la notifica si deve invece
1101 specificare un valore nullo.
1103 \index{file!inotify|(}
1105 Il maggiore problema di \textit{dnotify} è quello della scalabilità: si deve
1106 usare un file descriptor per ciascuna directory che si vuole tenere sotto
1107 controllo, il che porta facilmente ad un eccesso di file aperti. Inoltre
1108 quando la directory è su un dispositivo rimovibile, mantenere un file
1109 descriptor aperto comporta l'impossibilità di smontare il dispositivo e
1110 rimuoverlo, complicando la gestione.
1112 Un secondo problema è che l'interfaccia consente solo di tenere sotto
1113 controllo il contenuto di una directory; la modifica di un file viene
1114 segnalata, ma poi devo verificare quale è. Infine l'uso dei segnali come
1115 interfaccia di notifica comporta tutti i problemi di gestione visti in
1116 sez.~\ref{sec:sig_management} e sez.~\ref{sec:sig_control}, e per questo in
1117 generale quella di \textit{dnotify} viene considerata una interfaccia di
1118 usabilità problematica.
1120 \index{file!dnotify|)}
1122 Per questa serie di motivi, a partire dal kernel 2.6.13, è stata introdotta
1123 una nuova interfaccia per l'osservazione delle modifiche a file o directory,
1124 chiamata \textit{inotify}.\footnote{le corrispondenti funzioni di interfaccia
1125 sono state introdotte nelle glibc 2.4.} Questa è una interfaccia specifica
1126 di Linux (pertanto non deve essere usata se si devono scrivere programmi
1127 portabili), ed è basata sull'uso di una coda di notifica degli eventi
1128 associata ad un singolo file descriptor, risolvendo così il principale
1129 problema di \itindex{dnotify} \textit{dnotify}. La coda viene creata
1130 attraverso la funzione \funcd{inotify\_init}, il cui prototipo è:
1131 \begin{prototype}{sys/inotify.h}
1132 {int inotify\_init(void)}
1134 Inizializza una istanza di \textit{inotify}.
1136 \bodydesc{La funzione restituisce un file descriptor in caso di successo, o
1137 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1139 \item[\errcode{EMFILE}] si è raggiunto il numero massimo di istanze di
1140 \textit{inotify} consentite all'utente.
1141 \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
1143 \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
1149 La funzione non prende alcun argomento, e restituisce un file descriptor
1150 associato alla coda, attraverso il quale verranno effettuate le operazioni di
1151 notifica. Si tratta di un file descriptor speciale, che non è associato a
1152 nessun file, ma che viene utilizzato per notificare gli eventi che si sono
1153 posti in osservazione all'applicazione che usa l'interfaccia di
1154 \textit{inotify}. Dato che questo file descriptor non è associato a nessun
1155 file o directory, questo consente di evitare l'inconveniente di non poter
1156 smontare un filesystem i cui file sono tenuti sotto osservazione.\footnote{ed
1157 una delle caratteristiche dell'interfaccia di \textit{inotify} è proprio
1158 quella di notificare il fatto che il filesystem su cui si trova il file o la
1159 directory osservata è stato smontato.}
1161 Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà
1162 essere utilizzato come argomento per le funzioni \func{select} e \func{poll},
1163 e siccome gli eventi vengono notificati come dati disponibili in lettura sul
1164 file descriptor, dette funzioni ritorneranno tutte le volte che si avrà un
1165 evento di notifica. Così, invece di dover utilizzare i segnali, si potrà
1166 gestire l'osservazione delle modifiche con l'\textit{I/O multiplexing},
1167 utilizzando secondo le modalità illustrate in
1168 sez.~\ref{sec:file_multiplexing}.
1170 Infine l'interfaccia di \textit{inotify} consente di mettere sotto
1171 osservazione sia singoli file, che intere directory; in quest'ultimo caso
1172 l'interfaccia restituirà informazioni sia riguardo alla directory che ai file
1173 che essa contiene. Una volta creata la coda di notifica si devono definire
1174 gli eventi da tenere sotto osservazione; questo viene fatto tramite una
1175 \textsl{lista di osservazione} (o \textit{watch list}) associata alla coda.
1176 Per gestire la lista di osservazione l'interfaccia fornisce due funzioni, la
1177 prima di queste è \funcd{inotify\_add\_watch}, il cui prototipo è:
1178 \begin{prototype}{sys/inotify.h}
1179 {int inotify\_add\_watch(int fd, const char *pathname, uint32\_t mask)}
1181 Aggiunge un evento di osservazione alla lista di osservazione di \param{fd}.
1183 \bodydesc{La funzione restituisce un valore positivo in caso di successo, o
1184 $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
1186 \item[\errcode{EACCESS}] non si ha accesso in lettura al file indicato.
1187 \item[\errcode{EINVAL}] \param{mask} non contiene eventi legali o \param{fd}
1188 non è un filesystem di \textit{inotify}.
1189 \item[\errcode{ENOSPC}] si è raggiunto il numero massimo di voci di
1190 osservazione o il kernel non ha potuto allocare una risorsa necessaria.
1192 ed inoltre \errval{EFAULT}, \errval{ENOMEM} e \errval{EBADF}.}
1195 La funzione consente di creare un \textsl{evento di osservazione} (un
1196 cosiddetto ``\textit{watch}'') nella lista di una coda di notifica, indicata
1197 specificando il file descriptor ad essa associato nell'argomento \param{fd}.
1198 Il file o la directory da porre sotto osservazione viene invece indicato per
1199 nome, che viene passato nell'argomento \param{pathname}. Infine il terzo
1200 argomento, \param{mask}, indica che tipo di eventi devono essere tenuti sotto
1201 osservazione. Questo deve essere specificato come maschera binaria combinando
1202 i valori delle costanti riportate in tab.~\ref{tab:inotify_event_watch}. In
1203 essa si sono marcati con un ``$\bullet$'' gli eventi che, quando specificati
1204 per una directory, vengono osservati anche su tutti i file che essa contiene.
1209 \begin{tabular}[c]{|l|c|p{10cm}|}
1211 \textbf{Valore} & & \textbf{Significato} \\
1214 \const{IN\_ACCESS} &$\bullet$& c'è stato accesso al file in
1216 \const{IN\_ATTRIB} &$\bullet$& ci sono stati cambiamenti sui dati
1218 \const{IN\_CLOSE\_WRITE} &$\bullet$& è stato chiuso un file aperto in
1220 \const{IN\_CLOSE\_NOWRITE}&$\bullet$& è stato chiuso un file aperto in
1222 \const{IN\_CREATE} &$\bullet$& è stato creato un file o una
1223 directory in una directory sotto
1225 \const{IN\_DELETE} &$\bullet$& è stato cancellato un file o una
1226 directory in una directory sotto
1228 \const{IN\_DELETE\_SELF} & & è stato cancellato il file (o la
1229 directory) sotto osservazione.\\
1230 \const{IN\_MODIFY} &$\bullet$& è stato modificato il file.\\
1231 \const{IN\_MOVE\_SELF} & & è stato rinominato il file (o la
1232 directory) sotto osservazione.\\
1233 \const{IN\_MOVED\_FROM} &$\bullet$& un file è stato spostato fuori dalla
1234 directory sotto osservazione.\\
1235 \const{IN\_MOVED\_TO} &$\bullet$& un file è stato spostato nella
1236 directory sotto osservazione.\\
1237 \const{IN\_OPEN} &$\bullet$& un file è stato aperto.\\
1240 \caption{Le costanti che identificano i valori per la maschera binaria
1241 dell'argomento \param{mask} di \func{inotify\_add\_watch}.}
1242 \label{tab:inotify_event_watch}
1245 Se non esiste nessun \textit{watch} per il file (o la directory) specificata
1246 questo verrà creato per gli eventi specificati dall'argomento \param{mask},
1247 altrimenti la funzione sovrascriverà le impostazioni precedenti. In caso di
1248 successo la funzione ritorna un intero positivo, detto \textit{watch
1249 descriptor} che identifica univocamente l'evento di osservazione. Questo
1250 valore è importante perché è soltanto con esso che si può rimuovere un evento
1251 di osservazione, usando la seconda funzione dell'interfaccia di gestione,
1252 \funcd{inotify\_rm\_watch}, il cui prototipo è:
1253 \begin{prototype}{sys/inotify.h}
1254 {int inotify\_rm\_watch(int fd, uint32\_t wd)}
1256 Rimuove un evento di osservazione.
1258 \bodydesc{La funzione restituisce 0 in caso di successo, o $-1$ in caso di
1259 errore, nel qual caso \var{errno} assumerà uno dei valori:
1261 \item[\errcode{EBADF}] non si è specificato in \param{fd} un file descriptor
1263 \item[\errcode{EINVAL}] il valore di \param{wd} non è corretto, o \param{fd}
1264 non è associato ad una coda di notifica.
1269 Oltre che per la rimozione, il \textit{watch descriptor} viene usato anche per
1270 identificare l'evento a cui si fa riferimento nella lista dei risultati
1271 restituiti da \textit{inotify}
1274 \begin{figure}[!htb]
1275 \footnotesize \centering
1276 \begin{minipage}[c]{15cm}
1277 \includestruct{listati/inotify_event.h}
1280 \caption{La struttura \structd{inotify\_event}.}
1281 \label{fig:inotify_event}
1285 Inoltre l'interfaccia di \textit{inotify} permette di conoscere, come avviene
1286 per i file descriptor associati ai socket (si veda al proposito quanto
1287 trattato in sez.~\ref{sec:sock_ioctl_IP}) il numero di byte disponibili in
1288 lettura sul nostro file descriptor, utilizzando su di esso l'operazione
1289 \const{FIONREAD} con \func{ioctl}.\footnote{questa è una delle operazioni
1290 speciali (che abbiamo visto in sez.~\ref{sec:file_ioctl}) che nel caso è
1291 disponibile solo per i socket e per i file descriptor creati con
1292 \func{inotify\_init}.} Questo consente anche di ottenere rapidamente il
1293 numero di file che sono cambiati.
1297 % TODO inserire anche inotify, vedi http://www.linuxjournal.com/article/8478
1298 % TODO e man inotify
1300 \index{file!inotify|)}
1303 % TODO inserire anche eventfd (vedi http://lwn.net/Articles/233462/)
1307 \subsection{L'interfaccia POSIX per l'I/O asincrono}
1308 \label{sec:file_asyncronous_io}
1310 Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione
1311 dell'I/O simultaneo su molti file è costituita dal cosiddetto \textsl{I/O
1312 asincrono}. Il concetto base dell'\textsl{I/O asincrono} è che le funzioni
1313 di I/O non attendono il completamento delle operazioni prima di ritornare,
1314 così che il processo non viene bloccato. In questo modo diventa ad esempio
1315 possibile effettuare una richiesta preventiva di dati, in modo da poter
1316 effettuare in contemporanea le operazioni di calcolo e quelle di I/O.
1318 Benché la modalità di apertura asincrona di un file possa risultare utile in
1319 varie occasioni (in particolar modo con i socket e gli altri file per i quali
1320 le funzioni di I/O sono \index{system~call~lente} system call lente), essa è
1321 comunque limitata alla notifica della disponibilità del file descriptor per le
1322 operazioni di I/O, e non ad uno svolgimento asincrono delle medesime. Lo
1323 standard POSIX.1b definisce una interfaccia apposita per l'I/O asincrono vero
1324 e proprio, che prevede un insieme di funzioni dedicate per la lettura e la
1325 scrittura dei file, completamente separate rispetto a quelle usate
1328 In generale questa interfaccia è completamente astratta e può essere
1329 implementata sia direttamente nel kernel, che in user space attraverso l'uso
1330 di thread. Per le versioni del kernel meno recenti esiste una implementazione
1331 di questa interfaccia fornita delle \acr{glibc}, che è realizzata
1332 completamente in user space, ed è accessibile linkando i programmi con la
1333 libreria \file{librt}. Nelle versioni più recenti (a partire dalla 2.5.32) è
1334 stato introdotto direttamente nel kernel un nuovo layer per l'I/O asincrono.
1336 Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
1337 attraverso l'uso di una apposita struttura \struct{aiocb} (il cui nome sta per
1338 \textit{asyncronous I/O control block}), che viene passata come argomento a
1339 tutte le funzioni dell'interfaccia. La sua definizione, come effettuata in
1340 \file{aio.h}, è riportata in fig.~\ref{fig:file_aiocb}. Nello steso file è
1341 definita la macro \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la
1342 disponibilità dell'interfaccia per l'I/O asincrono.
1344 \begin{figure}[!htb]
1345 \footnotesize \centering
1346 \begin{minipage}[c]{15cm}
1347 \includestruct{listati/aiocb.h}
1350 \caption{La struttura \structd{aiocb}, usata per il controllo dell'I/O
1352 \label{fig:file_aiocb}
1355 Le operazioni di I/O asincrono possono essere effettuate solo su un file già
1356 aperto; il file deve inoltre supportare la funzione \func{lseek}, pertanto
1357 terminali e pipe sono esclusi. Non c'è limite al numero di operazioni
1358 contemporanee effettuabili su un singolo file. Ogni operazione deve
1359 inizializzare opportunamente un \textit{control block}. Il file descriptor su
1360 cui operare deve essere specificato tramite il campo \var{aio\_fildes}; dato
1361 che più operazioni possono essere eseguita in maniera asincrona, il concetto
1362 di posizione corrente sul file viene a mancare; pertanto si deve sempre
1363 specificare nel campo \var{aio\_offset} la posizione sul file da cui i dati
1364 saranno letti o scritti. Nel campo \var{aio\_buf} deve essere specificato
1365 l'indirizzo del buffer usato per l'I/O, ed in \var{aio\_nbytes} la lunghezza
1366 del blocco di dati da trasferire.
1368 Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni
1369 di I/O.\footnote{in generale perché ciò sia possibile occorre che la
1370 piattaforma supporti questa caratteristica, questo viene indicato definendo
1371 le macro \macro{\_POSIX\_PRIORITIZED\_IO}, e
1372 \macro{\_POSIX\_PRIORITY\_SCHEDULING}.} La priorità viene impostata a
1373 partire da quella del processo chiamante (vedi sez.~\ref{sec:proc_priority}),
1374 cui viene sottratto il valore di questo campo. Il campo
1375 \var{aio\_lio\_opcode} è usato solo dalla funzione \func{lio\_listio}, che,
1376 come vedremo, permette di eseguire con una sola chiamata una serie di
1377 operazioni, usando un vettore di \textit{control block}. Tramite questo campo
1378 si specifica quale è la natura di ciascuna di esse.
1380 \begin{figure}[!htb]
1381 \footnotesize \centering
1382 \begin{minipage}[c]{15cm}
1383 \includestruct{listati/sigevent.h}
1386 \caption{La struttura \structd{sigevent}, usata per specificare le modalità
1387 di notifica degli eventi relativi alle operazioni di I/O asincrono.}
1388 \label{fig:file_sigevent}
1391 Infine il campo \var{aio\_sigevent} è una struttura di tipo \struct{sigevent}
1392 che serve a specificare il modo in cui si vuole che venga effettuata la
1393 notifica del completamento delle operazioni richieste. La struttura è
1394 riportata in fig.~\ref{fig:file_sigevent}; il campo \var{sigev\_notify} è
1395 quello che indica le modalità della notifica, esso può assumere i tre valori:
1396 \begin{basedescript}{\desclabelwidth{2.6cm}}
1397 \item[\const{SIGEV\_NONE}] Non viene inviata nessuna notifica.
1398 \item[\const{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo
1399 chiamante il segnale specificato da \var{sigev\_signo}; se il gestore di
1400 questo è stato installato con \const{SA\_SIGINFO} gli verrà restituito il
1401 valore di \var{sigev\_value} (la cui definizione è in
1402 fig.~\ref{fig:sig_sigval}) come valore del campo \var{si\_value} di
1403 \struct{siginfo\_t}.
1404 \item[\const{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo
1405 thread che esegue la funzione specificata da \var{sigev\_notify\_function}
1406 con argomento \var{sigev\_value}, e con gli attributi specificati da
1407 \var{sigev\_notify\_attribute}.
1410 Le due funzioni base dell'interfaccia per l'I/O asincrono sono
1411 \funcd{aio\_read} ed \funcd{aio\_write}. Esse permettono di richiedere una
1412 lettura od una scrittura asincrona di dati, usando la struttura \struct{aiocb}
1413 appena descritta; i rispettivi prototipi sono:
1417 \funcdecl{int aio\_read(struct aiocb *aiocbp)}
1418 Richiede una lettura asincrona secondo quanto specificato con \param{aiocbp}.
1420 \funcdecl{int aio\_write(struct aiocb *aiocbp)}
1421 Richiede una scrittura asincrona secondo quanto specificato con
1424 \bodydesc{Le funzioni restituiscono 0 in caso di successo, e -1 in caso di
1425 errore, nel qual caso \var{errno} assumerà uno dei valori:
1427 \item[\errcode{EBADF}] Si è specificato un file descriptor sbagliato.
1428 \item[\errcode{ENOSYS}] La funzione non è implementata.
1429 \item[\errcode{EINVAL}] Si è specificato un valore non valido per i campi
1430 \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}.
1431 \item[\errcode{EAGAIN}] La coda delle richieste è momentaneamente piena.
1436 Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la
1437 richiesta, o in caso di errore. Non è detto che gli errori \errcode{EBADF} ed
1438 \errcode{EINVAL} siano rilevati immediatamente al momento della chiamata,
1439 potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e
1440 scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che
1441 il file non sia stato aperto in \itindex{append~mode} \textit{append mode}
1442 (vedi sez.~\ref{sec:file_open}), nel qual caso le scritture vengono effettuate
1443 comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}.
1445 Si tenga inoltre presente che deallocare la memoria indirizzata da
1446 \param{aiocbp} o modificarne i valori prima della conclusione di una
1447 operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
1448 campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
1449 richiesta. Questo comporta che non si devono usare per \param{aiocbp}
1450 variabili automatiche e che non si deve riutilizzare la stessa struttura per
1451 un'altra operazione fintanto che la precedente non sia stata ultimata. In
1452 generale per ogni operazione si deve utilizzare una diversa struttura
1455 Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
1456 \func{aio\_write} non implica che le operazioni siano state effettivamente
1457 eseguite in maniera corretta; per verificarne l'esito l'interfaccia prevede
1458 altre due funzioni, che permettono di controllare lo stato di esecuzione. La
1459 prima è \funcd{aio\_error}, che serve a determinare un eventuale stato di
1460 errore; il suo prototipo è:
1461 \begin{prototype}{aio.h}
1462 {int aio\_error(const struct aiocb *aiocbp)}
1464 Determina lo stato di errore delle operazioni di I/O associate a
1467 \bodydesc{La funzione restituisce 0 se le operazioni si sono concluse con
1468 successo, altrimenti restituisce il codice di errore relativo al loro
1472 Se l'operazione non si è ancora completata viene restituito l'errore di
1473 \errcode{EINPROGRESS}. La funzione ritorna zero quando l'operazione si è
1474 conclusa con successo, altrimenti restituisce il codice dell'errore
1475 verificatosi, ed esegue la corrispondente impostazione di \var{errno}. Il
1476 codice può essere sia \errcode{EINVAL} ed \errcode{EBADF}, dovuti ad un valore
1477 errato per \param{aiocbp}, che uno degli errori possibili durante l'esecuzione
1478 dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda
1479 del caso, i codici di errore delle system call \func{read}, \func{write} e
1482 Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
1483 che una chiamata ad \func{aio\_error} non ha restituito
1484 \errcode{EINPROGRESS}), si potrà usare la funzione \funcd{aio\_return}, che
1485 permette di verificare il completamento delle operazioni di I/O asincrono; il
1487 \begin{prototype}{aio.h}
1488 {ssize\_t aio\_return(const struct aiocb *aiocbp)}
1490 Recupera il valore dello stato di ritorno delle operazioni di I/O associate a
1493 \bodydesc{La funzione restituisce lo stato di uscita dell'operazione
1497 La funzione deve essere chiamata una sola volte per ciascuna operazione
1498 asincrona, essa infatti fa sì che il sistema rilasci le risorse ad essa
1499 associate. É per questo motivo che occorre chiamare la funzione solo dopo che
1500 l'operazione cui \param{aiocbp} fa riferimento si è completata. Una chiamata
1501 precedente il completamento delle operazioni darebbe risultati indeterminati.
1503 La funzione restituisce il valore di ritorno relativo all'operazione eseguita,
1504 così come ricavato dalla sottostante system call (il numero di byte letti,
1505 scritti o il valore di ritorno di \func{fsync}). É importante chiamare sempre
1506 questa funzione, altrimenti le risorse disponibili per le operazioni di I/O
1507 asincrono non verrebbero liberate, rischiando di arrivare ad un loro
1510 Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a
1511 disposizione un'altra operazione, quella di sincronizzazione dell'I/O,
1512 compiuta dalla funzione \funcd{aio\_fsync}, che ha lo stesso effetto della
1513 analoga \func{fsync}, ma viene eseguita in maniera asincrona; il suo prototipo
1515 \begin{prototype}{aio.h}
1516 {int aio\_fsync(int op, struct aiocb *aiocbp)}
1518 Richiede la sincronizzazione dei dati per il file indicato da \param{aiocbp}.
1520 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1521 errore, che può essere, con le stesse modalità di \func{aio\_read},
1522 \errval{EAGAIN}, \errval{EBADF} o \errval{EINVAL}.}
1525 La funzione richiede la sincronizzazione delle operazioni di I/O, ritornando
1526 immediatamente. L'esecuzione effettiva della sincronizzazione dovrà essere
1527 verificata con \func{aio\_error} e \func{aio\_return} come per le operazioni
1528 di lettura e scrittura. L'argomento \param{op} permette di indicare la
1529 modalità di esecuzione, se si specifica il valore \const{O\_DSYNC} le
1530 operazioni saranno completate con una chiamata a \func{fdatasync}, se si
1531 specifica \const{O\_SYNC} con una chiamata a \func{fsync} (per i dettagli vedi
1532 sez.~\ref{sec:file_sync}).
1534 Il successo della chiamata assicura la sincronizzazione delle operazioni fino
1535 allora richieste, niente è garantito riguardo la sincronizzazione dei dati
1536 relativi ad eventuali operazioni richieste successivamente. Se si è
1537 specificato un meccanismo di notifica questo sarà innescato una volta che le
1538 operazioni di sincronizzazione dei dati saranno completate.
1540 In alcuni casi può essere necessario interrompere le operazioni (in genere
1541 quando viene richiesta un'uscita immediata dal programma), per questo lo
1542 standard POSIX.1b prevede una funzioni apposita, \funcd{aio\_cancel}, che
1543 permette di cancellare una operazione richiesta in precedenza; il suo
1545 \begin{prototype}{aio.h}
1546 {int aio\_cancel(int fildes, struct aiocb *aiocbp)}
1548 Richiede la cancellazione delle operazioni sul file \param{fildes} specificate
1551 \bodydesc{La funzione restituisce il risultato dell'operazione con un codice
1552 di positivo, e -1 in caso di errore, che avviene qualora si sia specificato
1553 un valore non valido di \param{fildes}, imposta \var{errno} al valore
1557 La funzione permette di cancellare una operazione specifica sul file
1558 \param{fildes}, o tutte le operazioni pendenti, specificando \val{NULL} come
1559 valore di \param{aiocbp}. Quando una operazione viene cancellata una
1560 successiva chiamata ad \func{aio\_error} riporterà \errcode{ECANCELED} come
1561 codice di errore, ed il suo codice di ritorno sarà -1, inoltre il meccanismo
1562 di notifica non verrà invocato. Se si specifica una operazione relativa ad un
1563 altro file descriptor il risultato è indeterminato. In caso di successo, i
1564 possibili valori di ritorno per \func{aio\_cancel} (anch'essi definiti in
1565 \file{aio.h}) sono tre:
1566 \begin{basedescript}{\desclabelwidth{3.0cm}}
1567 \item[\const{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
1568 cancellazione sono state già completate,
1570 \item[\const{AIO\_CANCELED}] indica che tutte le operazioni richieste sono
1573 \item[\const{AIO\_NOTCANCELED}] indica che alcune delle operazioni erano in
1574 corso e non sono state cancellate.
1577 Nel caso si abbia \const{AIO\_NOTCANCELED} occorrerà chiamare
1578 \func{aio\_error} per determinare quali sono le operazioni effettivamente
1579 cancellate. Le operazioni che non sono state cancellate proseguiranno il loro
1580 corso normale, compreso quanto richiesto riguardo al meccanismo di notifica
1581 del loro avvenuto completamento.
1583 Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia
1584 fornisce anche una apposita funzione, \funcd{aio\_suspend}, che permette di
1585 sospendere l'esecuzione del processo chiamante fino al completamento di una
1586 specifica operazione; il suo prototipo è:
1587 \begin{prototype}{aio.h}
1588 {int aio\_suspend(const struct aiocb * const list[], int nent, const struct
1591 Attende, per un massimo di \param{timeout}, il completamento di una delle
1592 operazioni specificate da \param{list}.
1594 \bodydesc{La funzione restituisce 0 se una (o più) operazioni sono state
1595 completate, e -1 in caso di errore nel qual caso \var{errno} assumerà uno
1598 \item[\errcode{EAGAIN}] Nessuna operazione è stata completata entro
1600 \item[\errcode{ENOSYS}] La funzione non è implementata.
1601 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
1606 La funzione permette di bloccare il processo fintanto che almeno una delle
1607 \param{nent} operazioni specificate nella lista \param{list} è completata, per
1608 un tempo massimo specificato da \param{timout}, o fintanto che non arrivi un
1609 segnale.\footnote{si tenga conto che questo segnale può anche essere quello
1610 utilizzato come meccanismo di notifica.} La lista deve essere inizializzata
1611 con delle strutture \struct{aiocb} relative ad operazioni effettivamente
1612 richieste, ma può contenere puntatori nulli, che saranno ignorati. In caso si
1613 siano specificati valori non validi l'effetto è indefinito. Un valore
1614 \val{NULL} per \param{timout} comporta l'assenza di timeout.
1616 Lo standard POSIX.1b infine ha previsto pure una funzione, \funcd{lio\_listio},
1617 che permette di effettuare la richiesta di una intera lista di operazioni di
1618 lettura o scrittura; il suo prototipo è:
1619 \begin{prototype}{aio.h}
1620 {int lio\_listio(int mode, struct aiocb * const list[], int nent, struct
1623 Richiede l'esecuzione delle operazioni di I/O elencata da \param{list},
1624 secondo la modalità \param{mode}.
1626 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
1627 errore, nel qual caso \var{errno} assumerà uno dei valori:
1629 \item[\errcode{EAGAIN}] Nessuna operazione è stata completata entro
1631 \item[\errcode{EINVAL}] Si è passato un valore di \param{mode} non valido
1632 o un numero di operazioni \param{nent} maggiore di
1633 \const{AIO\_LISTIO\_MAX}.
1634 \item[\errcode{ENOSYS}] La funzione non è implementata.
1635 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
1640 La funzione esegue la richiesta delle \param{nent} operazioni indicate nella
1641 lista \param{list} che deve contenere gli indirizzi di altrettanti
1642 \textit{control block} opportunamente inizializzati; in particolare dovrà
1643 essere specificato il tipo di operazione con il campo \var{aio\_lio\_opcode},
1644 che può prendere i valori:
1645 \begin{basedescript}{\desclabelwidth{2.0cm}}
1646 \item[\const{LIO\_READ}] si richiede una operazione di lettura.
1647 \item[\const{LIO\_WRITE}] si richiede una operazione di scrittura.
1648 \item[\const{LIO\_NOP}] non si effettua nessuna operazione.
1650 dove \const{LIO\_NOP} viene usato quando si ha a che fare con un vettore di
1651 dimensione fissa, per poter specificare solo alcune operazioni, o quando si
1652 sono dovute cancellare delle operazioni e si deve ripetere la richiesta per
1653 quelle non completate.
1655 L'argomento \param{mode} controlla il comportamento della funzione, se viene
1656 usato il valore \const{LIO\_WAIT} la funzione si blocca fino al completamento
1657 di tutte le operazioni richieste; se si usa \const{LIO\_NOWAIT} la funzione
1658 ritorna immediatamente dopo aver messo in coda tutte le richieste. In tal caso
1659 il chiamante può richiedere la notifica del completamento di tutte le
1660 richieste, impostando l'argomento \param{sig} in maniera analoga a come si fa
1661 per il campo \var{aio\_sigevent} di \struct{aiocb}.
1664 \section{Altre modalità di I/O avanzato}
1665 \label{sec:file_advanced_io}
1667 Oltre alle precedenti modalità di \textit{I/O multiplexing} e \textsl{I/O
1668 asincrono}, esistono altre funzioni che implementano delle modalità di
1669 accesso ai file più evolute rispetto alle normali funzioni di lettura e
1670 scrittura che abbiamo esaminato in sez.~\ref{sec:file_base_func}. In questa
1671 sezione allora prenderemo in esame le interfacce per l'\textsl{I/O
1672 vettorizzato} e per l'\textsl{I/O mappato in memoria} e la funzione
1676 \subsection{I/O vettorizzato}
1677 \label{sec:file_multiple_io}
1679 Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una
1680 serie multipla di operazioni di I/O, come una serie di letture o scritture di
1681 vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di
1682 una struttura ed essi devono essere caricati o salvati su un file. Benché
1683 l'operazione sia facilmente eseguibile attraverso una serie multipla di
1684 chiamate, ci sono casi in cui si vuole poter contare sulla atomicità delle
1687 Per questo motivo BSD 4.2\footnote{Le due funzioni sono riprese da BSD4.4 ed
1688 integrate anche dallo standard Unix 98. Fino alle libc5, Linux usava
1689 \type{size\_t} come tipo dell'argomento \param{count}, una scelta logica,
1690 che però è stata dismessa per restare aderenti allo standard.} ha introdotto
1691 due nuove system call, \funcd{readv} e \funcd{writev}, che permettono di
1692 effettuare con una sola chiamata una lettura o una scrittura su una serie di
1693 buffer (quello che viene chiamato \textsl{I/O vettorizzato}. I relativi
1696 \headdecl{sys/uio.h}
1698 \funcdecl{int readv(int fd, const struct iovec *vector, int count)}
1699 \funcdecl{int writev(int fd, const struct iovec *vector, int count)}
1701 Eseguono rispettivamente una lettura o una scrittura vettorizzata.
1703 \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti in
1704 caso di successo, e -1 in caso di errore, nel qual caso \var{errno}
1705 assumerà uno dei valori:
1707 \item[\errcode{EINVAL}] si è specificato un valore non valido per uno degli
1708 argomenti (ad esempio \param{count} è maggiore di \const{MAX\_IOVEC}).
1709 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di
1710 di avere eseguito una qualunque lettura o scrittura.
1711 \item[\errcode{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e
1712 non ci sono dati in lettura.
1713 \item[\errcode{EOPNOTSUPP}] la coda delle richieste è momentaneamente piena.
1715 ed anche \errval{EISDIR}, \errval{EBADF}, \errval{ENOMEM}, \errval{EFAULT}
1716 (se non sono stati allocati correttamente i buffer specificati nei campi
1717 \var{iov\_base}), più gli eventuali errori delle funzioni di lettura e
1718 scrittura eseguite su \param{fd}.}
1721 Entrambe le funzioni usano una struttura \struct{iovec}, la cui definizione è
1722 riportata in fig.~\ref{fig:file_iovec}, che definisce dove i dati devono
1723 essere letti o scritti ed in che quantità. Il primo campo della struttura,
1724 \var{iov\_base}, contiene l'indirizzo del buffer ed il secondo,
1725 \var{iov\_len}, la dimensione dello stesso.
1727 \begin{figure}[!htb]
1728 \footnotesize \centering
1729 \begin{minipage}[c]{15cm}
1730 \includestruct{listati/iovec.h}
1733 \caption{La struttura \structd{iovec}, usata dalle operazioni di I/O
1735 \label{fig:file_iovec}
1738 La lista dei buffer da utilizzare viene indicata attraverso l'argomento
1739 \param{vector} che è un vettore di strutture \struct{iovec}, la cui lunghezza
1740 è specificata dall'argomento \param{count}. Ciascuna struttura dovrà essere
1741 inizializzata opportunamente per indicare i vari buffer da e verso i quali
1742 verrà eseguito il trasferimento dei dati. Essi verranno letti (o scritti)
1743 nell'ordine in cui li si sono specificati nel vettore \param{vector}.
1746 \subsection{File mappati in memoria}
1747 \label{sec:file_memory_map}
1749 \itindbeg{memory~mapping}
1750 Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
1751 rispetto a quella classica vista in cap.~\ref{cha:file_unix_interface}, è il
1752 cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della
1753 \textsl{paginazione} \index{paginazione} usato dalla memoria virtuale (vedi
1754 sez.~\ref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un
1755 file in una sezione dello spazio di indirizzi del processo.
1759 \includegraphics[width=10cm]{img/mmap_layout}
1760 \caption{Disposizione della memoria di un processo quando si esegue la
1761 mappatura in memoria di un file.}
1762 \label{fig:file_mmap_layout}
1765 Il meccanismo è illustrato in fig.~\ref{fig:file_mmap_layout}, una sezione del
1766 file viene \textsl{mappata} direttamente nello spazio degli indirizzi del
1767 programma. Tutte le operazioni di lettura e scrittura su variabili contenute
1768 in questa zona di memoria verranno eseguite leggendo e scrivendo dal contenuto
1769 del file attraverso il sistema della memoria virtuale \index{memoria~virtuale}
1770 che in maniera analoga a quanto avviene per le pagine che vengono salvate e
1771 rilette nella swap, si incaricherà di sincronizzare il contenuto di quel
1772 segmento di memoria con quello del file mappato su di esso. Per questo motivo
1773 si può parlare tanto di \textsl{file mappato in memoria}, quanto di
1774 \textsl{memoria mappata su file}.
1776 L'uso del \textit{memory-mapping} comporta una notevole semplificazione delle
1777 operazioni di I/O, in quanto non sarà più necessario utilizzare dei buffer
1778 intermedi su cui appoggiare i dati da traferire, poiché questi potranno essere
1779 acceduti direttamente nella sezione di memoria mappata; inoltre questa
1780 interfaccia è più efficiente delle usuali funzioni di I/O, in quanto permette
1781 di caricare in memoria solo le parti del file che sono effettivamente usate ad
1784 Infatti, dato che l'accesso è fatto direttamente attraverso la
1785 \index{memoria~virtuale} memoria virtuale, la sezione di memoria mappata su
1786 cui si opera sarà a sua volta letta o scritta sul file una pagina alla volta e
1787 solo per le parti effettivamente usate, il tutto in maniera completamente
1788 trasparente al processo; l'accesso alle pagine non ancora caricate avverrà
1789 allo stesso modo con cui vengono caricate in memoria le pagine che sono state
1792 Infine in situazioni in cui la memoria è scarsa, le pagine che mappano un file
1793 vengono salvate automaticamente, così come le pagine dei programmi vengono
1794 scritte sulla swap; questo consente di accedere ai file su dimensioni il cui
1795 solo limite è quello dello spazio di indirizzi disponibile, e non della
1796 memoria su cui possono esserne lette delle porzioni.
1798 L'interfaccia POSIX implementata da Linux prevede varie funzioni per la
1799 gestione del \textit{memory mapped I/O}, la prima di queste, che serve ad
1800 eseguire la mappatura in memoria di un file, è \funcd{mmap}; il suo prototipo
1805 \headdecl{sys/mman.h}
1807 \funcdecl{void * mmap(void * start, size\_t length, int prot, int flags, int
1810 Esegue la mappatura in memoria della sezione specificata del file \param{fd}.
1812 \bodydesc{La funzione restituisce il puntatore alla zona di memoria mappata
1813 in caso di successo, e \const{MAP\_FAILED} (-1) in caso di errore, nel
1814 qual caso \var{errno} assumerà uno dei valori:
1816 \item[\errcode{EBADF}] Il file descriptor non è valido, e non si è usato
1817 \const{MAP\_ANONYMOUS}.
1818 \item[\errcode{EACCES}] o \param{fd} non si riferisce ad un file regolare,
1819 o si è usato \const{MAP\_PRIVATE} ma \param{fd} non è aperto in lettura,
1820 o si è usato \const{MAP\_SHARED} e impostato \const{PROT\_WRITE} ed
1821 \param{fd} non è aperto in lettura/scrittura, o si è impostato
1822 \const{PROT\_WRITE} ed \param{fd} è in \textit{append-only}.
1823 \item[\errcode{EINVAL}] I valori di \param{start}, \param{length} o
1824 \param{offset} non sono validi (o troppo grandi o non allineati sulla
1825 dimensione delle pagine).
1826 \item[\errcode{ETXTBSY}] Si è impostato \const{MAP\_DENYWRITE} ma
1827 \param{fd} è aperto in scrittura.
1828 \item[\errcode{EAGAIN}] Il file è bloccato, o si è bloccata troppa memoria
1829 rispetto a quanto consentito dai limiti di sistema (vedi
1830 sez.~\ref{sec:sys_resource_limit}).
1831 \item[\errcode{ENOMEM}] Non c'è memoria o si è superato il limite sul
1832 numero di mappature possibili.
1833 \item[\errcode{ENODEV}] Il filesystem di \param{fd} non supporta il memory
1835 \item[\errcode{EPERM}] L'argomento \param{prot} ha richiesto
1836 \const{PROT\_EXEC}, ma il filesystem di \param{fd} è montato con
1837 l'opzione \texttt{noexec}.
1838 \item[\errcode{ENFILE}] Si è superato il limite del sistema sul numero di
1839 file aperti (vedi sez.~\ref{sec:sys_resource_limit}).
1844 La funzione richiede di mappare in memoria la sezione del file \param{fd} a
1845 partire da \param{offset} per \param{lenght} byte, preferibilmente
1846 all'indirizzo \param{start}. Il valore di \param{offset} deve essere un
1847 multiplo della dimensione di una pagina di memoria.
1853 \begin{tabular}[c]{|l|l|}
1855 \textbf{Valore} & \textbf{Significato} \\
1858 \const{PROT\_EXEC} & Le pagine possono essere eseguite.\\
1859 \const{PROT\_READ} & Le pagine possono essere lette.\\
1860 \const{PROT\_WRITE} & Le pagine possono essere scritte.\\
1861 \const{PROT\_NONE} & L'accesso alle pagine è vietato.\\
1864 \caption{Valori dell'argomento \param{prot} di \func{mmap}, relativi alla
1865 protezione applicate alle pagine del file mappate in memoria.}
1866 \label{tab:file_mmap_prot}
1870 Il valore dell'argomento \param{prot} indica la protezione\footnote{in Linux
1871 la memoria reale è divisa in pagine: ogni processo vede la sua memoria
1872 attraverso uno o più segmenti lineari di memoria virtuale. Per ciascuno di
1873 questi segmenti il kernel mantiene nella \itindex{page~table} \textit{page
1874 table} la mappatura sulle pagine di memoria reale, ed le modalità di
1875 accesso (lettura, esecuzione, scrittura); una loro violazione causa quella
1876 che si chiama una \textit{segment violation}, e la relativa emissione del
1877 segnale \const{SIGSEGV}.} da applicare al segmento di memoria e deve essere
1878 specificato come maschera binaria ottenuta dall'OR di uno o più dei valori
1879 riportati in tab.~\ref{tab:file_mmap_flag}; il valore specificato deve essere
1880 compatibile con la modalità di accesso con cui si è aperto il file.
1882 L'argomento \param{flags} specifica infine qual è il tipo di oggetto mappato,
1883 le opzioni relative alle modalità con cui è effettuata la mappatura e alle
1884 modalità con cui le modifiche alla memoria mappata vengono condivise o
1885 mantenute private al processo che le ha effettuate. Deve essere specificato
1886 come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in
1887 tab.~\ref{tab:file_mmap_flag}.
1892 \begin{tabular}[c]{|l|p{11cm}|}
1894 \textbf{Valore} & \textbf{Significato} \\
1897 \const{MAP\_FIXED} & Non permette di restituire un indirizzo diverso
1898 da \param{start}, se questo non può essere usato
1899 \func{mmap} fallisce. Se si imposta questo flag il
1900 valore di \param{start} deve essere allineato
1901 alle dimensioni di una pagina. \\
1902 \const{MAP\_SHARED} & I cambiamenti sulla memoria mappata vengono
1903 riportati sul file e saranno immediatamente
1904 visibili agli altri processi che mappano lo stesso
1905 file.\footnotemark Il file su disco però non sarà
1906 aggiornato fino alla chiamata di \func{msync} o
1907 \func{munmap}), e solo allora le modifiche saranno
1908 visibili per l'I/O convenzionale. Incompatibile
1909 con \const{MAP\_PRIVATE}. \\
1910 \const{MAP\_PRIVATE} & I cambiamenti sulla memoria mappata non vengono
1911 riportati sul file. Ne viene fatta una copia
1912 privata cui solo il processo chiamante ha
1913 accesso. Le modifiche sono mantenute attraverso
1914 il meccanismo del \textit{copy on
1915 write} \itindex{copy~on~write} e
1916 salvate su swap in caso di necessità. Non è
1917 specificato se i cambiamenti sul file originale
1918 vengano riportati sulla regione
1919 mappata. Incompatibile con \const{MAP\_SHARED}. \\
1920 \const{MAP\_DENYWRITE} & In Linux viene ignorato per evitare
1921 \textit{DoS} \itindex{Denial~of~Service~(DoS)}
1922 (veniva usato per segnalare che tentativi di
1923 scrittura sul file dovevano fallire con
1924 \errcode{ETXTBSY}).\\
1925 \const{MAP\_EXECUTABLE}& Ignorato. \\
1926 \const{MAP\_NORESERVE} & Si usa con \const{MAP\_PRIVATE}. Non riserva
1927 delle pagine di swap ad uso del meccanismo del
1928 \textit{copy on write} \itindex{copy~on~write}
1930 modifiche fatte alla regione mappata, in
1931 questo caso dopo una scrittura, se non c'è più
1932 memoria disponibile, si ha l'emissione di
1933 un \const{SIGSEGV}. \\
1934 \const{MAP\_LOCKED} & Se impostato impedisce lo swapping delle pagine
1936 \const{MAP\_GROWSDOWN} & Usato per gli \itindex{stack} stack. Indica
1937 che la mappatura deve essere effettuata con gli
1938 indirizzi crescenti verso il basso.\\
1939 \const{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
1940 argomenti \param{fd} e \param{offset} sono
1941 ignorati.\footnotemark\\
1942 \const{MAP\_ANON} & Sinonimo di \const{MAP\_ANONYMOUS}, deprecato.\\
1943 \const{MAP\_FILE} & Valore di compatibilità, ignorato.\\
1944 \const{MAP\_32BIT} & Esegue la mappatura sui primi 2GiB dello spazio
1945 degli indirizzi, viene supportato solo sulle
1946 piattaforme \texttt{x86-64} per compatibilità con
1947 le applicazioni a 32 bit. Viene ignorato se si è
1948 richiesto \const{MAP\_FIXED}.\\
1949 \const{MAP\_POPULATE} & Esegue il \itindex{prefaulting}
1950 \textit{prefaulting} delle pagine di memoria
1951 necessarie alla mappatura. \\
1952 \const{MAP\_NONBLOCK} & Esegue un \textit{prefaulting} più limitato che
1953 non causa I/O.\footnotemark \\
1954 % \const{MAP\_DONTEXPAND}& Non consente una successiva espansione dell'area
1955 % mappata con \func{mremap}, proposto ma pare non
1959 \caption{Valori possibili dell'argomento \param{flag} di \func{mmap}.}
1960 \label{tab:file_mmap_flag}
1964 Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere
1965 piuttosto complessi, essi si possono comprendere solo tenendo presente che
1966 tutto quanto è comunque basato sul meccanismo della \index{memoria~virtuale}
1967 memoria virtuale. Questo comporta allora una serie di conseguenze. La più
1968 ovvia è che se si cerca di scrivere su una zona mappata in sola lettura si
1969 avrà l'emissione di un segnale di violazione di accesso (\const{SIGSEGV}),
1970 dato che i permessi sul segmento di memoria relativo non consentono questo
1973 È invece assai diversa la questione relativa agli accessi al di fuori della
1974 regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe
1975 ritenere che anch'essi debbano generare un segnale di violazione di accesso;
1976 questo però non tiene conto del fatto che, essendo basata sul meccanismo della
1977 paginazione \index{paginazione}, la mappatura in memoria non può che essere
1978 eseguita su un segmento di dimensioni rigorosamente multiple di quelle di una
1979 pagina, ed in generale queste potranno non corrispondere alle dimensioni
1980 effettive del file o della sezione che si vuole mappare.
1982 \footnotetext[20]{Dato che tutti faranno riferimento alle stesse pagine di
1985 \footnotetext[21]{L'uso di questo flag con \const{MAP\_SHARED} è stato
1986 implementato in Linux a partire dai kernel della serie 2.4.x; esso consente
1987 di creare segmenti di memoria condivisa e torneremo sul suo utilizzo in
1988 sez.~\ref{sec:ipc_mmap_anonymous}.}
1990 \footnotetext{questo flag ed il precedente \const{MAP\_POPULATE} sono stati
1991 introdotti nel kernel 2.5.46 insieme alla mappatura non lineare di cui
1992 parleremo più avanti.}
1994 \begin{figure}[!htb]
1996 \includegraphics[width=12cm]{img/mmap_boundary}
1997 \caption{Schema della mappatura in memoria di una sezione di file di
1998 dimensioni non corrispondenti al bordo di una pagina.}
1999 \label{fig:file_mmap_boundary}
2003 Il caso più comune è quello illustrato in fig.~\ref{fig:file_mmap_boundary},
2004 in cui la sezione di file non rientra nei confini di una pagina: in tal caso
2005 verrà il file sarà mappato su un segmento di memoria che si estende fino al
2006 bordo della pagina successiva.
2008 In questo caso è possibile accedere a quella zona di memoria che eccede le
2009 dimensioni specificate da \param{lenght}, senza ottenere un \const{SIGSEGV}
2010 poiché essa è presente nello spazio di indirizzi del processo, anche se non è
2011 mappata sul file. Il comportamento del sistema è quello di restituire un
2012 valore nullo per quanto viene letto, e di non riportare su file quanto viene
2015 Un caso più complesso è quello che si viene a creare quando le dimensioni del
2016 file mappato sono più corte delle dimensioni della mappatura, oppure quando il
2017 file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a
2018 quella della mappatura in memoria.
2020 In questa situazione, per la sezione di pagina parzialmente coperta dal
2021 contenuto del file, vale esattamente quanto visto in precedenza; invece per la
2022 parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non
2023 sarà più possibile, ma il segnale emesso non sarà \const{SIGSEGV}, ma
2024 \const{SIGBUS}, come illustrato in fig.~\ref{fig:file_mmap_exceed}.
2026 Non tutti i file possono venire mappati in memoria, dato che, come illustrato
2027 in fig.~\ref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza
2028 biunivoca fra una sezione di un file ed una sezione di memoria. Questo
2029 comporta che ad esempio non è possibile mappare in memoria file descriptor
2030 relativi a pipe, socket e fifo, per i quali non ha senso parlare di
2031 \textsl{sezione}. Lo stesso vale anche per alcuni file di dispositivo, che non
2032 dispongono della relativa operazione \func{mmap} (si ricordi quanto esposto in
2033 sez.~\ref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi
2034 di dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe)
2035 che sono utilizzabili solo con questa interfaccia.
2039 \includegraphics[width=12cm]{img/mmap_exceed}
2040 \caption{Schema della mappatura in memoria di file di dimensioni inferiori
2041 alla lunghezza richiesta.}
2042 \label{fig:file_mmap_exceed}
2045 Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene
2046 copiato integralmente, i file mappati in memoria verranno ereditati in maniera
2047 trasparente dal processo figlio, mantenendo gli stessi attributi avuti nel
2048 padre; così se si è usato \const{MAP\_SHARED} padre e figlio accederanno allo
2049 stesso file in maniera condivisa, mentre se si è usato \const{MAP\_PRIVATE}
2050 ciascuno di essi manterrà una sua versione privata indipendente. Non c'è
2051 invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima
2052 sostituisce tutto lo spazio degli indirizzi di un processo con quello di un
2055 Quando si effettua la mappatura di un file vengono pure modificati i tempi ad
2056 esso associati (di cui si è trattato in sez.~\ref{sec:file_file_times}). Il
2057 valore di \var{st\_atime} può venir cambiato in qualunque istante a partire
2058 dal momento in cui la mappatura è stata effettuata: il primo riferimento ad
2059 una pagina mappata su un file aggiorna questo tempo. I valori di
2060 \var{st\_ctime} e \var{st\_mtime} possono venir cambiati solo quando si è
2061 consentita la scrittura sul file (cioè per un file mappato con
2062 \const{PROT\_WRITE} e \const{MAP\_SHARED}) e sono aggiornati dopo la scrittura
2063 o in corrispondenza di una eventuale \func{msync}.
2065 Dato per i file mappati in memoria le operazioni di I/O sono gestite
2066 direttamente dalla \index{memoria~virtuale}memoria virtuale, occorre essere
2067 consapevoli delle interazioni che possono esserci con operazioni effettuate
2068 con l'interfaccia standard dei file di cap.~\ref{cha:file_unix_interface}. Il
2069 problema è che una volta che si è mappato un file, le operazioni di lettura e
2070 scrittura saranno eseguite sulla memoria, e riportate su disco in maniera
2071 autonoma dal sistema della memoria virtuale.
2073 Pertanto se si modifica un file con l'interfaccia standard queste modifiche
2074 potranno essere visibili o meno a seconda del momento in cui la memoria
2075 virtuale trasporterà dal disco in memoria quella sezione del file, perciò è
2076 del tutto imprevedibile il risultato della modifica di un file nei confronti
2077 del contenuto della memoria su cui è mappato.
2079 Per questo, è sempre sconsigliabile eseguire scritture su file attraverso
2080 l'interfaccia standard, quando lo si è mappato in memoria, è invece possibile
2081 usare l'interfaccia standard per leggere un file mappato in memoria, purché si
2082 abbia una certa cura; infatti l'interfaccia dell'I/O mappato in memoria mette
2083 a disposizione la funzione \funcd{msync} per sincronizzare il contenuto della
2084 memoria mappata con il file su disco; il suo prototipo è:
2087 \headdecl{sys/mman.h}
2089 \funcdecl{int msync(const void *start, size\_t length, int flags)}
2091 Sincronizza i contenuti di una sezione di un file mappato in memoria.
2093 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2094 errore nel qual caso \var{errno} assumerà uno dei valori:
2096 \item[\errcode{EINVAL}] O \param{start} non è multiplo di
2097 \const{PAGE\_SIZE}, o si è specificato un valore non valido per
2099 \item[\errcode{EFAULT}] L'intervallo specificato non ricade in una zona
2100 precedentemente mappata.
2105 La funzione esegue la sincronizzazione di quanto scritto nella sezione di
2106 memoria indicata da \param{start} e \param{offset}, scrivendo le modifiche sul
2107 file (qualora questo non sia già stato fatto). Provvede anche ad aggiornare i
2108 relativi tempi di modifica. In questo modo si è sicuri che dopo l'esecuzione
2109 di \func{msync} le funzioni dell'interfaccia standard troveranno un contenuto
2110 del file aggiornato.
2115 \begin{tabular}[c]{|l|l|}
2117 \textbf{Valore} & \textbf{Significato} \\
2120 \const{MS\_ASYNC} & Richiede la sincronizzazione.\\
2121 \const{MS\_SYNC} & Attende che la sincronizzazione si eseguita.\\
2122 \const{MS\_INVALIDATE}& Richiede che le altre mappature dello stesso file
2126 \caption{Valori dell'argomento \param{flag} di \func{msync}.}
2127 \label{tab:file_mmap_rsync}
2130 L'argomento \param{flag} è specificato come maschera binaria composta da un OR
2131 dei valori riportati in tab.~\ref{tab:file_mmap_rsync}, di questi però
2132 \const{MS\_ASYNC} e \const{MS\_SYNC} sono incompatibili; con il primo valore
2133 infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al
2134 meccanismo della memoria virtuale, ritornando subito, mentre con il secondo
2135 attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo
2136 flag fa invalidare le pagine di cui si richiede la sincronizzazione per tutte
2137 le mappature dello stesso file, così che esse possano essere immediatamente
2138 aggiornate ai nuovi valori.
2140 Una volta che si sono completate le operazioni di I/O si può eliminare la
2141 mappatura della memoria usando la funzione \funcd{munmap}, il suo prototipo è:
2144 \headdecl{sys/mman.h}
2146 \funcdecl{int munmap(void *start, size\_t length)}
2148 Rilascia la mappatura sulla sezione di memoria specificata.
2150 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2151 errore nel qual caso \var{errno} assumerà uno dei valori:
2153 \item[\errcode{EINVAL}] L'intervallo specificato non ricade in una zona
2154 precedentemente mappata.
2159 La funzione cancella la mappatura per l'intervallo specificato con
2160 \param{start} e \param{length}; ogni successivo accesso a tale regione causerà
2161 un errore di accesso in memoria. L'argomento \param{start} deve essere
2162 allineato alle dimensioni di una pagina, e la mappatura di tutte le pagine
2163 contenute anche parzialmente nell'intervallo indicato, verrà rimossa.
2164 Indicare un intervallo che non contiene mappature non è un errore. Si tenga
2165 presente inoltre che alla conclusione di un processo ogni pagina mappata verrà
2166 automaticamente rilasciata, mentre la chiusura del file descriptor usato per
2167 il \textit{memory mapping} non ha alcun effetto su di esso.
2169 Lo standard POSIX prevede anche una funzione che permetta di cambiare le
2170 protezioni delle pagine di memoria; lo standard prevede che essa si applichi
2171 solo ai \textit{memory mapping} creati con \func{mmap}, ma nel caso di Linux
2172 la funzione può essere usata con qualunque pagina valida nella memoria
2173 virtuale. Questa funzione è \funcd{mprotect} ed il suo prototipo è:
2175 % \headdecl{unistd.h}
2176 \headdecl{sys/mman.h}
2178 \funcdecl{int mprotect(const void *addr, size\_t len, int prot)}
2180 Modifica le protezioni delle pagine di memoria comprese nell'intervallo
2183 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2184 errore nel qual caso \var{errno} assumerà uno dei valori:
2186 \item[\errcode{EINVAL}] il valore di \param{addr} non è valido o non è un
2187 multiplo di \const{PAGE\_SIZE}.
2188 \item[\errcode{EACCESS}] l'operazione non è consentita, ad esempio si è
2189 cercato di marcare con \const{PROT\_WRITE} un segmento di memoria cui si
2190 ha solo accesso in lettura.
2191 % \item[\errcode{ENOMEM}] non è stato possibile allocare le risorse
2192 % necessarie all'interno del kernel.
2193 % \item[\errcode{EFAULT}] si è specificato un indirizzo di memoria non
2196 ed inoltre \errval{ENOMEM} ed \errval{EFAULT}.
2201 La funzione prende come argomenti un indirizzo di partenza in \param{addr},
2202 allineato alle dimensioni delle pagine di memoria, ed una dimensione
2203 \param{size}. La nuova protezione deve essere specificata in \param{prot} con
2204 una combinazione dei valori di tab.~\ref{tab:file_mmap_prot}. La nuova
2205 protezione verrà applicata a tutte le pagine contenute, anche parzialmente,
2206 dall'intervallo fra \param{addr} e \param{addr}+\param{size}-1.
2208 Infine Linux supporta alcune operazioni specifiche non disponibili su altri
2209 kernel unix-like. La prima di queste è la possibilità di modificare un
2210 precedente \textit{memory mapping}, ad esempio per espanderlo o restringerlo.
2211 Questo è realizzato dalla funzione \funcd{mremap}, il cui prototipo è:
2214 \headdecl{sys/mman.h}
2216 \funcdecl{void * mremap(void *old\_address, size\_t old\_size , size\_t
2217 new\_size, unsigned long flags)}
2219 Restringe o allarga una mappatura in memoria di un file.
2221 \bodydesc{La funzione restituisce l'indirizzo alla nuova area di memoria in
2222 caso di successo od il valore \const{MAP\_FAILED} (pari a \texttt{(void *)
2223 -1}) in caso di errore, nel qual caso \var{errno} assumerà uno dei
2226 \item[\errcode{EINVAL}] il valore di \param{old\_address} non è un
2228 \item[\errcode{EFAULT}] ci sono indirizzi non validi nell'intervallo
2229 specificato da \param{old\_address} e \param{old\_size}, o ci sono altre
2230 mappature di tipo non corrispondente a quella richiesta.
2231 \item[\errcode{ENOMEM}] non c'è memoria sufficiente oppure l'area di
2232 memoria non può essere espansa all'indirizzo virtuale corrente, e non si
2233 è specificato \const{MREMAP\_MAYMOVE} nei flag.
2234 \item[\errcode{EAGAIN}] il segmento di memoria scelto è bloccato e non può
2240 La funzione richiede come argomenti \param{old\_address} (che deve essere
2241 allineato alle dimensioni di una pagina di memoria) che specifica il
2242 precedente indirizzo del \textit{memory mapping} e \param{old\_size}, che ne
2243 indica la dimensione. Con \param{new\_size} si specifica invece la nuova
2244 dimensione che si vuole ottenere. Infine l'argomento \param{flags} è una
2245 maschera binaria per i flag che controllano il comportamento della funzione.
2246 Il solo valore utilizzato è \const{MREMAP\_MAYMOVE}\footnote{per poter
2247 utilizzare questa costante occorre aver definito \macro{\_GNU\_SOURCE} prima
2248 di includere \file{sys/mman.h}.} che consente di eseguire l'espansione
2249 anche quando non è possibile utilizzare il precedente indirizzo. Per questo
2250 motivo, se si è usato questo flag, la funzione può restituire un indirizzo
2251 della nuova zona di memoria che non è detto coincida con \param{old\_address}.
2253 La funzione si appoggia al sistema della \index{memoria~virtuale} memoria
2254 virtuale per modificare l'associazione fra gli indirizzi virtuali del processo
2255 e le pagine di memoria, modificando i dati direttamente nella
2256 \itindex{page~table} \textit{page table} del processo. Come per
2257 \func{mprotect} la funzione può essere usata in generale, anche per pagine di
2258 memoria non corrispondenti ad un \textit{memory mapping}, e consente così di
2259 implementare la funzione \func{realloc} in maniera molto efficiente.
2261 Una caratteristica comune a tutti i sistemi unix-like è che la mappatura in
2262 memoria di un file viene eseguita in maniera lineare, cioè parti successive di
2263 un file vengono mappate linearmente su indirizzi successivi in memoria.
2264 Esistono però delle applicazioni\footnote{in particolare la tecnica è usata
2265 dai database o dai programmi che realizzano macchine virtuali.} in cui è
2266 utile poter mappare sezioni diverse di un file su diverse zone di memoria.
2268 Questo è ovviamente sempre possibile eseguendo ripetutamente la funzione
2269 \func{mmap} per ciascuna delle diverse aree del file che si vogliono mappare
2270 in sequenza non lineare,\footnote{ed in effetti è quello che veniva fatto
2271 anche con Linux prima che fossero introdotte queste estensioni.} ma questo
2272 approccio ha delle conseguenze molto pesanti in termini di prestazioni.
2273 Infatti per ciascuna mappatura in memoria deve essere definita nella
2274 \itindex{page~table} \textit{page table} del processo una nuova area di
2275 memoria virtuale\footnote{quella che nel gergo del kernel viene chiamata VMA
2276 (\textit{virtual memory area}).} che corrisponda alla mappatura, in modo che
2277 questa diventi visibile nello spazio degli indirizzi come illustrato in
2278 fig.~\ref{fig:file_mmap_layout}.
2280 Quando un processo esegue un gran numero di mappature diverse\footnote{si può
2281 arrivare anche a centinaia di migliaia.} per realizzare a mano una mappatura
2282 non-lineare si avrà un accrescimento eccessivo della sua \itindex{page~table}
2283 \textit{page table}, e lo stesso accadrà per tutti gli altri processi che
2284 utilizzano questa tecnica. In situazioni in cui le applicazioni hanno queste
2285 esigenze si avranno delle prestazioni ridotte, dato che il kernel dovrà
2286 impiegare molte risorse\footnote{sia in termini di memoria interna per i dati
2287 delle \itindex{page~table} \textit{page table}, che di CPU per il loro
2288 aggiornamento.} solo per mantenere i dati di una gran quantità di
2289 \textit{memory mapping}.
2291 Per questo motivo con il kernel 2.5.46 è stato introdotto, ad opera di Ingo
2292 Molnar, un meccanismo che consente la mappatura non-lineare. Anche questa è
2293 una caratteristica specifica di Linux, non presente in altri sistemi
2294 unix-like. Diventa così possibile utilizzare una sola mappatura
2295 iniziale\footnote{e quindi una sola \textit{virtual memory area} nella
2296 \itindex{page~table} \textit{page table} del processo.} e poi rimappare a
2297 piacere all'interno di questa i dati del file. Ciò è possibile grazie ad una
2298 nuova system call, \funcd{remap\_file\_pages}, il cui prototipo è:
2300 \headdecl{sys/mman.h}
2302 \funcdecl{int remap\_file\_pages(void *start, size\_t size, int prot,
2303 ssize\_t pgoff, int flags)}
2305 Permette di rimappare non linearmente un precedente \textit{memory mapping}.
2307 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
2308 errore, nel qual caso \var{errno} assumerà uno dei valori:
2310 \item[\errcode{EINVAL}] Si è usato un valore non valido per uno degli
2311 argomenti o \param{start} non fa riferimento ad un \textit{memory
2312 mapping} valido creato con \const{MAP\_SHARED}.
2317 Per poter utilizzare questa funzione occorre anzitutto effettuare
2318 preliminarmente una chiamata a \func{mmap} con \const{MAP\_SHARED} per
2319 definire l'area di memoria che poi sarà rimappata non linearmente. Poi di
2320 chiamerà questa funzione per modificare le corrispondenze fra pagine di
2321 memoria e pagine del file; si tenga presente che \func{remap\_file\_pages}
2322 permette anche di mappare la stessa pagina di un file in più pagine della
2325 La funzione richiede che si identifichi la sezione del file che si vuole
2326 riposizionare all'interno del \textit{memory mapping} con gli argomenti
2327 \param{pgoff} e \param{size}; l'argomento \param{start} invece deve indicare
2328 un indirizzo all'interno dell'area definita dall'\func{mmap} iniziale, a
2329 partire dal quale la sezione di file indicata verrà rimappata. L'argomento
2330 \param{prot} deve essere sempre nullo, mentre \param{flags} prende gli stessi
2331 valori di \func{mmap} (quelli di tab.~\ref{tab:file_mmap_prot}) ma di tutti i
2332 flag solo \const{MAP\_NONBLOCK} non viene ignorato.
2334 Insieme alla funzione \func{remap\_file\_pages} nel kernel 2.5.46 con sono
2335 stati introdotti anche due nuovi flag per \func{mmap}: \const{MAP\_POPULATE} e
2336 \const{MAP\_NONBLOCK}. Il primo dei due consente di abilitare il meccanismo
2337 del \itindex{prefaulting} \textit{prefaulting}. Questo viene di nuovo in aiuto
2338 per migliorare le prestazioni in certe condizioni di utilizzo del
2339 \textit{memory mapping}.
2341 Il problema si pone tutte le volte che si vuole mappare in memoria un file di
2342 grosse dimensioni. Il comportamento normale del sistema della
2343 \index{memoria~virtuale} memoria virtuale è quello per cui la regione mappata
2344 viene aggiunta alla \itindex{page~table} \textit{page table} del processo, ma
2345 i dati verranno effettivamente utilizzati (si avrà cioè un
2346 \itindex{page~fault} \textit{page fault} che li trasferisce dal disco alla
2347 memoria) soltanto in corrispondenza dell'accesso a ciascuna delle pagine
2348 interessate dal \textit{memory mapping}.
2350 Questo vuol dire che il passaggio dei dati dal disco alla memoria avverrà una
2351 pagina alla volta con un gran numero di \itindex{page~fault} \textit{page
2352 fault}, chiaramente se si sa in anticipo che il file verrà utilizzato
2353 immediatamente, è molto più efficiente eseguire un \itindex{prefaulting}
2354 \textit{prefaulting} in cui tutte le pagine di memoria interessate alla
2355 mappatura vengono ``\textsl{popolate}'' in una sola volta, questo
2356 comportamento viene abilitato quando si usa con \func{mmap} il flag
2357 \const{MAP\_POPULATE}.
2359 Dato che l'uso di \const{MAP\_POPULATE} comporta dell'I/O su disco che può
2360 rallentare l'esecuzione di \func{mmap} è stato introdotto anche un secondo
2361 flag, \const{MAP\_NONBLOCK}, che esegue un \itindex{prefaulting}
2362 \textit{prefaulting} più limitato in cui vengono popolate solo le pagine della
2363 mappatura che già si trovano nella cache del kernel.\footnote{questo può
2364 essere utile per il linker dinamico, in particolare quando viene effettuato
2365 il \textit{prelink} delle applicazioni.}
2367 \itindend{memory~mapping}
2370 \subsection{L'I/O diretto fra file descriptor}
2371 \label{sec:file_sendfile_splice}
2375 NdA è da finire, sul perché non è abilitata fra file vedi:
2377 \href{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}
2378 {\texttt{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}}
2380 % TODO documentare la funzione sendfile
2381 % TODO documentare le funzioni tee e splice
2382 % http://kerneltrap.org/node/6505 e http://lwn.net/Articles/178199/ e
2383 % http://lwn.net/Articles/179492/
2384 % e http://en.wikipedia.org/wiki/Splice_(system_call)
2387 %\subsection{L'utilizzo delle porte di I/O}
2388 %\label{sec:file_io_port}
2390 % TODO l'I/O sulle porte di I/O
2391 % consultare le manpage di ioperm, iopl e outb
2396 \section{Il file locking}
2397 \label{sec:file_locking}
2399 \index{file!locking|(}
2401 In sez.~\ref{sec:file_sharing} abbiamo preso in esame le modalità in cui un
2402 sistema unix-like gestisce la condivisione dei file da parte di processi
2403 diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti
2404 in \itindex{append~mode} \textit{append mode}, quando più processi scrivono
2405 contemporaneamente sullo stesso file non è possibile determinare la sequenza
2406 in cui essi opereranno.
2408 Questo causa la possibilità di una \itindex{race~condition} \textit{race
2409 condition}; in generale le situazioni più comuni sono due: l'interazione fra
2410 un processo che scrive e altri che leggono, in cui questi ultimi possono
2411 leggere informazioni scritte solo in maniera parziale o incompleta; o quella
2412 in cui diversi processi scrivono, mescolando in maniera imprevedibile il loro
2415 In tutti questi casi il \textit{file locking} è la tecnica che permette di
2416 evitare le \textit{race condition} \itindex{race~condition}, attraverso una
2417 serie di funzioni che permettono di bloccare l'accesso al file da parte di
2418 altri processi, così da evitare le sovrapposizioni, e garantire la atomicità
2419 delle operazioni di scrittura.
2423 \subsection{L'\textit{advisory locking}}
2424 \label{sec:file_record_locking}
2426 La prima modalità di \textit{file locking} che è stata implementata nei
2427 sistemi unix-like è quella che viene usualmente chiamata \textit{advisory
2428 locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
2429 come al \textit{record locking}, dizione utilizzata anche dal manuale delle
2430 \acr{glibc}; nelle pagine di manuale si parla di \textit{discrectionary file
2431 lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
2432 mentre questo nome viene usato da Stevens per riferirsi al \textit{file
2433 locking} POSIX. Dato che la dizione \textit{record locking} è quantomeno
2434 ambigua, in quanto in un sistema Unix non esiste niente che possa fare
2435 riferimento al concetto di \textit{record}, alla fine si è scelto di
2436 mantenere il nome \textit{advisory locking}.} in quanto sono i singoli
2437 processi, e non il sistema, che si incaricano di asserire e verificare se
2438 esistono delle condizioni di blocco per l'accesso ai file. Questo significa
2439 che le funzioni \func{read} o \func{write} vengono eseguite comunque e non
2440 risentono affatto della presenza di un eventuale \textit{lock}; pertanto è
2441 sempre compito dei vari processi che intendono usare il file locking,
2442 controllare esplicitamente lo stato dei file condivisi prima di accedervi,
2443 utilizzando le relative funzioni.
2445 In generale si distinguono due tipologie di \textit{file lock}:\footnote{di
2446 seguito ci riferiremo sempre ai blocchi di accesso ai file con la
2447 nomenclatura inglese di \textit{file lock}, o più brevemente con
2448 \textit{lock}, per evitare confusioni linguistiche con il blocco di un
2449 processo (cioè la condizione in cui il processo viene posto in stato di
2450 \textit{sleep}).} la prima è il cosiddetto \textit{shared lock}, detto anche
2451 \textit{read lock} in quanto serve a bloccare l'accesso in scrittura su un
2452 file affinché il suo contenuto non venga modificato mentre lo si legge. Si
2453 parla appunto di \textsl{blocco condiviso} in quanto più processi possono
2454 richiedere contemporaneamente uno \textit{shared lock} su un file per
2455 proteggere il loro accesso in lettura.
2457 La seconda tipologia è il cosiddetto \textit{exclusive lock}, detto anche
2458 \textit{write lock} in quanto serve a bloccare l'accesso su un file (sia in
2459 lettura che in scrittura) da parte di altri processi mentre lo si sta
2460 scrivendo. Si parla di \textsl{blocco esclusivo} appunto perché un solo
2461 processo alla volta può richiedere un \textit{exclusive lock} su un file per
2462 proteggere il suo accesso in scrittura.
2467 \begin{tabular}[c]{|l|c|c|c|}
2469 \textbf{Richiesta} & \multicolumn{3}{|c|}{\textbf{Stato del file}}\\
2471 &Nessun lock&\textit{Read lock}&\textit{Write lock}\\
2474 \textit{Read lock} & SI & SI & NO \\
2475 \textit{Write lock}& SI & NO & NO \\
2478 \caption{Tipologie di file locking.}
2479 \label{tab:file_file_lock}
2482 In Linux sono disponibili due interfacce per utilizzare l'\textit{advisory
2483 locking}, la prima è quella derivata da BSD, che è basata sulla funzione
2484 \func{flock}, la seconda è quella standardizzata da POSIX.1 (derivata da
2485 System V), che è basata sulla funzione \func{fcntl}. I \textit{file lock}
2486 sono implementati in maniera completamente indipendente nelle due interfacce,
2487 che pertanto possono coesistere senza interferenze.
2489 Entrambe le interfacce prevedono la stessa procedura di funzionamento: si
2490 inizia sempre con il richiedere l'opportuno \textit{file lock} (un
2491 \textit{exclusive lock} per una scrittura, uno \textit{shared lock} per una
2492 lettura) prima di eseguire l'accesso ad un file. Se il lock viene acquisito
2493 il processo prosegue l'esecuzione, altrimenti (a meno di non aver richiesto un
2494 comportamento non bloccante) viene posto in stato di sleep. Una volta finite
2495 le operazioni sul file si deve provvedere a rimuovere il lock. La situazione
2496 delle varie possibilità è riassunta in tab.~\ref{tab:file_file_lock}, dove si
2497 sono riportati, per le varie tipologie di lock presenti su un file, il
2498 risultato che si ha in corrispondenza alle due tipologie di \textit{file lock}
2499 menzionate, nel successo della richiesta.
2501 Si tenga presente infine che il controllo di accesso e la gestione dei
2502 permessi viene effettuata quando si apre un file, l'unico controllo residuo
2503 che si può avere riguardo il \textit{file locking} è che il tipo di lock che
2504 si vuole ottenere su un file deve essere compatibile con le modalità di
2505 apertura dello stesso (in lettura per un read lock e in scrittura per un write
2509 %% la condizione per acquisire uno \textit{shared lock} è che il file non abbia
2510 %% già un \textit{exclusive lock} attivo, mentre per acquisire un
2511 %% \textit{exclusive lock} non deve essere presente nessun tipo di blocco.
2514 \subsection{La funzione \func{flock}}
2515 \label{sec:file_flock}
2517 La prima interfaccia per il file locking, quella derivata da BSD, permette di
2518 eseguire un blocco solo su un intero file; la funzione usata per richiedere e
2519 rimuovere un \textit{file lock} è \funcd{flock}, ed il suo prototipo è:
2520 \begin{prototype}{sys/file.h}{int flock(int fd, int operation)}
2522 Applica o rimuove un \textit{file lock} sul file \param{fd}.
2524 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2525 errore, nel qual caso \var{errno} assumerà uno dei valori:
2527 \item[\errcode{EWOULDBLOCK}] Il file ha già un blocco attivo, e si è
2528 specificato \const{LOCK\_NB}.
2533 La funzione può essere usata per acquisire o rilasciare un \textit{file lock}
2534 a seconda di quanto specificato tramite il valore dell'argomento
2535 \param{operation}, questo viene interpretato come maschera binaria, e deve
2536 essere passato utilizzando le costanti riportate in
2537 tab.~\ref{tab:file_flock_operation}.
2542 \begin{tabular}[c]{|l|l|}
2544 \textbf{Valore} & \textbf{Significato} \\
2547 \const{LOCK\_SH} & Asserisce uno \textit{shared lock} sul file.\\
2548 \const{LOCK\_EX} & Asserisce un \textit{esclusive lock} sul file.\\
2549 \const{LOCK\_UN} & Rilascia il \textit{file lock}.\\
2550 \const{LOCK\_NB} & Impedisce che la funzione si blocchi nella
2551 richiesta di un \textit{file lock}.\\
2554 \caption{Valori dell'argomento \param{operation} di \func{flock}.}
2555 \label{tab:file_flock_operation}
2558 I primi due valori, \const{LOCK\_SH} e \const{LOCK\_EX} permettono di
2559 richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera
2560 alternativa. Se si specifica anche \const{LOCK\_NB} la funzione non si
2561 bloccherà qualora il lock non possa essere acquisito, ma ritornerà subito con
2562 un errore di \errcode{EWOULDBLOCK}. Per rilasciare un lock si dovrà invece
2563 usare \const{LOCK\_UN}.
2565 La semantica del file locking di BSD è diversa da quella del file locking
2566 POSIX, in particolare per quanto riguarda il comportamento dei lock nei
2567 confronti delle due funzioni \func{dup} e \func{fork}. Per capire queste
2568 differenze occorre descrivere con maggiore dettaglio come viene realizzato il
2569 file locking nel kernel in entrambe le interfacce.
2571 In fig.~\ref{fig:file_flock_struct} si è riportato uno schema essenziale
2572 dell'implementazione del file locking in stile BSD in Linux; il punto
2573 fondamentale da capire è che un lock, qualunque sia l'interfaccia che si usa,
2574 anche se richiesto attraverso un file descriptor, agisce sempre su un file;
2575 perciò le informazioni relative agli eventuali \textit{file lock} sono
2576 mantenute a livello di inode\index{inode},\footnote{in particolare, come
2577 accennato in fig.~\ref{fig:file_flock_struct}, i \textit{file lock} sono
2578 mantenuti in una \itindex{linked~list} \textit{linked list} di strutture
2579 \struct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
2580 mantenuto dal campo \var{i\_flock} della struttura \struct{inode} (per le
2581 definizioni esatte si faccia riferimento al file \file{fs.h} nei sorgenti
2582 del kernel). Un bit del campo \var{fl\_flags} di specifica se si tratta di
2583 un lock in semantica BSD (\const{FL\_FLOCK}) o POSIX (\const{FL\_POSIX}).}
2584 dato che questo è l'unico riferimento in comune che possono avere due processi
2585 diversi che aprono lo stesso file.
2589 \includegraphics[width=14cm]{img/file_flock}
2590 \caption{Schema dell'architettura del file locking, nel caso particolare
2591 del suo utilizzo da parte dalla funzione \func{flock}.}
2592 \label{fig:file_flock_struct}
2595 La richiesta di un file lock prevede una scansione della lista per determinare
2596 se l'acquisizione è possibile, ed in caso positivo l'aggiunta di un nuovo
2597 elemento.\footnote{cioè una nuova struttura \struct{file\_lock}.} Nel caso
2598 dei lock creati con \func{flock} la semantica della funzione prevede che sia
2599 \func{dup} che \func{fork} non creino ulteriori istanze di un file lock quanto
2600 piuttosto degli ulteriori riferimenti allo stesso. Questo viene realizzato dal
2601 kernel secondo lo schema di fig.~\ref{fig:file_flock_struct}, associando ad
2602 ogni nuovo \textit{file lock} un puntatore\footnote{il puntatore è mantenuto
2603 nel campo \var{fl\_file} di \struct{file\_lock}, e viene utilizzato solo per
2604 i lock creati con la semantica BSD.} alla voce nella \itindex{file~table}
2605 \textit{file table} da cui si è richiesto il lock, che così ne identifica il
2608 Questa struttura prevede che, quando si richiede la rimozione di un file lock,
2609 il kernel acconsenta solo se la richiesta proviene da un file descriptor che
2610 fa riferimento ad una voce nella \itindex{file~table} \textit{file table}
2611 corrispondente a quella registrata nel lock. Allora se ricordiamo quanto
2612 visto in sez.~\ref{sec:file_dup} e sez.~\ref{sec:file_sharing}, e cioè che i
2613 file descriptor duplicati e quelli ereditati in un processo figlio puntano
2614 sempre alla stessa voce nella \itindex{file~table} \textit{file table}, si può
2615 capire immediatamente quali sono le conseguenze nei confronti delle funzioni
2616 \func{dup} e \func{fork}.
2618 Sarà così possibile rimuovere un file lock attraverso uno qualunque dei file
2619 descriptor che fanno riferimento alla stessa voce nella \itindex{file~table}
2620 \textit{file table}, anche se questo è diverso da quello con cui lo si è
2621 creato,\footnote{attenzione, questo non vale se il file descriptor fa
2622 riferimento allo stesso file, ma attraverso una voce diversa della
2623 \itindex{file~table} \textit{file table}, come accade tutte le volte che si
2624 apre più volte lo stesso file.} o se si esegue la rimozione in un processo
2625 figlio; inoltre una volta tolto un file lock, la rimozione avrà effetto su
2626 tutti i file descriptor che condividono la stessa voce nella
2627 \itindex{file~table} \textit{file table}, e quindi, nel caso di file
2628 descriptor ereditati attraverso una \func{fork}, anche su processi diversi.
2630 Infine, per evitare che la terminazione imprevista di un processo lasci attivi
2631 dei file lock, quando un file viene chiuso il kernel provveda anche a
2632 rimuovere tutti i lock ad esso associati. Anche in questo caso occorre tenere
2633 presente cosa succede quando si hanno file descriptor duplicati; in tal caso
2634 infatti il file non verrà effettivamente chiuso (ed il lock rimosso) fintanto
2635 che non viene rilasciata la relativa voce nella \itindex{file~table}
2636 \textit{file table}; e questo avverrà solo quando tutti i file descriptor che
2637 fanno riferimento alla stessa voce sono stati chiusi. Quindi, nel caso ci
2638 siano duplicati o processi figli che mantengono ancora aperto un file
2639 descriptor, il lock non viene rilasciato.
2641 Si tenga presente infine che \func{flock} non è in grado di funzionare per i
2642 file mantenuti su NFS, in questo caso, se si ha la necessità di eseguire il
2643 \textit{file locking}, occorre usare l'interfaccia basata su \func{fcntl} che
2644 può funzionare anche attraverso NFS, a condizione che sia il client che il
2645 server supportino questa funzionalità.
2648 \subsection{Il file locking POSIX}
2649 \label{sec:file_posix_lock}
2651 La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
2652 quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo
2653 già trattato questa funzione nelle sue molteplici possibilità di utilizzo in
2654 sez.~\ref{sec:file_fcntl}. Quando la si impiega per il \textit{file locking}
2655 essa viene usata solo secondo il prototipo:
2656 \begin{prototype}{fcntl.h}{int fcntl(int fd, int cmd, struct flock *lock)}
2658 Applica o rimuove un \textit{file lock} sul file \param{fd}.
2660 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
2661 errore, nel qual caso \var{errno} assumerà uno dei valori:
2663 \item[\errcode{EACCES}] L'operazione è proibita per la presenza di
2664 \textit{file lock} da parte di altri processi.
2665 \item[\errcode{ENOLCK}] Il sistema non ha le risorse per il locking: ci
2666 sono troppi segmenti di lock aperti, si è esaurita la tabella dei lock,
2667 o il protocollo per il locking remoto è fallito.
2668 \item[\errcode{EDEADLK}] Si è richiesto un lock su una regione bloccata da
2669 un altro processo che è a sua volta in attesa dello sblocco di un lock
2670 mantenuto dal processo corrente; si avrebbe pertanto un
2671 \itindex{deadlock} \textit{deadlock}. Non è garantito che il sistema
2672 riconosca sempre questa situazione.
2673 \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale prima
2674 di poter acquisire un lock.
2676 ed inoltre \errval{EBADF}, \errval{EFAULT}.
2680 Al contrario di quanto avviene con l'interfaccia basata su \func{flock} con
2681 \func{fcntl} è possibile bloccare anche delle singole sezioni di un file, fino
2682 al singolo byte. Inoltre la funzione permette di ottenere alcune informazioni
2683 relative agli eventuali lock preesistenti. Per poter fare tutto questo la
2684 funzione utilizza come terzo argomento una apposita struttura \struct{flock}
2685 (la cui definizione è riportata in fig.~\ref{fig:struct_flock}) nella quale
2686 inserire tutti i dati relativi ad un determinato lock. Si tenga presente poi
2687 che un lock fa sempre riferimento ad una regione, per cui si potrà avere un
2688 conflitto anche se c'è soltanto una sovrapposizione parziale con un'altra
2691 \begin{figure}[!bht]
2692 \footnotesize \centering
2693 \begin{minipage}[c]{15cm}
2694 \includestruct{listati/flock.h}
2697 \caption{La struttura \structd{flock}, usata da \func{fcntl} per il file
2699 \label{fig:struct_flock}
2703 I primi tre campi della struttura, \var{l\_whence}, \var{l\_start} e
2704 \var{l\_len}, servono a specificare la sezione del file a cui fa riferimento
2705 il lock: \var{l\_start} specifica il byte di partenza, \var{l\_len} la
2706 lunghezza della sezione e infine \var{l\_whence} imposta il riferimento da cui
2707 contare \var{l\_start}. Il valore di \var{l\_whence} segue la stessa semantica
2708 dell'omonimo argomento di \func{lseek}, coi tre possibili valori
2709 \const{SEEK\_SET}, \const{SEEK\_CUR} e \const{SEEK\_END}, (si vedano le
2710 relative descrizioni in sez.~\ref{sec:file_lseek}).
2712 Si tenga presente che un lock può essere richiesto anche per una regione al di
2713 là della corrente fine del file, così che una eventuale estensione dello
2714 stesso resti coperta dal blocco. Inoltre se si specifica un valore nullo per
2715 \var{l\_len} il blocco si considera esteso fino alla dimensione massima del
2716 file; in questo modo è possibile bloccare una qualunque regione a partire da
2717 un certo punto fino alla fine del file, coprendo automaticamente quanto
2718 eventualmente aggiunto in coda allo stesso.
2723 \begin{tabular}[c]{|l|l|}
2725 \textbf{Valore} & \textbf{Significato} \\
2728 \const{F\_RDLCK} & Richiede un blocco condiviso (\textit{read lock}).\\
2729 \const{F\_WRLCK} & Richiede un blocco esclusivo (\textit{write lock}).\\
2730 \const{F\_UNLCK} & Richiede l'eliminazione di un file lock.\\
2733 \caption{Valori possibili per il campo \var{l\_type} di \struct{flock}.}
2734 \label{tab:file_flock_type}
2737 Il tipo di file lock richiesto viene specificato dal campo \var{l\_type}, esso
2738 può assumere i tre valori definiti dalle costanti riportate in
2739 tab.~\ref{tab:file_flock_type}, che permettono di richiedere rispettivamente
2740 uno \textit{shared lock}, un \textit{esclusive lock}, e la rimozione di un
2741 lock precedentemente acquisito. Infine il campo \var{l\_pid} viene usato solo
2742 in caso di lettura, quando si chiama \func{fcntl} con \const{F\_GETLK}, e
2743 riporta il \acr{pid} del processo che detiene il lock.
2745 Oltre a quanto richiesto tramite i campi di \struct{flock}, l'operazione
2746 effettivamente svolta dalla funzione è stabilita dal valore dall'argomento
2747 \param{cmd} che, come già riportato in sez.~\ref{sec:file_fcntl}, specifica
2748 l'azione da compiere; i valori relativi al file locking sono tre:
2749 \begin{basedescript}{\desclabelwidth{2.0cm}}
2750 \item[\const{F\_GETLK}] verifica se il file lock specificato dalla struttura
2751 puntata da \param{lock} può essere acquisito: in caso negativo sovrascrive
2752 la struttura \param{flock} con i valori relativi al lock già esistente che
2753 ne blocca l'acquisizione, altrimenti si limita a impostarne il campo
2754 \var{l\_type} con il valore \const{F\_UNLCK}.
2755 \item[\const{F\_SETLK}] se il campo \var{l\_type} della struttura puntata da
2756 \param{lock} è \const{F\_RDLCK} o \const{F\_WRLCK} richiede il
2757 corrispondente file lock, se è \const{F\_UNLCK} lo rilascia. Nel caso la
2758 richiesta non possa essere soddisfatta a causa di un lock preesistente la
2759 funzione ritorna immediatamente con un errore di \errcode{EACCES} o di
2761 \item[\const{F\_SETLKW}] è identica a \const{F\_SETLK}, ma se la richiesta di
2762 non può essere soddisfatta per la presenza di un altro lock, mette il
2763 processo in stato di attesa fintanto che il lock precedente non viene
2764 rilasciato. Se l'attesa viene interrotta da un segnale la funzione ritorna
2765 con un errore di \errcode{EINTR}.
2768 Si noti che per quanto detto il comando \const{F\_GETLK} non serve a rilevare
2769 una presenza generica di lock su un file, perché se ne esistono altri
2770 compatibili con quello richiesto, la funzione ritorna comunque impostando
2771 \var{l\_type} a \const{F\_UNLCK}. Inoltre a seconda del valore di
2772 \var{l\_type} si potrà controllare o l'esistenza di un qualunque tipo di lock
2773 (se è \const{F\_WRLCK}) o di write lock (se è \const{F\_RDLCK}). Si consideri
2774 poi che può esserci più di un lock che impedisce l'acquisizione di quello
2775 richiesto (basta che le regioni si sovrappongano), ma la funzione ne riporterà
2776 sempre soltanto uno, impostando \var{l\_whence} a \const{SEEK\_SET} ed i
2777 valori \var{l\_start} e \var{l\_len} per indicare quale è la regione bloccata.
2779 Infine si tenga presente che effettuare un controllo con il comando
2780 \const{F\_GETLK} e poi tentare l'acquisizione con \const{F\_SETLK} non è una
2781 operazione atomica (un altro processo potrebbe acquisire un lock fra le due
2782 chiamate) per cui si deve sempre verificare il codice di ritorno di
2783 \func{fcntl}\footnote{controllare il codice di ritorno delle funzioni invocate
2784 è comunque una buona norma di programmazione, che permette di evitare un
2785 sacco di errori difficili da tracciare proprio perché non vengono rilevati.}
2786 quando la si invoca con \const{F\_SETLK}, per controllare che il lock sia
2787 stato effettivamente acquisito.
2790 \centering \includegraphics[width=9cm]{img/file_lock_dead}
2791 \caption{Schema di una situazione di \itindex{deadlock} \textit{deadlock}.}
2792 \label{fig:file_flock_dead}
2795 Non operando a livello di interi file, il file locking POSIX introduce
2796 un'ulteriore complicazione; consideriamo la situazione illustrata in
2797 fig.~\ref{fig:file_flock_dead}, in cui il processo A blocca la regione 1 e il
2798 processo B la regione 2. Supponiamo che successivamente il processo A richieda
2799 un lock sulla regione 2 che non può essere acquisito per il preesistente lock
2800 del processo 2; il processo 1 si bloccherà fintanto che il processo 2 non
2801 rilasci il blocco. Ma cosa accade se il processo 2 nel frattempo tenta a sua
2802 volta di ottenere un lock sulla regione A? Questa è una tipica situazione che
2803 porta ad un \itindex{deadlock} \textit{deadlock}, dato che a quel punto anche
2804 il processo 2 si bloccherebbe, e niente potrebbe sbloccare l'altro processo.
2805 Per questo motivo il kernel si incarica di rilevare situazioni di questo tipo,
2806 ed impedirle restituendo un errore di \errcode{EDEADLK} alla funzione che
2807 cerca di acquisire un lock che porterebbe ad un \itindex{deadlock}
2810 \begin{figure}[!bht]
2811 \centering \includegraphics[width=13cm]{img/file_posix_lock}
2812 \caption{Schema dell'architettura del file locking, nel caso particolare
2813 del suo utilizzo secondo l'interfaccia standard POSIX.}
2814 \label{fig:file_posix_lock}
2818 Per capire meglio il funzionamento del file locking in semantica POSIX (che
2819 differisce alquanto rispetto da quello di BSD, visto
2820 sez.~\ref{sec:file_flock}) esaminiamo più in dettaglio come viene gestito dal
2821 kernel. Lo schema delle strutture utilizzate è riportato in
2822 fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
2823 di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si
2824 sono evidenziati solo i campi di \struct{file\_lock} significativi per la
2825 semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
2826 \acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene
2827 bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è
2828 comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
2829 impostato il bit \const{FL\_POSIX} ed il campo \var{fl\_file} non viene
2830 usato.} il lock è sempre associato \index{inode} all'inode, solo che in
2831 questo caso la titolarità non viene identificata con il riferimento ad una
2832 voce nella \itindex{file~table} \textit{file table}, ma con il valore del
2833 \acr{pid} del processo.
2835 Quando si richiede un lock il kernel effettua una scansione di tutti i lock
2836 presenti sul file\footnote{scandisce cioè la \itindex{linked~list}
2837 \textit{linked list} delle strutture \struct{file\_lock}, scartando
2838 automaticamente quelle per cui \var{fl\_flags} non è \const{FL\_POSIX}, così
2839 che le due interfacce restano ben separate.} per verificare se la regione
2840 richiesta non si sovrappone ad una già bloccata, in caso affermativo decide in
2841 base al tipo di lock, in caso negativo il nuovo lock viene comunque acquisito
2842 ed aggiunto alla lista.
2844 Nel caso di rimozione invece questa viene effettuata controllando che il
2845 \acr{pid} del processo richiedente corrisponda a quello contenuto nel lock.
2846 Questa diversa modalità ha delle conseguenze precise riguardo il comportamento
2847 dei lock POSIX. La prima conseguenza è che un lock POSIX non viene mai
2848 ereditato attraverso una \func{fork}, dato che il processo figlio avrà un
2849 \acr{pid} diverso, mentre passa indenne attraverso una \func{exec} in quanto
2850 il \acr{pid} resta lo stesso. Questo comporta che, al contrario di quanto
2851 avveniva con la semantica BSD, quando processo termina tutti i file lock da
2852 esso detenuti vengono immediatamente rilasciati.
2854 La seconda conseguenza è che qualunque file descriptor che faccia riferimento
2855 allo stesso file (che sia stato ottenuto con una \func{dup} o con una
2856 \func{open} in questo caso non fa differenza) può essere usato per rimuovere
2857 un lock, dato che quello che conta è solo il \acr{pid} del processo. Da questo
2858 deriva una ulteriore sottile differenza di comportamento: dato che alla
2859 chiusura di un file i lock ad esso associati vengono rimossi, nella semantica
2860 POSIX basterà chiudere un file descriptor qualunque per cancellare tutti i
2861 lock relativi al file cui esso faceva riferimento, anche se questi fossero
2862 stati creati usando altri file descriptor che restano aperti.
2864 Dato che il controllo sull'accesso ai lock viene eseguito sulla base del
2865 \acr{pid} del processo, possiamo anche prendere in considerazione un altro
2866 degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
2867 richiedono dei lock su regioni che si sovrappongono fra loro all'interno
2868 stesso processo. Siccome il controllo, come nel caso della rimozione, si basa
2869 solo sul \acr{pid} del processo che chiama la funzione, queste richieste
2870 avranno sempre successo.
2872 Nel caso della semantica BSD, essendo i lock relativi a tutto un file e non
2873 accumulandosi,\footnote{questa ultima caratteristica è vera in generale, se
2874 cioè si richiede più volte lo stesso file lock, o più lock sulla stessa
2875 sezione di file, le richieste non si cumulano e basta una sola richiesta di
2876 rilascio per cancellare il lock.} la cosa non ha alcun effetto; la funzione
2877 ritorna con successo, senza che il kernel debba modificare la lista dei lock.
2878 In questo caso invece si possono avere una serie di situazioni diverse: ad
2879 esempio è possibile rimuovere con una sola chiamata più lock distinti
2880 (indicando in una regione che si sovrapponga completamente a quelle di questi
2881 ultimi), o rimuovere solo una parte di un lock preesistente (indicando una
2882 regione contenuta in quella di un altro lock), creando un buco, o coprire con
2883 un nuovo lock altri lock già ottenuti, e così via, a secondo di come si
2884 sovrappongono le regioni richieste e del tipo di operazione richiesta. Il
2885 comportamento seguito in questo caso che la funzione ha successo ed esegue
2886 l'operazione richiesta sulla regione indicata; è compito del kernel
2887 preoccuparsi di accorpare o dividere le voci nella lista dei lock per far si
2888 che le regioni bloccate da essa risultanti siano coerenti con quanto
2889 necessario a soddisfare l'operazione richiesta.
2891 \begin{figure}[!htb]
2892 \footnotesize \centering
2893 \begin{minipage}[c]{15cm}
2894 \includecodesample{listati/Flock.c}
2897 \caption{Sezione principale del codice del programma \file{Flock.c}.}
2898 \label{fig:file_flock_code}
2901 Per fare qualche esempio sul file locking si è scritto un programma che
2902 permette di bloccare una sezione di un file usando la semantica POSIX, o un
2903 intero file usando la semantica BSD; in fig.~\ref{fig:file_flock_code} è
2904 riportata il corpo principale del codice del programma, (il testo completo è
2905 allegato nella directory dei sorgenti).
2907 La sezione relativa alla gestione delle opzioni al solito si è omessa, come la
2908 funzione che stampa le istruzioni per l'uso del programma, essa si cura di
2909 impostare le variabili \var{type}, \var{start} e \var{len}; queste ultime due
2910 vengono inizializzate al valore numerico fornito rispettivamente tramite gli
2911 switch \code{-s} e \cmd{-l}, mentre il valore della prima viene impostato con
2912 le opzioni \cmd{-w} e \cmd{-r} si richiede rispettivamente o un write lock o
2913 read lock (i due valori sono esclusivi, la variabile assumerà quello che si è
2914 specificato per ultimo). Oltre a queste tre vengono pure impostate la
2915 variabile \var{bsd}, che abilita la semantica omonima quando si invoca
2916 l'opzione \cmd{-f} (il valore preimpostato è nullo, ad indicare la semantica
2917 POSIX), e la variabile \var{cmd} che specifica la modalità di richiesta del
2918 lock (bloccante o meno), a seconda dell'opzione \cmd{-b}.
2920 Il programma inizia col controllare (\texttt{\small 11--14}) che venga passato
2921 un argomento (il file da bloccare), che sia stato scelto (\texttt{\small
2922 15--18}) il tipo di lock, dopo di che apre (\texttt{\small 19}) il file,
2923 uscendo (\texttt{\small 20--23}) in caso di errore. A questo punto il
2924 comportamento dipende dalla semantica scelta; nel caso sia BSD occorre
2925 reimpostare il valore di \var{cmd} per l'uso con \func{flock}; infatti il
2926 valore preimpostato fa riferimento alla semantica POSIX e vale rispettivamente
2927 \const{F\_SETLKW} o \const{F\_SETLK} a seconda che si sia impostato o meno la
2930 Nel caso si sia scelta la semantica BSD (\texttt{\small 25--34}) prima si
2931 controlla (\texttt{\small 27--31}) il valore di \var{cmd} per determinare se
2932 si vuole effettuare una chiamata bloccante o meno, reimpostandone il valore
2933 opportunamente, dopo di che a seconda del tipo di lock al valore viene
2934 aggiunta la relativa opzione (con un OR aritmetico, dato che \func{flock}
2935 vuole un argomento \param{operation} in forma di maschera binaria. Nel caso
2936 invece che si sia scelta la semantica POSIX le operazioni sono molto più
2937 immediate, si prepara (\texttt{\small 36--40}) la struttura per il lock, e lo
2938 esegue (\texttt{\small 41}).
2940 In entrambi i casi dopo aver richiesto il lock viene controllato il risultato
2941 uscendo (\texttt{\small 44--46}) in caso di errore, o stampando un messaggio
2942 (\texttt{\small 47--49}) in caso di successo. Infine il programma si pone in
2943 attesa (\texttt{\small 50}) finché un segnale (ad esempio un \cmd{C-c} dato da
2944 tastiera) non lo interrompa; in questo caso il programma termina, e tutti i
2945 lock vengono rilasciati.
2947 Con il programma possiamo fare varie verifiche sul funzionamento del file
2948 locking; cominciamo con l'eseguire un read lock su un file, ad esempio usando
2949 all'interno di un terminale il seguente comando:
2952 \begin{minipage}[c]{12cm}
2954 [piccardi@gont sources]$ ./flock -r Flock.c
2957 \end{minipage}\vspace{1mm}
2959 il programma segnalerà di aver acquisito un lock e si bloccherà; in questo
2960 caso si è usato il file locking POSIX e non avendo specificato niente riguardo
2961 alla sezione che si vuole bloccare sono stati usati i valori preimpostati che
2962 bloccano tutto il file. A questo punto se proviamo ad eseguire lo stesso
2963 comando in un altro terminale, e avremo lo stesso risultato. Se invece
2964 proviamo ad eseguire un write lock avremo:
2967 \begin{minipage}[c]{12cm}
2969 [piccardi@gont sources]$ ./flock -w Flock.c
2970 Failed lock: Resource temporarily unavailable
2972 \end{minipage}\vspace{1mm}
2974 come ci aspettiamo il programma terminerà segnalando l'indisponibilità del
2975 lock, dato che il file è bloccato dal precedente read lock. Si noti che il
2976 risultato è lo stesso anche se si richiede il blocco su una sola parte del
2977 file con il comando:
2980 \begin{minipage}[c]{12cm}
2982 [piccardi@gont sources]$ ./flock -w -s0 -l10 Flock.c
2983 Failed lock: Resource temporarily unavailable
2985 \end{minipage}\vspace{1mm}
2987 se invece blocchiamo una regione con:
2990 \begin{minipage}[c]{12cm}
2992 [piccardi@gont sources]$ ./flock -r -s0 -l10 Flock.c
2995 \end{minipage}\vspace{1mm}
2997 una volta che riproviamo ad acquisire il write lock i risultati dipenderanno
2998 dalla regione richiesta; ad esempio nel caso in cui le due regioni si
2999 sovrappongono avremo che:
3002 \begin{minipage}[c]{12cm}
3004 [piccardi@gont sources]$ ./flock -w -s5 -l15 Flock.c
3005 Failed lock: Resource temporarily unavailable
3007 \end{minipage}\vspace{1mm}
3009 ed il lock viene rifiutato, ma se invece si richiede una regione distinta
3013 \begin{minipage}[c]{12cm}
3015 [piccardi@gont sources]$ ./flock -w -s11 -l15 Flock.c
3018 \end{minipage}\vspace{1mm}
3020 ed il lock viene acquisito. Se a questo punto si prova ad eseguire un read
3021 lock che comprende la nuova regione bloccata in scrittura:
3024 \begin{minipage}[c]{12cm}
3026 [piccardi@gont sources]$ ./flock -r -s10 -l20 Flock.c
3027 Failed lock: Resource temporarily unavailable
3029 \end{minipage}\vspace{1mm}
3031 come ci aspettiamo questo non sarà consentito.
3033 Il programma di norma esegue il tentativo di acquisire il lock in modalità non
3034 bloccante, se però usiamo l'opzione \cmd{-b} possiamo impostare la modalità
3035 bloccante, riproviamo allora a ripetere le prove precedenti con questa
3039 \begin{minipage}[c]{12cm}
3041 [piccardi@gont sources]$ ./flock -r -b -s0 -l10 Flock.c Lock acquired
3043 \end{minipage}\vspace{1mm}
3045 il primo comando acquisisce subito un read lock, e quindi non cambia nulla, ma
3046 se proviamo adesso a richiedere un write lock che non potrà essere acquisito
3050 \begin{minipage}[c]{12cm}
3052 [piccardi@gont sources]$ ./flock -w -s0 -l10 Flock.c
3054 \end{minipage}\vspace{1mm}
3056 il programma cioè si bloccherà nella chiamata a \func{fcntl}; se a questo
3057 punto rilasciamo il precedente lock (terminando il primo comando un
3058 \texttt{C-c} sul terminale) potremo verificare che sull'altro terminale il
3059 lock viene acquisito, con la comparsa di una nuova riga:
3062 \begin{minipage}[c]{12cm}
3064 [piccardi@gont sources]$ ./flock -w -s0 -l10 Flock.c
3067 \end{minipage}\vspace{3mm}
3070 Un'altra cosa che si può controllare con il nostro programma è l'interazione
3071 fra i due tipi di lock; se ripartiamo dal primo comando con cui si è ottenuto
3072 un lock in lettura sull'intero file, possiamo verificare cosa succede quando
3073 si cerca di ottenere un lock in scrittura con la semantica BSD:
3076 \begin{minipage}[c]{12cm}
3078 [root@gont sources]# ./flock -f -w Flock.c
3081 \end{minipage}\vspace{1mm}
3083 che ci mostra come i due tipi di lock siano assolutamente indipendenti; per
3084 questo motivo occorre sempre tenere presente quale fra le due semantiche
3085 disponibili stanno usando i programmi con cui si interagisce, dato che i lock
3086 applicati con l'altra non avrebbero nessun effetto.
3090 \subsection{La funzione \func{lockf}}
3091 \label{sec:file_lockf}
3093 Abbiamo visto come l'interfaccia POSIX per il file locking sia molto più
3094 potente e flessibile di quella di BSD, questo comporta anche una maggiore
3095 complessità per via delle varie opzioni da passare a \func{fcntl}. Per questo
3096 motivo è disponibile anche una interfaccia semplificata (ripresa da System V)
3097 che utilizza la funzione \funcd{lockf}, il cui prototipo è:
3098 \begin{prototype}{sys/file.h}{int lockf(int fd, int cmd, off\_t len)}
3100 Applica, controlla o rimuove un \textit{file lock} sul file \param{fd}.
3102 \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
3103 errore, nel qual caso \var{errno} assumerà uno dei valori:
3105 \item[\errcode{EWOULDBLOCK}] Non è possibile acquisire il lock, e si è
3106 selezionato \const{LOCK\_NB}, oppure l'operazione è proibita perché il
3107 file è mappato in memoria.
3108 \item[\errcode{ENOLCK}] Il sistema non ha le risorse per il locking: ci
3109 sono troppi segmenti di lock aperti, si è esaurita la tabella dei lock.
3111 ed inoltre \errval{EBADF}, \errval{EINVAL}.
3115 Il comportamento della funzione dipende dal valore dell'argomento \param{cmd},
3116 che specifica quale azione eseguire; i valori possibili sono riportati in
3117 tab.~\ref{tab:file_lockf_type}.
3122 \begin{tabular}[c]{|l|p{7cm}|}
3124 \textbf{Valore} & \textbf{Significato} \\
3127 \const{LOCK\_SH}& Richiede uno \textit{shared lock}. Più processi possono
3128 mantenere un lock condiviso sullo stesso file.\\
3129 \const{LOCK\_EX}& Richiede un \textit{exclusive lock}. Un solo processo
3130 alla volta può mantenere un lock esclusivo su un file. \\
3131 \const{LOCK\_UN}& Sblocca il file.\\
3132 \const{LOCK\_NB}& Non blocca la funzione quando il lock non è disponibile,
3133 si specifica sempre insieme ad una delle altre operazioni
3134 con un OR aritmetico dei valori.\\
3137 \caption{Valori possibili per l'argomento \param{cmd} di \func{lockf}.}
3138 \label{tab:file_lockf_type}
3141 Qualora il lock non possa essere acquisito, a meno di non aver specificato
3142 \const{LOCK\_NB}, la funzione si blocca fino alla disponibilità dello stesso.
3143 Dato che la funzione è implementata utilizzando \func{fcntl} la semantica
3144 delle operazioni è la stessa di quest'ultima (pertanto la funzione non è
3145 affatto equivalente a \func{flock}).
3149 \subsection{Il \textit{mandatory locking}}
3150 \label{sec:file_mand_locking}
3152 \itindbeg{mandatory~locking|(}
3154 Il \textit{mandatory locking} è una opzione introdotta inizialmente in SVr4,
3155 per introdurre un file locking che, come dice il nome, fosse effettivo
3156 indipendentemente dai controlli eseguiti da un processo. Con il
3157 \textit{mandatory locking} infatti è possibile far eseguire il blocco del file
3158 direttamente al sistema, così che, anche qualora non si predisponessero le
3159 opportune verifiche nei processi, questo verrebbe comunque rispettato.
3161 Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
3162 utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid}. Se si ricorda
3163 quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma
3164 utilizzato per cambiare il group-ID effettivo con cui viene eseguito un
3165 programma, ed è pertanto sempre associato alla presenza del permesso di
3166 esecuzione per il gruppo. Impostando questo bit su un file senza permesso di
3167 esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che
3168 quest'ultimo venga attivato per il file in questione. In questo modo una
3169 combinazione dei permessi originariamente non contemplata, in quanto senza
3170 significato, diventa l'indicazione della presenza o meno del \textit{mandatory
3171 locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in
3172 sez.~\ref{sec:file_perm_management} e cioè che il bit \acr{sgid} viene
3173 cancellato (come misura di sicurezza) quando di scrive su un file, questo
3174 non vale quando esso viene utilizzato per attivare il \textit{mandatory
3177 L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che
3178 neanche l'amministratore può passare sopra ad un lock; pertanto un processo
3179 che blocchi un file cruciale può renderlo completamente inaccessibile,
3180 rendendo completamente inutilizzabile il sistema\footnote{il problema si
3181 potrebbe risolvere rimuovendo il bit \itindex{sgid~bit} \acr{sgid}, ma non è
3182 detto che sia così facile fare questa operazione con un sistema bloccato.}
3183 inoltre con il \textit{mandatory locking} si può bloccare completamente un
3184 server NFS richiedendo una lettura su un file su cui è attivo un lock. Per
3185 questo motivo l'abilitazione del mandatory locking è di norma disabilitata, e
3186 deve essere attivata filesystem per filesystem in fase di montaggio
3187 (specificando l'apposita opzione di \func{mount} riportata in
3188 tab.~\ref{tab:sys_mount_flags}, o con l'opzione \code{-o mand} per il comando
3191 Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
3192 sull'interfaccia POSIX di \func{fcntl}. Questo ha due conseguenze: che non si
3193 ha nessun effetto sui lock richiesti con l'interfaccia di \func{flock}, e che
3194 la granularità del lock è quella del singolo byte, come per \func{fcntl}.
3196 La sintassi di acquisizione dei lock è esattamente la stessa vista in
3197 precedenza per \func{fcntl} e \func{lockf}, la differenza è che in caso di
3198 mandatory lock attivato non è più necessario controllare la disponibilità di
3199 accesso al file, ma si potranno usare direttamente le ordinarie funzioni di
3200 lettura e scrittura e sarà compito del kernel gestire direttamente il file
3203 Questo significa che in caso di read lock la lettura dal file potrà avvenire
3204 normalmente con \func{read}, mentre una \func{write} si bloccherà fino al
3205 rilascio del lock, a meno di non aver aperto il file con \const{O\_NONBLOCK},
3206 nel qual caso essa ritornerà immediatamente con un errore di \errcode{EAGAIN}.
3208 Se invece si è acquisito un write lock tutti i tentativi di leggere o scrivere
3209 sulla regione del file bloccata fermeranno il processo fino al rilascio del
3210 lock, a meno che il file non sia stato aperto con \const{O\_NONBLOCK}, nel
3211 qual caso di nuovo si otterrà un ritorno immediato con l'errore di
3214 Infine occorre ricordare che le funzioni di lettura e scrittura non sono le
3215 sole ad operare sui contenuti di un file, e che sia \func{creat} che
3216 \func{open} (quando chiamata con \const{O\_TRUNC}) effettuano dei cambiamenti,
3217 così come \func{truncate}, riducendone le dimensioni (a zero nei primi due
3218 casi, a quanto specificato nel secondo). Queste operazioni sono assimilate a
3219 degli accessi in scrittura e pertanto non potranno essere eseguite (fallendo
3220 con un errore di \errcode{EAGAIN}) su un file su cui sia presente un qualunque
3221 lock (le prime due sempre, la terza solo nel caso che la riduzione delle
3222 dimensioni del file vada a sovrapporsi ad una regione bloccata).
3224 L'ultimo aspetto della interazione del \textit{mandatory locking} con le
3225 funzioni di accesso ai file è quello relativo ai file mappati in memoria (che
3226 abbiamo trattato in sez.~\ref{sec:file_memory_map}); anche in tal caso infatti,
3227 quando si esegue la mappatura con l'opzione \const{MAP\_SHARED}, si ha un
3228 accesso al contenuto del file. Lo standard SVID prevede che sia impossibile
3229 eseguire il memory mapping di un file su cui sono presenti dei
3230 lock\footnote{alcuni sistemi, come HP-UX, sono ancora più restrittivi e lo
3231 impediscono anche in caso di \textit{advisory locking}, anche se questo
3232 comportamento non ha molto senso, dato che comunque qualunque accesso
3233 diretto al file è consentito.} in Linux è stata però fatta la scelta
3234 implementativa\footnote{per i dettagli si possono leggere le note relative
3235 all'implementazione, mantenute insieme ai sorgenti del kernel nel file
3236 \file{Documentation/mandatory.txt}.} di seguire questo comportamento
3237 soltanto quando si chiama \func{mmap} con l'opzione \const{MAP\_SHARED} (nel
3238 qual caso la funzione fallisce con il solito \errcode{EAGAIN}) che comporta la
3239 possibilità di modificare il file.
3241 \index{file!locking|)}
3243 \itindend{mandatory~locking|(}
3246 % LocalWords: dell'I locking multiplexing cap dell' sez system call socket BSD
3247 % LocalWords: descriptor client deadlock NONBLOCK EAGAIN polling select kernel
3248 % LocalWords: pselect like sys unistd int fd readfds writefds exceptfds struct
3249 % LocalWords: timeval errno EBADF EINTR EINVAL ENOMEM sleep tab signal void of
3250 % LocalWords: CLR ISSET SETSIZE POSIX read NULL nell'header l'header glibc fig
3251 % LocalWords: libc header psignal sigmask SOURCE XOPEN timespec sigset race DN
3252 % LocalWords: condition sigprocmask tut self trick oldmask poll XPG pollfd l'I
3253 % LocalWords: ufds unsigned nfds RLIMIT NOFILE EFAULT ndfs events revents hung
3254 % LocalWords: POLLIN POLLRDNORM POLLRDBAND POLLPRI POLLOUT POLLWRNORM POLLERR
3255 % LocalWords: POLLWRBAND POLLHUP POLLNVAL POLLMSG SysV stream ASYNC SETOWN FAQ
3256 % LocalWords: GETOWN fcntl SETFL SIGIO SETSIG Stevens driven siginfo sigaction
3257 % LocalWords: all'I nell'I Frequently Unanswered Question SIGHUP lease holder
3258 % LocalWords: breaker truncate write SETLEASE arg RDLCK WRLCK UNLCK GETLEASE
3259 % LocalWords: uid capabilities capability EWOULDBLOCK notify dall'OR ACCESS st
3260 % LocalWords: pread readv MODIFY pwrite writev ftruncate creat mknod mkdir buf
3261 % LocalWords: symlink rename DELETE unlink rmdir ATTRIB chown chmod utime lio
3262 % LocalWords: MULTISHOT thread linkando librt layer aiocb asyncronous control
3263 % LocalWords: block ASYNCHRONOUS lseek fildes nbytes reqprio PRIORITIZED sigev
3264 % LocalWords: PRIORITY SCHEDULING opcode listio sigevent signo value function
3265 % LocalWords: aiocbp ENOSYS append error const EINPROGRESS fsync return ssize
3266 % LocalWords: DSYNC fdatasync SYNC cancel ECANCELED ALLDONE CANCELED suspend
3267 % LocalWords: NOTCANCELED list nent timout sig NOP WAIT NOWAIT size count iov
3268 % LocalWords: iovec vector EOPNOTSUPP EISDIR len memory mapping mapped swap NB
3269 % LocalWords: mmap length prot flags off MAP FAILED ANONYMOUS EACCES SHARED SH
3270 % LocalWords: only ETXTBSY DENYWRITE ENODEV filesystem EPERM EXEC noexec table
3271 % LocalWords: ENFILE lenght segment violation SIGSEGV FIXED msync munmap copy
3272 % LocalWords: DoS Denial Service EXECUTABLE NORESERVE LOCKED swapping stack fs
3273 % LocalWords: GROWSDOWN ANON GiB POPULATE prefaulting SIGBUS fifo VME fork old
3274 % LocalWords: exec atime ctime mtime mprotect addr EACCESS mremap address new
3275 % LocalWords: long MAYMOVE realloc VMA virtual Ingo Molnar remap pages pgoff
3276 % LocalWords: dall' fault cache linker prelink advisory discrectionary lock fl
3277 % LocalWords: flock shared exclusive operation dup inode linked NFS cmd ENOLCK
3278 % LocalWords: EDEADLK whence SEEK CUR type pid GETLK SETLK SETLKW all'inode HP
3279 % LocalWords: switch bsd lockf mandatory SVr sgid group root mount mand TRUNC
3280 % LocalWords: SVID UX Documentation sendfile dnotify inotify NdA ppoll fds add
3281 % LocalWords: init EMFILE FIONREAD ioctl watch char pathname uint mask ENOSPC
3282 % LocalWords: dell'inode CLOSE NOWRITE MOVE MOVED FROM TO rm wd event page ctl
3283 % LocalWords: attribute Universe epoll Solaris kqueue level triggered Jonathan
3284 % LocalWords: Lemon BSDCON edge Libenzi kevent backporting epfd EEXIST ENOENT
3288 %%% Local Variables:
3290 %%% TeX-master: "gapil"