Messi un po' di placeholder per i terminali virtuali e UDP, corretti alcuni
authorSimone Piccardi <piccardi@gnulinux.it>
Tue, 17 Feb 2004 02:23:34 +0000 (02:23 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Tue, 17 Feb 2004 02:23:34 +0000 (02:23 +0000)
errori sul l'apertura asincrona dei file, sistemata una figura, messo un
riferimento alla dimensione della coda dei segnali real-time

fileadv.tex
img/mmap_layout.dia
session.tex
signal.tex
trasplayer.tex

index 2d000d8..fd77995 100644 (file)
@@ -393,7 +393,7 @@ nel campo \var{revents} per notificare delle condizioni di errore.
     \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
@@ -413,9 +413,9 @@ distinzione ha senso solo per i dati \textit{out-of-band} dei socket (vedi
 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
@@ -441,9 +441,11 @@ le pi
 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}
@@ -464,14 +466,15 @@ propriamente 
 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
@@ -484,14 +487,15 @@ percentuale) sono diventati attivi.
 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
@@ -504,17 +508,18 @@ campo \var{si\_code}\footnote{il valore resta \const{SI\_SIGIO} qualunque sia
 \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}
index 9394095..7978d5a 100644 (file)
Binary files a/img/mmap_layout.dia and b/img/mmap_layout.dia differ
index c1c8a34..c5cdeae 100644 (file)
@@ -1968,6 +1968,25 @@ distinti:
 \end{description}
 
 
+%
+% Qui c'è da mettere tutta la parte sui terminali virtuali, e la gestione
+% degli stessi
+%
+
+\section{La gestione dei terminali virtuali}
+\label{sec:sess_virtual_terminal}
+
+Da fare.
+
+\subsection{I terminali virtuali}
+\label{sec:sess_pty}
+
+Qui vanno spiegati i terminali virtuali, \file{/dev/pty} e compagnia.
+
+\subsection{La funzione \func{openpty}}
+\label{sec:sess_openpty}
+
+Qui vanno le cose su \func{openpty} e compagnia.
 
 %%% Local Variables: 
 %%% mode: latex
index c426986..625a65b 100644 (file)
@@ -212,15 +212,19 @@ scheduler\index{scheduler} che esegue l'azione specificata. Questo a meno che
 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
@@ -826,10 +830,11 @@ ripetendo l'esecuzione dell'espressione \var{expr} fintanto che il risultato
 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
@@ -912,7 +917,7 @@ e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle
 \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}.
@@ -2328,15 +2333,17 @@ Se il segnale 
 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
@@ -2431,5 +2438,4 @@ dedicato alla gestione, che potrebbe riceverlo fra due chiamate successive.
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
-%%% TeX-master: "gapil"
 %%% End: 
index e1d217d..f02165b 100644 (file)
@@ -52,6 +52,15 @@ sono gli stessi che vengono riportati del comando \cmd{netstat} nel campo
 \textit{State}.
 
 
+
+\section{Il protocollo UDP}
+\label{sec:udp_protocol}
+
+In questa sezione prenderemo in esame i vari aspetti del protocollo UDP, che
+dopo il TCP è il protocollo più usato dalle applicazioni di rete.
+
+
+
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"