Materiale di ieri su SO_LINGER piu` la correzione di un typo su un numero di

[gapil.git] / ipc.tex

diff --git a/ipc.tex b/ipc.tex
index 7f664ab62e0ae6da6a2d46e5b8432de96536a941..e6b45de65be21c0d310fca5609d8e467311a5626 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -98,7 +98,7 @@ capo della pipe, l'altro pu
 
 Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
 comunicazione fra processi attraverso una pipe, utilizzando le proprietà
 
 Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
 comunicazione fra processi attraverso una pipe, utilizzando le proprietà

-ordinarie dei file, ma ci mostra anche qual'è il principale\footnote{Stevens
+ordinarie dei file, ma ci mostra anche qual è il principale\footnote{Stevens

   in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
   unidirezionale, ma in realtà questo è un limite facilmente superabile usando
   una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
   in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
   unidirezionale, ma in realtà questo è un limite facilmente superabile usando
   una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i


@@ -371,7 +371,7 @@ dei programmi 
 effettivamente eseguiti. Questo non comporta nessun problema dato che la
 lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
 per primo, si bloccherà in attesa di ricevere sullo standard input il
 effettivamente eseguiti. Questo non comporta nessun problema dato che la
 lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
 per primo, si bloccherà in attesa di ricevere sullo standard input il

-risultato dell'elaborazione del precedente, benchè quest'ultimo venga invocato
+risultato dell'elaborazione del precedente, benché quest'ultimo venga invocato

 dopo.
 
 \begin{figure}[!htb]
 dopo.
 
 \begin{figure}[!htb]


@@ -1186,22 +1186,23 @@ file \file{msgmax}, \file{msgmnb} e \file{msgmni} di \file{/proc/sys/kernel/}.
 \end{figure}
 
 
 \end{figure}
 
 

-Una coda di messaggi è costituita da una \textit{linked list};\footnote{una
-  \textit{linked list} è una tipica struttura di dati, organizzati in una
-  lista in cui ciascun elemento contiene un puntatore al successivo. In questo
-  modo la struttura è veloce nell'estrazione ed immissione dei dati dalle
-  estremità dalla lista (basta aggiungere un elemento in testa o in coda ed
-  aggiornare un puntatore), e relativamente veloce da attraversare in ordine
-  sequenziale (seguendo i puntatori), è invece relativamente lenta
-  nell'accesso casuale e nella ricerca.}  i nuovi messaggi vengono inseriti in
-coda alla lista e vengono letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si
-è riportato lo schema con cui queste strutture vengono mantenute dal
-kernel.\footnote{lo schema illustrato in fig.~\ref{fig:ipc_mq_schema} è in
-  realtà una semplificazione di quello usato effettivamente fino ai kernel
-  della serie 2.2.x, nei kernel della serie 2.4.x la gestione delle code di
-  messaggi è stata modificata ed è effettuata in maniera diversa; abbiamo
-  mantenuto lo schema precedente in quanto illustra comunque in maniera più
-  che adeguata i principi di funzionamento delle code di messaggi.}
+Una coda di messaggi è costituita da una
+\index{\textit{linked~list}}\textit{linked list};\footnote{una \textit{linked
+    list} è una tipica struttura di dati, organizzati in una lista in cui
+  ciascun elemento contiene un puntatore al successivo. In questo modo la
+  struttura è veloce nell'estrazione ed immissione dei dati dalle estremità
+  dalla lista (basta aggiungere un elemento in testa o in coda ed aggiornare
+  un puntatore), e relativamente veloce da attraversare in ordine sequenziale
+  (seguendo i puntatori), è invece relativamente lenta nell'accesso casuale e
+  nella ricerca.}  i nuovi messaggi vengono inseriti in coda alla lista e
+vengono letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato lo
+schema con cui queste strutture vengono mantenute dal kernel.\footnote{lo
+  schema illustrato in fig.~\ref{fig:ipc_mq_schema} è in realtà una
+  semplificazione di quello usato effettivamente fino ai kernel della serie
+  2.2.x, nei kernel della serie 2.4.x la gestione delle code di messaggi è
+  stata modificata ed è effettuata in maniera diversa; abbiamo mantenuto lo
+  schema precedente in quanto illustra comunque in maniera più che adeguata i
+  principi di funzionamento delle code di messaggi.}

 
 \begin{figure}[!htb]
   \footnotesize \centering
 
 \begin{figure}[!htb]
   \footnotesize \centering


@@ -2557,9 +2558,9 @@ direttamente, la situazione dopo l'esecuzione di \func{shmat} 
 fig.~\ref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
 ricordi quanto illustrato al proposito in sez.~\ref{sec:proc_mem_layout}). In
 particolare l'indirizzo finale del segmento dati (quello impostato da
 fig.~\ref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
 ricordi quanto illustrato al proposito in sez.~\ref{sec:proc_mem_layout}). In
 particolare l'indirizzo finale del segmento dati (quello impostato da

-\func{brk}, vedi sez.~\ref{sec:proc_mem_sbrk}) non viene influenzato. Si tenga
-presente infine che la funzione ha successo anche se il segmento è stato
-marcato per la cancellazione.
+\func{brk}, vedi sez.~\ref{sec:proc_mem_sbrk_alloca}) non viene influenzato.
+Si tenga presente infine che la funzione ha successo anche se il segmento è
+stato marcato per la cancellazione.

 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering


@@ -2640,7 +2641,7 @@ dell'interfaccia, \funcd{shmdt}, il cui prototipo 
   
   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
     errore, la funzione fallisce solo quando non c'è un segmento agganciato
   
   \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
     errore, la funzione fallisce solo quando non c'è un segmento agganciato

-    all'indirizzo \func{shmaddr}, con \var{errno} che assume il valore
+    all'indirizzo \param{shmaddr}, con \var{errno} che assume il valore

     \errval{EINVAL}.}
 \end{functions}
 
     \errval{EINVAL}.}
 \end{functions}
 


@@ -3313,9 +3314,9 @@ processo che esegue la creazione).
 Le code di messaggi non sono ancora supportate nel kernel ufficiale, esiste
 però una implementazione sperimentale di Michal Wronski e Krzysztof
 Benedyczak,\footnote{i patch al kernel e la relativa libreria possono essere
 Le code di messaggi non sono ancora supportate nel kernel ufficiale, esiste
 però una implementazione sperimentale di Michal Wronski e Krzysztof
 Benedyczak,\footnote{i patch al kernel e la relativa libreria possono essere

-  trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc}
-  {http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}, questi sono stati
-  inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}.  In
+trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc}
+{\textsf{http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}}, questi sono
+stati inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}.  In

 generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
 usate, dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono
 più comodi, e che in casi più complessi la comunicazione può essere gestita
 generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
 usate, dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono
 più comodi, e che in casi più complessi la comunicazione può essere gestita