X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=ipc.tex;h=105c757073319cc936011e100b84d8b2949c498c;hb=c6c3ca02fdb433ef054e56f288d50d74ce8ec4ec;hp=75e8849f83943f159015a8e36e96d35968f7249b;hpb=eba75c4aaf390ff55ad6697ab80d4c1512ea2f39;p=gapil.git

diff --git a/ipc.tex b/ipc.tex
index 75e8849..105c757 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -134,7 +134,7 @@ Per capire meglio il funzionamento delle pipe faremo un esempio di quello che
 è il loro uso più comune, analogo a quello effettuato della shell, e che
 consiste nell'inviare l'output di un processo (lo standard output) sull'input
 di un altro. Realizzeremo il programma di esempio nella forma di un
-\textit{CGI}\footnote{Un CGI (\textit{Common Gateway Interface}) è un
+\textit{CGI}\footnote{un CGI (\textit{Common Gateway Interface}) è un
   programma che permette la creazione dinamica di un oggetto da inserire
   all'interno di una pagina HTML.}  per Apache, che genera una immagine JPEG
 di un codice a barre, specificato come argomento in ingresso.
@@ -569,7 +569,7 @@ ricevuta la risposta, uscir
 A questo punto il server resta (se non ci sono altri client che stanno
 effettuando richieste) con la fifo chiusa sul lato in lettura, ed in questo
 stato la funzione \func{read} non si bloccherà in attesa di input, ma
-ritornerà in continuazione, restituendo un end-of-file.\footnote{Si è usata
+ritornerà in continuazione, restituendo un end-of-file.\footnote{si è usata
   questa tecnica per compatibilità, Linux infatti supporta l'apertura delle
   fifo in lettura/scrittura, per cui si sarebbe potuto effettuare una singola
   apertura con \const{O\_RDWR}, la doppia apertura comunque ha il vantaggio
@@ -978,7 +978,7 @@ solo se tutti i controlli elencati falliscono l'accesso 
 a differenza di quanto avviene per i permessi dei file, fallire in uno dei
 passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
 differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
-il valore di \var{umask} (si ricordi quanto esposto in
+il valore di \itindex{umask} \textit{umask} (si ricordi quanto esposto in
 sez.~\ref{sec:file_perm_management}) non ha alcun significato.
 
 
@@ -2476,7 +2476,7 @@ un segmento di memoria condivisa 
     \begin{errlist}
     \item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma i permessi non
       consentono l'accesso in lettura al segmento.
-    \item[\errcode{EINVAL}] O \param{shmid} non è un identificatore valido o
+    \item[\errcode{EINVAL}] o \param{shmid} non è un identificatore valido o
       \param{cmd} non è un comando valido.
     \item[\errcode{EIDRM}] l'argomento \param{shmid} fa riferimento ad un
       segmento che è stato cancellato.
@@ -2573,9 +2573,9 @@ stato marcato per la cancellazione.
   \label{fig:ipc_shmem_layout}
 \end{figure}
 
-L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{Lo standard
+L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{lo standard
   SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
-  come il valore di ritorno della funzione. In Linux è stato così con le
+  come il valore di ritorno della funzione; in Linux è stato così con le
   \acr{libc4} e le \acr{libc5}, con il passaggio alle \acr{glibc} il tipo di
   \param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
   ritorno un \ctyp{void *}.} deve essere associato il segmento, se il valore
@@ -3322,7 +3322,7 @@ Le code di messaggi POSIX sono supportate da Linux a partire dalla versione
 2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e
   Krzysztof Benedyczak, e le relative informazioni si possono trovare su
   \href{http://www.geocities.com/wronski12/posix_ipc/index.html}
-  {\texttt{http://www.geocities.com/wronski12/posix\_ipc/index.html}}.} In
+  {\textsf{http://www.geocities.com/wronski12/posix\_ipc/index.html}}.} In
 generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
 usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e
 che in casi più complessi la comunicazione può essere gestita direttamente con
@@ -4041,9 +4041,9 @@ accesso.
 
 Questo significa che un nuovo semaforo viene sempre creato con l'user-ID ed il
 group-ID effettivo del processo chiamante, e che i permessi indicati con
-\param{mode} vengono filtrati dal valore della \textit{umask} del processo.
-Inoltre per poter aprire un semaforo è necessario avere su di esso sia il
-permesso di lettura che quello di scrittura.
+\param{mode} vengono filtrati dal valore della \itindex{umask} \textit{umask}
+del processo.  Inoltre per poter aprire un semaforo è necessario avere su di
+esso sia il permesso di lettura che quello di scrittura.
 
 Una volta che si sia ottenuto l'indirizzo di un semaforo, sarà possibile
 utilizzarlo; se si ricorda quanto detto all'inizio di
@@ -4317,7 +4317,7 @@ utilizzare nello stesso modo dei semafori normali con \func{sem\_wait} e
 semaforo può dar luogo ad un comportamento indefinito. 
 
 
-Una volta che non si indenda più utilizzare un semaforo anonimo questo può
+Una volta che non si intenda più utilizzare un semaforo anonimo questo può
 essere eliminato da sistema; per far questo di deve utilizzare una apposita
 funzione, \funcd{sem\_destroy}, il cui prototipo è:
 \begin{functions}
@@ -4399,7 +4399,7 @@ seconda volta con \func{sem\_init}.
 % LocalWords:  lrt blocks PAGECACHE TRUNC CLOEXEC mmap ftruncate munmap FindShm
 % LocalWords:  CreateShm RemoveShm LIBRARY Library libmqueue FAILED EACCESS
 % LocalWords:  ENAMETOOLONG qualchenome RESTART trywait XOPEN SOURCE timedwait
-% LocalWords:  process getvalue sval execve pshared ENOSYS heap
+% LocalWords:  process getvalue sval execve pshared ENOSYS heap PAGE destroy
 
 
 %%% Local Variables: