From: Simone Piccardi <piccardi@gnulinux.it>
Date: Thu, 7 Nov 2002 23:31:45 +0000 (+0000)
Subject: Aggiunti alcuni header alla lista e quattro chiacchiere sulle alternative
X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=fe017ba5da165123761dbb85036ad3ed8bbd7ad2;p=gapil.git

Aggiunti alcuni header alla lista e quattro chiacchiere sulle alternative
alle message queue
---

diff --git a/intro.tex b/intro.tex
index 9c682f7..cc730a2 100644
--- a/intro.tex
+++ b/intro.tex
@@ -293,11 +293,16 @@ qualunque sistema operativo.
 Per questo motivo, anche se lo standard non ha alcun riferimento ad un sistema
 di tipo Unix, GNU/Linux (per essere precisi le \acr{glibc}), come molti Unix
 moderni, provvede la compatibilità con questo standard, fornendo le funzioni
-di libreria da esso previste. Queste sono dichiarate in quindici header file
-(anch'essi provvisti dalla \acr{glibc}), uno per ciascuna delle quindici aree
-in cui è stata suddivisa una libreria standard. In
-\tabref{tab:intro_posix_header} si sono riportati questi header, insieme a
-quelli definiti negli altri standard descritti nelle sezioni successive.
+di libreria da esso previste. Queste sono dichiarate in una serie di
+\textit{header file}\footnote{i file di dichiarazione di variabili, tipi e
+  funzioni, usati normalmente da un compilatore C. Per poter accedere alle
+  funzioni occorre includere con la direttiva \code{\#include} questi file nei
+  propri programmi; per ciascuna funzione che tratteremo in seguito
+  indicheremo anche gli \textit{header file} necessari ad usarla.}  (anch'essi
+provvisti dalla \acr{glibc}), In \tabref{tab:intro_posix_header} si sono
+riportati i principali \textit{header file} definiti nello standard POSIX,
+insieme a quelli definiti negli altri standard descritti nelle sezioni
+successive.
 
 \begin{table}[htb]
   \footnotesize
@@ -309,9 +314,8 @@ quelli definiti negli altri standard descritti nelle sezioni successive.
     \hline
     \file{assert.h}& Verifica le asserzioni fatte in un programma.\\
     \file{cpio.h}  & .\\
-    \file{} & .\\
-    \file{} & .\\
-    \file{} & .\\
+    \file{dirent.h}& .\\
+    \file{errno.h} & .\\
     \file{} & .\\
     \file{} & .\\
     \file{} & .\\
@@ -320,9 +324,10 @@ quelli definiti negli altri standard descritti nelle sezioni successive.
     \file{} & .\\
     \file{stdio.h} & I/O bufferizzato in standard ANSI C.\\
     \file{stdlib.h}& definizioni della libreria standard.\\
+    \file{unistd.h}& .\\
     \hline
   \end{tabular}
-  \caption{Elenco dei vari file di include definiti dallo standard POSIX.}
+  \caption{Elenco dei vari header file definiti dallo standard POSIX.}
   \label{tab:intro_posix_header}
 \end{table}
 
diff --git a/ipc.tex b/ipc.tex
index f3fb316..d8ffa5f 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -2609,10 +2609,10 @@ attraverso l'argomento \param{cmd}, i valori possibili sono i seguenti:
 i primi tre comandi sono gli stessi già visti anche per le code ed i semafori,
 gli ultimi due sono delle estensioni previste da Linux. 
 
-Per utilizzare i segmenti di memoria condivisa si usano due funzioni, la prima
-di queste è \func{shmat}, che serve ad agganciare un segmento al processo
-chiamante, in modo che quest'ultimo possa vederlo nel suo spazio di indirizzi;
-il suo prototipo è:
+Per utilizzare i segmenti di memoria condivisa l'interfaccia prevede due
+funzioni, la prima è \func{shmat}, che serve ad agganciare un segmento al
+processo chiamante, in modo che quest'ultimo possa vederlo nel suo spazio di
+indirizzi; il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/shm.h}
@@ -2696,14 +2696,15 @@ Come accennato in \secref{sec:proc_fork} un segmento di memoria condivisa
 agganciato ad un precesso viene ereditato da un figlio attraverso una
 \func{fork}, dato che quest'ultimo riceve una copia dello spazio degli
 indirizzi del padre. Invece, dato che attraverso una \func{exec} viene
-eseguito un diverso programma, tutti i segmenti eventualmente agganciati al
-processo vengono automaticamente sganciati. Lo stesso avviene all'uscita del
-processo attraverso una \func{exit}.
+eseguito un diverso programma con uno spazio di indirizzi completamente
+diverso, tutti i segmenti agganciati al processo originario vengono
+automaticamente sganciati. Lo stesso avviene all'uscita del processo
+attraverso una \func{exit}.
 
 
-La seconda funzione è \func{shmdt}, che consente di sganciare un segmento di
-memoria condivisa dal processo chiamante quando questo non è più necessario,
-il suo prototipo è:
+Una volta che un segmento di memoria condivisa non serve più si può sganciarlo
+esplicitamente dal processo usando la seconda funzione dell'interfaccia,
+\func{shmdt}, il cui  il suo prototipo è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/shm.h}
@@ -2711,19 +2712,16 @@ il suo prototipo 
   \funcdecl{int shmdt(const void *shmaddr)}
   Sgancia dal processo un segmento di memoria condivisa.
   
