quanto senza la richiesta, il server non avrebbe potuto aprirne il capo in
scrittura e l'apertura si sarebbe bloccata indefinitamente.
-
Benché il nostro sistema client-server funzioni, la sua struttura è piuttosto
complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
che esamina questa architettura in \cite{APUE}, nota come sia impossibile
a riga di comando, che permette di specificare quante volte effettuare il
ciclo \var{n}, e su quale tipo di oggetto eseguirlo.
-
La figura non riporta il codice di selezione delle opzioni, che permette di
inizializzare i valori delle variabili \var{type} al tipo di oggetto voluto, e
\var{n} al numero di volte che si vuole effettuare il ciclo di creazione,
successo solo se l'oggetto non esiste già, fallendo con un errore di
\macro{EEXIST} altrimenti.
+Si tenga conto che l'uso di \macro{IPC\_PRIVATE} non impedisce ad altri
+processi di accedere alla coda (se hanno privilegi sufficienti) una volta che
+questi possano indovinare o ricavare l'identificatore ad essa associato. Per
+la loro implementazione non esiste cioè una maniera che garantisca l'accesso
+esclusivo ad una coda di messaggi. Usare \macro{IPC\_PRIVATE} o
+macro{IPC\_CREAT} e \macro{IPC\_EXCL} per \param{flag} comporta solo la
+creazione di una nuova coda.
+
+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.} in cui nuovi messaggi vengono
+inseriti in coda per poi essere letti dalla cima, con una struttura del tipo
+di quella illustrata in \secref{fig:ipc_mq_schema}.\footnote{la struttura è
+ effettivamente in uso fino ai kernel della serie 2.2.x. Viene mantenuta nei
+ kernel della serie 2.4.x, dove la gestione è effettuata con strutture
+ diverse, solo per compatibilità; essa comunque è quella restituita dalle
+ funzioni dell'interfaccia ed illustra in maniera adeguata i principi di
+ funzionamento delle code di messaggi.}
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=15cm]{img/mqstruct}
+ \caption{Schema della struttura di una coda messaggi.}
+ \label{fig:ipc_mq_schema}
+\end{figure}
+
+Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti
+negli header e corrispondenti alle prime tre costanti riportate in , come
+accennato però in Linux è possibile modificare questi limiti attraverso l'uso
+di \func{syscntl} o scrivendo nei file \file{msgmax}, \file{msgmnb} e
+\file{msgmni} di \file{/proc/sys/kernel/}.
-Una coda di messaggi è costituita da una \textit{linked list} in cui nuovi
-messaggi vengono inseriti in coda e letti dalla cima, con una struttura del
-tipo di quella illustrata in
+\begin{table}[htb]
+ \centering
+ \begin{tabular}[c]{|c|c|l|l}
+ \hline
+ \textbf{Costante} & \textbf{Valore} & \textbf{File in \texttt{proc}}
+ & \textbf{Significato} \\
+ \hline
+ \hline
+ \macro{MSGMNI}& 16& \file{msgmni} & Numero massimo di code di
+ messaggi. \\
+ \macro{MSGMAX}& 8192& \file{msgmax} & Dimensione massima di un singolo
+ messaggio.\\
+ \macro{MSGMNB}&16384& \file{msgmnb} & Dimensione massima di una coda di
+ messaggi.\\
+ \hline
+ \end{tabular}
+ \caption{Valori delle costanti associati ai limiti delle code di messaggi.}
+ \label{tab:ipc_msg_limits}
+\end{table}
+
+Una volta creata una coda di messaggi se ne può controllare
projects / gapil.git / blobdiff