Correzioni ortografiche e aggiornamento di alcune voci per l'indice

[gapil.git] / ipc.tex

diff --git a/ipc.tex b/ipc.tex
index da8d85a09c1e7eff365c4d02aa305fef2da2ed53..f06dfbf9efcd56baf74b9feb0c9dcb443b945e73 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -830,7 +830,7 @@ descriptor connessi fra di loro (tramite un socket, appunto), senza dover
 ricorrere ad un file speciale sul filesystem, i descrittori sono del tutto
 analoghi a quelli che si avrebbero con una chiamata a \func{pipe}, con la sola
 differenza è che in questo caso il flusso dei dati può essere effettuato in
-emtrambe le direzioni. Il prototipo della funzione è:
+entrambe le direzioni. Il prototipo della funzione è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/socket.h} 
@@ -903,7 +903,7 @@ file, un contatore del numero di riferimenti che ne indichi l'essere in uso,
 essi possono essere cancellati anche se ci sono dei processi che li stanno
 utilizzando, con tutte le conseguenze (negative) del caso.
 
-Un'ulteriore caratterestica negativa è che gli oggetti usati nel System V IPC
+Un'ulteriore caratteristica negativa è che gli oggetti usati nel System V IPC
 vengono creati direttamente dal kernel, e sono accessibili solo specificando
 il relativo \textsl{identificatore}. Questo è un numero progressivo (un po'
 come il \acr{pid} dei processi) che il kernel assegna a ciascuno di essi
@@ -1716,13 +1716,13 @@ void HandSIGTERM(int signo) {
 \end{figure}
 
 In \figref{fig:ipc_mq_fortune_server} si è riportato un estratto delle parti
-primcipali del codice del nuovo server (il codice completo è nel file
+principali del codice del nuovo server (il codice completo è nel file
 \file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un
 uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi
 per permettere una comunicazione indipendente fra il server ed i vari client,
 usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile
 in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
-non essere sequanziale, proprio grazie alla classificazione dei messaggi sulla
+non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla
 base del loro tipo.
 
 Il programma, oltre alle solite variabili per il nome del file da cui leggere
@@ -1752,7 +1752,7 @@ Finita la fase di inizializzazione il server esegue in permanenza il ciclo
 principale (\texttt{\small 32--41}). Questo inizia (\texttt{\small 33}) con il
 porsi in attesa di un messaggio di richiesta da parte di un client; si noti
 infatti come \func{msgrcv} richieda un messaggio con \var{mtype} uguale a 1:
-questo è il valore usato per le richieste dato che corriponde al \acr{pid} di
+questo è il valore usato per le richieste dato che corrisponde al \acr{pid} di
 \cmd{init}, che non può essere un client. L'uso del flag \macro{MSG\_NOERROR}
 è solo per sicurezza, dato che i messaggi di richiesta sono di dimensione
 fissa (e contengono solo il \acr{pid} del client).
@@ -1820,7 +1820,7 @@ non viene chiamata con il flag di creazione in quanto la coda deve essere
 preesistente. In caso di errore (ad esempio se il server non è stato avviato)
 il programma termina immediatamente. 
 
-Una volta acquistito l'identificatore della coda il client compone il
+Una volta acquisito l'identificatore della coda il client compone il
 messaggio di richiesta (\texttt{\small 12--13}) in \var{msg\_read}, usando 1
 per il tipo ed inserendo il proprio \acr{pid} come dato da passare al server.
 Calcolata (\texttt{\small 14}) la dimensione, provvede (\texttt{\small 15}) ad
@@ -1832,7 +1832,7 @@ tipo corrispondente al valore del \acr{pid} inviato nella richiesta. L'ultimo
 passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il
 messaggio ricevuto.
  
-Benché funzionante questa archietettura risente dello stesso inconveniente
+Benché funzionante questa architettura risente dello stesso inconveniente
 visto anche nel caso del precedente server basato sulle fifo; se il client
 viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura
 della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
@@ -2001,7 +2001,7 @@ struct sem {
   \label{fig:ipc_sem}
 \end{figure}
 
-I dati mentenuti nella struttura, ed elencati in \figref{fig:ipc_sem},
+I dati mantenuti nella struttura, ed elencati in \figref{fig:ipc_sem},
 indicano rispettivamente: 
 \begin{description*}
 \item[\var{semval}] il valore numerico del semaforo.
@@ -2364,14 +2364,14 @@ Alla creazione di un nuovo insieme viene allocata una nuova strutture
 \var{semid\_ds} ed il relativo vettore di strutture \var{sem}. Quando si
 richiede una operazione viene anzitutto verificato che tutte le operazioni
 possono avere successo; se una di esse comporta il blocco del processo il
-kernel creaa una struttura \var{sem\_queue} che viene aggiunta in fondo alla
+kernel crea una struttura \var{sem\_queue} che viene aggiunta in fondo alla
 coda di attesa associata a ciascun insieme di semafori\footnote{che viene
   referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last}
   di \var{semid\_ds}.}. Nella struttura viene memorizzato il riferimento alle
 operazioni richieste (nel campo \var{sops}, che è un puntatore ad una
 struttura \var{sembuf}) e al processo corrente (nel campo \var{sleeper}) poi
-quest'ultimo viene messo stato di attesa e viene invocato lo scheduler per
-passare all'esecuzione di un altro processo.
+quest'ultimo viene messo stato di attesa e viene invocato lo
+scheduler\index{scheduler} per passare all'esecuzione di un altro processo.
 
 Se invece tutte le operazioni possono avere successo queste vengono eseguite
 immediatamente, dopo di che il kernel esegue una scansione della coda di