\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}
il segnale in questione non sia stato bloccato prima della notifica, nel qual
caso l'invio non avviene ed il segnale resta \textsl{pendente}
indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
-notificato.
+notificato. Si tenga presente però che i segnali \textsl{pendenti} non si
+accodano, alla generazione infatti il kernel marca un flag nella
+\struct{task\_struct} del processo, per cui se prima della notifica ne vengono
+generati altri il flag è comunque marcato, ed il gestore viene eseguito sempre
+una sola volta.
Si ricordi però che se l'azione specificata per un segnale è quella di essere
ignorato questo sarà scartato immediatamente al momento della sua generazione,
-e questo anche se in quel momento il segnale è bloccato (perché ciò che viene
-bloccata è la notifica). Per questo motivo un segnale, fintanto che viene
-ignorato, non sarà mai notificato, anche se è stato bloccato ed in seguito si
-è specificata una azione diversa (nel qual caso solo i segnali successivi alla
-nuova specificazione saranno notificati).
+e questo anche se in quel momento il segnale è bloccato (perché bloccare su un
+segnale significa bloccarne è la notifica). Per questo motivo un segnale,
+fintanto che viene ignorato, non sarà mai notificato, anche se prima è stato
+bloccato ed in seguito si è specificata una azione diversa (nel qual caso solo
+i segnali successivi alla nuova specificazione saranno notificati).
Una volta che un segnale viene notificato (che questo avvenga subito o dopo
una attesa più o meno lunga) viene eseguita l'azione specificata per il
non è diverso dall'uscita con un errore \errcode{EINTR}.
La soluzione è comunque poco elegante e BSD ha scelto un approccio molto
-diverso, che è quello di fare ripartire automaticamente la system call invece
-di farla fallire. In questo caso ovviamente non c'è da preoccuparsi di
-controllare il codice di errore; si perde però la possibilità di eseguire
-azioni specifiche all'occorrenza di questa particolare condizione.
+diverso, che è quello di fare ripartire automaticamente una system call
+interrotta invece di farla fallire. In questo caso ovviamente non c'è bisogno
+di preoccuparsi di controllare il codice di errore; si perde però la
+possibilità di eseguire azioni specifiche all'occorrenza di questa particolare
+condizione.
Linux e le \acr{glibc} consentono di utilizzare entrambi gli approcci,
attraverso una opportuna opzione di \func{sigaction} (vedi
\acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento. Il
comportamento della versione originale della funzione, il cui uso è deprecato
per i motivi visti in \secref{sec:sig_semantics}, può essere ottenuto
-chiamando \func{sysv\_signal}, uno volta che si sia definita la macro
+chiamando \func{sysv\_signal}, una volta che si sia definita la macro
\macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di
\func{signal} (ed ogni eventuale ridefinizine della stessa) è da evitare;
tutti i nuovi programmi dovrebbero usare \func{sigaction}.
installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
(vale a dire che c'è posto\footnote{la profondità della coda è indicata dalla
costante \const{SIGQUEUE\_MAX}, una della tante costanti di sistema definite
- dallo standard POSIX, che non abbiamo riportato esplicitamente in
+ dallo standard POSIX che non abbiamo riportato esplicitamente in
\secref{sec:sys_limits}. Il suo valore minimo secondo lo standard,
- \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32.} nella coda dei segnali
-real-time) esso viene inserito e diventa pendente; una volta consegnato
-riporterà nel campo \var{si\_code} di \struct{siginfo\_t} il valore
-\const{SI\_QUEUE} e il campo \var{si\_value} riceverà quanto inviato con
-\param{value}. Se invece si è installato un gestore nella forma classica il
-segnale sarà generato, ma tutte le caratteristiche tipiche dei segnali
-real-time (priorità e coda) saranno perse.
+ \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux questo è uno
+ dei parametri del kernel impostabili sia con \func{sysctl}, che scrivendolo
+ direttamente in \file{/proc/sys/kernel/rtsig-max}, il valore predefinito è
+ di 1024.} nella coda dei segnali real-time) esso viene inserito e diventa
+pendente; una volta consegnato riporterà nel campo \var{si\_code} di
+\struct{siginfo\_t} il valore \const{SI\_QUEUE} e il campo \var{si\_value}
+riceverà quanto inviato con \param{value}. Se invece si è installato un
+gestore nella forma classica il segnale sarà generato, ma tutte le
+caratteristiche tipiche dei segnali real-time (priorità e coda) saranno perse.
Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di
gestire l'attesa di segnali specifici su una coda, esse servono in particolar
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
-%%% TeX-master: "gapil"
%%% End:
projects / gapil.git / commitdiff