\const{POLLHUP} & Si è verificato un hung-up.\\
\const{POLLNVAL} & Il file descriptor non è aperto.\\
\hline
- \const{POLLMSG} & Definito per compatobilità con SysV.\\
+ \const{POLLMSG} & Definito per compatibilità con SysV.\\
\hline
\end{tabular}
\caption{Costanti per l'identificazione dei vari bit dei campi
alle varie condizioni dei socket torneremo in \secref{sec:TCP_serv_poll}, dove
vedremo anche un esempio del suo utilizzo. Si tenga conto comunque che le
costanti relative ai diversi tipi di dati (come \macro{POLLRDNORM} e
-\macro{POLLRDBAND}) sono utilizzabili soltanto qualora si sia definito
-\macro{\_XOPEN\_SOURCE}.\footnote{e ci si ricordi di farlo sempre in testa al
- file, definirla soltanto prima di includere \file{sys/poll.h} non è
+\macro{POLLRDBAND}) sono utilizzabili soltanto qualora si sia definita la
+macro \macro{\_XOPEN\_SOURCE}.\footnote{e ci si ricordi di farlo sempre in
+ testa al file, definirla soltanto prima di includere \file{sys/poll.h} non è
sufficiente.}
In caso di successo funzione ritorna restituendo il numero di file (un valore
debba operare su più file contemporaneamente, esistono altre modalità di
gestione delle stesse problematiche. In particolare sono importanti in questo
contesto le modalità di accesso ai file eseguibili in maniera
-\textsl{asincrona}, senza cioè che un processo debba bloccarsi, ed utilizzi
-invece un meccanismo di notifica asincrono, come un segnale, per rilevare la
-possibilità di eseguire le operazioni volute.
+\textsl{asincrona}, quelle cioè in cui un processo non deve bloccarsi in
+attesa della disponibilità dell'accesso al file, ma può proseguire
+nell'esecuzione utilizzando invece un meccanismo di notifica asincrono (di
+norma un segnale), per essere avvisato della possibilità di eseguire le
+operazioni di I/O volute.
\subsection{Operazioni asincrone sui file}
notifica delle variazione dello stato del file descriptor aperto in questo
modo.
-Quello che succede è che il sistema genera un segnale (normalmente
-\const{SIGIO}, ma è possibile usarne altri con il comando \const{F\_SETSIG} di
-\func{fcntl}) tutte le volte che diventa possibile leggere o scrivere dal file
-descriptor che si è posto in questa modalità. Si può inoltre selezionare, con
-il comando \const{F\_SETOWN} di \func{fcntl}, quale processo (o gruppo di
-processi) riceverà il segnale. Se pertanto si effettuano le operazioni in
-risposta alla ricezione del segnale non ci sarà più la necessità di restare
-bloccati in attesa della disponibilità di accesso ai file.
+Quello che succede in questo caso è che il sistema genera un segnale
+(normalmente \const{SIGIO}, ma è possibile usarne altri con il comando
+\const{F\_SETSIG} di \func{fcntl}) tutte le volte che diventa possibile
+leggere o scrivere dal file descriptor che si è posto in questa modalità. Si
+può inoltre selezionare, con il comando \const{F\_SETOWN} di \func{fcntl},
+quale processo (o gruppo di processi) riceverà il segnale. Se pertanto si
+effettuano le operazioni di I/O in risposta alla ricezione del segnale non ci
+sarà più la necessità di restare bloccati in attesa della disponibilità di
+accesso ai file.
In questo modo si può evitare l'uso delle funzioni \func{poll} o \func{select}
che, quando vengono usate con un numero molto grande di file descriptor, non
Tuttavia con l'implementazione classica dei segnali questa modalità di I/O
presenta notevoli problemi, dato che non è possibile determinare, quando i
file descriptor sono più di uno, qual'è quello responsabile dell'emissione del
-segnale; inoltre dato che i segnali normali non si accumulano, in presenza di
-più file descriptor attivi contemporaneamente, più segnali emessi nello stesso
-tempo verrebbero notificati una volta sola. Linux però supporta le estensioni
-POSIX.1b dei segnali real-time, che possono accumularsi e che permettono di
-riconoscere il file descriptor facendo ricorso alle informazioni aggiuntive
-restituite attraverso la struttura \struct{siginfo\_t}, utilizzando la forma
-estesa \var{sa\_sigaction} del gestore (si riveda quanto illustrato in
-\secref{sec:sig_sigaction}).
+segnale. Inoltre dato che i segnali normali non si accodano (si ricordi quanto
+illustrato in sez.~\ref{sec:sig_notification}), in presenza di più file
+descriptor attivi contemporaneamente, più segnali emessi nello stesso momento
+verrebbero notificati una volta sola. Linux però supporta le estensioni
+POSIX.1b dei segnali real-time, che vengono accodati e che permettono di
+riconoscere il file descriptor che li ha emessi. In questo caso infatti si può
+fare ricorso alle informazioni aggiuntive restituite attraverso la struttura
+\struct{siginfo\_t}, utilizzando la forma estesa \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
\struct{siginfo\_t}, troverà nel campo \var{si\_fd} il valore del file
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}, almeno fintanto che non si satura la coda;
-si eccedono le dimensioni di quest'ultima; in tal caso infatti il kernel, non
+Un secondo vantaggio dell'uso dei segnali real-time è che essendo questi
+ultimi 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, dato che i segnali real-time supportano
+anche questa funzionalità. 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}, almeno fintanto che non si satura
+la coda. Se infatti si eccedono le dimensioni di quest'ultima, il kernel, non
potendo più assicurare il comportamento corretto per un segnale real-time,
-invierà al suo posto un \const{SIGIO}, su cui si accumuleranno tutti i segnali
-in eccesso, e si dovrà determinare con un ciclo quali sono i file diventati
-attivi.
+invierà al suo posto un solo \const{SIGIO}, su cui si saranno accumulati tutti
+i segnali in eccesso, e si dovrà allora determinare con un ciclo quali sono i
+file diventati attivi.
\subsection{L'interfaccia POSIX per l'I/O asincrono}
projects / gapil.git / blobdiff