-  \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
+  \bodydesc{La funzione restituisce 0 in caso di succes so, 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
     \macro{EINVAL}.}
 \end{functions}
 
-La funzione esegue lo sganciamento del segmento di memoria condivisa
-agganciato all'indirizzo \param{shmaddr}; quest'ultimo deve essere uguale
-all'indirizzo ottenuto da una precedente chiamata a \func{shmat}. 
-
-
-
-
+La funzione sgancia dallo spazio degli indirizzi del processo un segmento di
+memoria condivisa; questo viene identificato con l'indirizzo \param{shmaddr}
+restituito dalla precedente chiamata a \func{shmat} con il quale era stato
+agganciato al processo.
 
 
 Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
@@ -2734,26 +2732,49 @@ condivisa; uno schema semplificato della struttura 
 \begin{figure}[htb]
   \centering
   \includegraphics[width=10cm]{img/shmstruct}
-  \caption{Schema dell'implementazione dei segmenti di memoria condivisa in
+   \caption{Schema dell'implementazione dei segmenti di memoria condivisa in
     Linux.}
   \label{fig:ipc_shm_struct}
 \end{figure}
 
 
+
+
 \section{Tecniche alternative}
 \label{sec:ipc_alternatives}
 
 Come abbiamo visto in \secref{sec:ipc_sysv_generic} il sistema di IPC di
-System V presenta numerosi problemi; in \cite{APUE}\footnote{nel capitolo 14.}
-Stevens effettua una accurata analisi (i cui concetti sono già stati accennati
-in precedenza) ed elenca alcune possibili alternative, che vogliamo riprendere
-in questa sezione.
+System V presenta numerosi problemi; in \cite{APUE}\footnote{in particolare
+  nel capitolo 14.}  Stevens effettua una accurata analisi (alcuni dei
+concetti sono già stati accennati in precedenza) ed elenca alcune possibili
+alternative, che vogliamo riprendere in questa sezione.
+
+
+\subsection{Alternative alle code di messaggi}
+\label{sec:ipc_mq_alternative}
+
+Le code di messaggi sono probabilmente il meno usato degli oggetti di IPC di
+System V; esse infatti nacquero principalmente come meccanismo di
+comunicazione bidirezionale quando ancora le pipe erano ancora unidirezionali;
+abbiamo visto però in \secref{sec:ipc_socketpair} che la funzione
+\func{socketpair} permette di fare la stessa cosa senza incorrere nelle
+complicazioni introdotte dal sistema di IPC di System V. 
+
+In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
+hanno delle caratteristiche ulteriori, consentendo una classificazione dei
+messaggi ed un accesso non rigidamente sequenziale, due cose che sono
+impossibili da ottenere con le pipe e i socket di \func{socketpair}.
+
+È però possibile implementare un meccanismo analogo attraverso l'uso di
+memoria condivisa e di meccanismi di sincronizzazione, (un esempio di
+reimplementazione di code di messaggi usando il \textit{memory mapping} e i
+semafori si trova in \cite{UNP2}). pertanto non è
 
 
 \subsection{La sincronizzazione con il \textit{file locking}}
 \label{sec:ipc_file_lock}
 
-Abbiamo esaminato il \textit{file locking} in \secref{sec:file_locking}, 
+Abbiamo esaminato il \textit{file locking} in \secref{sec:file_locking},
 
 
 
diff --git a/system.tex b/system.tex
index c474854..07e74f7 100644
--- a/system.tex
+++ b/system.tex
@@ -878,8 +878,8 @@ Queste funzioni permettono di ottenere una serie di informazioni generali
 riguardo al filesystem su cui si trova il file specificato; queste vengono
 restituite una struttura \param{buf} di tipo \type{statfs} definita come in
 \ref{fig:sys_statfs}, ed i campi che sono indefiniti per il filesystem in
-esame sono impostati a zero.  I valori del campo \var{f\_type} sono definiti per
-i vari filesystem nei relativi file di header dei sorgenti del kernel da
+esame sono impostati a zero.  I valori del campo \var{f\_type} sono definiti
+per i vari filesystem nei relativi file di header dei sorgenti del kernel da
 costanti del tipo \macro{XXX\_SUPER\_MAGIC}, dove \macro{XXX} in genere è il
 nome del filesystem stesso.
 
@@ -1475,10 +1475,10 @@ struct rlimit {
 \end{figure}
 
 In genere il superamento di un limite comporta o l'emissione di un segnale o
-il fallimento della system call che lo ha provocato; per far leggere o impostare
-i limiti di utilizzo delle risorse da parte di un processo le \acr{glibc}
-prevedono due funzioni, \func{getrlimit} e \func{setrlimit}, i cui prototipi
-sono:
+il fallimento della system call che lo ha provocato; per far leggere o
+impostare i limiti di utilizzo delle risorse da parte di un processo le
+\acr{glibc} prevedono due funzioni, \func{getrlimit} e \func{setrlimit}, i cui
+prototipi sono:
 \begin{functions}
   \headdecl{sys/time.h} 
   \headdecl{sys/resource.h}