L'uso di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
race condition\footnote{in Linux però, non esistendo una system call apposita,
la funzione è implementata nelle \acr{glibc} usando \func{select}, e la
- possibilità di una race condition resta.} quando si deve eseguire un test su
-una variabile assegnata da un manipolatore sulla base dell'occorrenza di un
-segnale per decidere se lanciare \func{select}. Fra il test e l'esecuzione è
-presente una finestra in cui potrebbe arrivare il segnale che non sarebbe
-rilevato; la race condition diventa superabile disabilitando il segnale prima
-del test e riabilitandolo poi grazie all'uso di \param{sigmask}.
+ possibilità di una race condition\index{race condition} resta.} quando si
+deve eseguire un test su una variabile assegnata da un gestore sulla base
+dell'occorrenza di un segnale per decidere se lanciare \func{select}. Fra il
+test e l'esecuzione è presente una finestra in cui potrebbe arrivare il
+segnale che non sarebbe rilevato; la race condition\index{race condition}
+diventa superabile disabilitando il segnale prima del test e riabilitandolo
+poi grazie all'uso di \param{sigmask}.
Linux però supporta le estensioni POSIX.1b dei segnali che permettono di
superare il problema facendo ricorso alle informazioni aggiuntive restituite
attraverso la struttura \struct{siginfo\_t}, utilizzando la forma estesa
-\var{sa\_sigaction} del manipolatore (si riveda quanto illustrato in
+\var{sa\_sigaction} del gestore (si riveda quanto illustrato in
\secref{sec:sig_sigaction}).
Per far questo però occorre utilizzare le funzionalità dei segnali real-time
(vedi \secref{sec:sig_real_time}) impostando esplicitamente con il comando
\const{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
I/O asincrono (il segnale predefinito è \const{SIGIO}). In questo caso il
-manipolatore tutte le volte che riceverà \const{SI\_SIGIO} come valore del
+gestore tutte le volte che riceverà \const{SI\_SIGIO} come valore del
campo \var{si\_code}\footnote{il valore resta \const{SI\_SIGIO} qualunque sia
il segnale che si è associato all'I/O asincrono, ed indica appunto che il
segnale è stato generato a causa di attività nell'I/O asincrono.} di
di I/O, che prevede anche l'introduzione di un nuovo layer per l'I/O
asincrono (effettuato a partire dal 2.5.32).} esiste una sola versione
stabile di questa interfaccia, quella delle \acr{glibc}, che è realizzata
-completamente in user space. Esistono comunque vari progetti sperimentali
-(come il KAIO della SGI, o i patch di Benjamin La Haise) che prevedono un
-supporto diretto da parte del kernel.
+completamente in user space, ed accessibile linkando i programmi con la
+libreria \file{librt}. Esistono comunque vari progetti sperimentali (come il
+KAIO della SGI, o i patch di Benjamin La Haise) che prevedono un supporto
+diretto da parte del kernel.
Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate
attraverso l'uso di una apposita struttura \struct{aiocb} (il cui nome sta per
sigval_t sigev_value;
int sigev_signo;
int sigev_notify;
- sigev_notify_function;
- sigev_notify_attributes;
+ void (*sigev_notify_function)(sigval_t);
+ pthread_attr_t *sigev_notify_attributes;
};
\end{lstlisting}
\end{minipage}
riportata in \secref{fig:file_sigevent}; il campo \var{sigev\_notify} è quello
che indica le modalità della notifica, esso può assumere i tre valori:
\begin{basedescript}{\desclabelwidth{3.0cm}}
-\item[\const{SIGEV\_NONE}] Non viene inviata nessuna notifica.
+\item[\const{SIGEV\_NONE}] Non viene inviata nessuna notifica.
\item[\const{SIGEV\_SIGNAL}] La notifica viene effettuata inviando al processo
- chiamante il segnale specificato nel campo \var{sigev\_signo}, se il
- manipolatore è installato con \const{SA\_SIGINFO}, il gli verrà restituito
- il valore di \var{sigev\_value} in come valore del campo \var{si\_value} per
+ chiamante il segnale specificato da \var{sigev\_signo}; se il gestore di
+ questo è stato installato con \const{SA\_SIGINFO} gli verrà restituito il
+ valore di \var{sigev\_value} (la cui definizione è in
+ \figref{fig:sig_sigval}) come valore del campo \var{si\_value} di
\struct{siginfo\_t}.
\item[\const{SIGEV\_THREAD}] La notifica viene effettuata creando un nuovo
- thread che esegue la funzione specificata da \var{sigev\_notify\_function},
- con gli attributi specificati da \var{sigev\_notify\_attribute}.
+ thread che esegue la funzione specificata da \var{sigev\_notify\_function}
+ con argomento \var{sigev\_value}, e con gli attributi specificati da
+ \var{sigev\_notify\_attribute}.
\end{basedescript}
Le due funzioni base dell'interfaccia per l'I/O asincrono sono
potranno essere visibili o meno a seconda del momento in cui la memoria
virtuale trasporterà dal disco in memoria quella sezione del file, perciò è
del tutto imprevedibile il risultato della modifica di un file nei confronti
-del contenuto della memoria mappata su cui è mappato.
-
-Per quanto appena visto, è sempre sconsigliabile eseguire scritture su file
-attraverso l'interfaccia standard, quando lo si è mappato in memoria, è invece
-possibile usare l'interfaccia standard per leggere un file mappato in memoria,
-purché si abbia una certa cura; infatti l'interfaccia dell'I/O mappato in
-memoria mette a disposizione la funzione \funcd{msync} per sincronizzare il
-contenuto della memoria mappata con il file su disco; il suo prototipo è:
+del contenuto della memoria su cui è mappato.
+
+Per questo, è sempre sconsigliabile eseguire scritture su file attraverso
+l'interfaccia standard, quando lo si è mappato in memoria, è invece possibile
+usare l'interfaccia standard per leggere un file mappato in memoria, purché si
+abbia una certa cura; infatti l'interfaccia dell'I/O mappato in memoria mette
+a disposizione la funzione \funcd{msync} per sincronizzare il contenuto della
+memoria mappata con il file su disco; il suo prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/mman.h}
file.
In tutti questi casi il \textit{file locking} è la tecnica che permette di
-evitare le race condition, attraverso una serie di funzioni che permettono di
-bloccare l'accesso al file da parte di altri processi, così da evitare le
-sovrapposizioni, e garantire la atomicità delle operazioni di scrittura.
+evitare le race condition\index{race condition}, attraverso una serie di
+funzioni che permettono di bloccare l'accesso al file da parte di altri
+processi, così da evitare le sovrapposizioni, e garantire la atomicità delle
+operazioni di scrittura.
Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
utilizzo particolare del bit \acr{sgid}. Se si ricorda quanto esposto in
\secref{sec:file_suid_sgid}), esso viene di norma utilizzato per cambiare il
-groupid effettivo con cui viene eseguito un programma, ed è pertanto sempre
+group-ID effettivo con cui viene eseguito un programma, ed è pertanto sempre
associato alla presenza del permesso di esecuzione per il gruppo. Impostando
questo bit su un file senza permesso di esecuzione in un sistema che supporta
il \textit{mandatory locking}, fa sì che quest'ultimo venga attivato per il
projects / gapil.git / blobdiff