\func{fcntl}, quale processo (o gruppo di processi) riceverà il segnale.
In questo modo si può evitare l'uso delle funzioni \func{poll} o \func{select}
-che normalmente quando vengono usate con un grande numero di file descriptor,
-non hanno buone prestazioni, in quanto passano maggior parte del tempo ad
-eseguire uno scan per determinare quali sono quelli (in genere un piccola
+che, quando vengono usate con un numero molto grande di file descriptor, non
+hanno buone prestazioni. In tal caso infatti la maggior parte del loro tempo
+di esecuzione è impegato per eseguire uno scan su tutti i file descriptor
+tenuti sotto controllo per determinare quali sono quelli (in genere un piccola
percentuale) che sono diventati attivi.
-Uno dei problemi che si presenta con l'implementazione usuale di questa
-modalità di I/O è che essa può essere usata in maniera immediata aprendo in
-modalità asincrona un solo file per processo, altrimenti ad ogni segnale si
-dovrebbe provvedere ad effettuare un controllo, utilizzando di nuovo
-\func{poll} o \func{select} su tutti i file tenuti in modalità asincrona per
-distinguere quelli cui è dovuta l'emissione del segnale.
-
-Linux però supporta una estensione che permette di evitare tutto questo
-facendo ricorso alle informazioni aggiuntive restituite attraverso la
-struttura \type{siginfo\_t} quando il manipolatore del segnale viene
-installato come \macro{SA\_SIGINFO} (si riveda quanto illustrato in
-\secref{sec:sig_sigaction}).
-
-Per attivare questa caratteristica occorre utilizzare le funzionalità dei
-segnali real-time (vedi \secref{sec:sig_real_time}) settando esplicitamente con
-il comando \macro{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare
-in caso di I/O asincrono (di norma viene usato \macro{SIGIO}). In questo caso
-il manipolatore tutte le volte che riceverà \macro{SI\_SIGIO} come valore del
+Tuttavia con l'implementazione classica dei segnali questa modalità di I/O
+presenta notevoli problemi, dato che non è possibile determinare, quando sono
+più di uno, qual'è il file descriptor responsabile dell'emissione del segnale.
+Linux però supporta le estensioni POSIX.1b dei segnali che permettono di
+superare il problema facendo ricorso alle informazioni aggiuntive restituite
+attraverso la struttura \type{siginfo\_t}, utilizzando la forma estesa
+\var{sa\_sigaction} del manipolatore (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}) settando esplicitamente con il comando
+\macro{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
+I/O asincrono (il segnale di default è \macro{SIGIO}). In questo caso il
+manipolatorem tutte le volte che riceverà \macro{SI\_SIGIO} come valore del
campo \var{si\_code}\footnote{il valore resta \macro{SI\_SIGIO} qualunque sia
il segnale che si è associato all'I/O asincrono, ed indica appunto che il
segnale è stato generato a causa di attività nell'I/O asincrono.} di
\type{siginfo\_t}, troverà nel campo \var{si\_fd} il valore del file
-descriptor che ha generato il segnale. In questo modo è possibile identificare
-immediatamente il file evitando completamente l'uso di funzioni come
-\func{poll} o \func{select}.
+descriptor che ha generato il segnale.
+
+Un secondo vantaggio dell'uso dei segnali real-time è che essendo dotati di
+una coda di consegna ogni segnale sarà associato ad uno solo file descriptor;
+inoltre sarà possibile stabilire delle priorità nella risposta a seconda del
+segnale usato. In questo modo si può identificare immediatamente un file su
+cui l'accesso è diventato possibile evitando completamente l'uso di funzioni
+come \func{poll} e \func{select}.
Benché la modalità di apertura asincrona di un file possa risultare utile in
varie occasioni (in particolar modo con i socket e gli altri file per i quali
le funzioni di I/O sono system call lente), essa è comunque limitata alla
notifica della disponibilità del file descriptor per le operazioni di I/O, e
non ad uno svolgimento asincrono delle medesime. Lo standard POSIX.1b
-definisce invece una interfaccia apposita per l'I/O asincrono, che prevede un
-insieme di funzioni dedicate, completamente separato rispetto a quelle usate
+definisce anche una interfaccia apposita per l'I/O asincrono, che prevede un
+insieme di funzioni dedicate, completamente separate rispetto a quelle usate
normalmente.
In generale questa interfaccia è completamente astratta e può essere
di thread. Al momento\footnote{fino ai kernel della serie 2.4.x, nella serie
2.5.x è però iniziato un lavoro completo di riscrittura di tutto il sistema
di I/O, che prevede anche l'introduzione di un nuovo layer per l'I/O
- asincrono.} esiste una sola versione stabile, quella delle \acr{glibc}, che
-è realizzata completamente in user space; esistono comunque vari progetti
-(come il KAIO della SGI, o i patch di Benjamin La Haise) che prevedono un
-supporto diretto all'interno del kernel.
+ asincrono.} esiste una sola versione stabile di questa interfaccia, quella
+delle \acr{glibc}, che è realizzata completamente in user space. Esistono
+comunque vari progetti sperimentali (come il KAIO della SGI, o i patch di
+Benjamin La Haise) che prevedono una interfaccia che utilizza un supporto
+diretto da parte del kernel.
projects / gapil.git / blobdiff