Ancora reindicizzazioni

[gapil.git] / ipc.tex

diff --git a/ipc.tex b/ipc.tex
index 9b7ac1a21a90ed2c395f4542f728556604db5f25..91d38feb5ab5534d0928d7bdfb3402ae1fdc16e4 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -1088,7 +1088,7 @@ solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
 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
 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 \itindex{umask} \textit{umask} (si ricordi quanto esposto in
+il valore di \textit{umask} (si ricordi quanto esposto in

 sez.~\ref{sec:file_perm_management}) non ha alcun significato.
 
 
 sez.~\ref{sec:file_perm_management}) non ha alcun significato.
 
 


@@ -1327,7 +1327,7 @@ coda alla lista e vengono letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si
 dal kernel. Lo schema illustrato in realtà è una semplificazione di quello
 usato fino ai kernel della serie 2.2. A partire della serie 2.4 la gestione
 delle code di messaggi è effettuata in maniera diversa (e non esiste una
 dal kernel. Lo schema illustrato in realtà è una semplificazione di quello
 usato fino ai kernel della serie 2.2. A partire della serie 2.4 la gestione
 delle code di messaggi è effettuata in maniera diversa (e non esiste una

-struttura \struct{msqid\_ds} nel kernel), ma abbiamo mantenuto lo schema
+struttura \kstruct{msqid\_ds} nel kernel), ma abbiamo mantenuto lo schema

 precedente dato che illustra in maniera più che adeguata i principi di
 funzionamento delle code di messaggi.
 
 precedente dato che illustra in maniera più che adeguata i principi di
 funzionamento delle code di messaggi.
 


@@ -1335,12 +1335,13 @@ funzionamento delle code di messaggi.
 
 \begin{figure}[!htb]
   \centering \includegraphics[width=13cm]{img/mqstruct}
 
 \begin{figure}[!htb]
   \centering \includegraphics[width=13cm]{img/mqstruct}

-  \caption{Schema della struttura di una coda messaggi.}
+  \caption{Schema delle strutture di una coda di messaggi
+    (\kstructd{msqid\_ds} e \kstructd{msg}).}

   \label{fig:ipc_mq_schema}
 \end{figure}
 
 
   \label{fig:ipc_mq_schema}
 \end{figure}
 
 

-A ciascuna coda è associata una struttura \struct{msqid\_ds} la cui
+A ciascuna coda è associata una struttura \kstruct{msqid\_ds} la cui

 definizione è riportata in fig.~\ref{fig:ipc_msqid_ds} ed a cui si accede
 includendo \headfiled{sys/msg.h};
 %
 definizione è riportata in fig.~\ref{fig:ipc_msqid_ds} ed a cui si accede
 includendo \headfiled{sys/msg.h};
 %


@@ -1536,13 +1537,13 @@ dovrà essere pari a \const{LENGTH}).
 
 Per capire meglio il funzionamento della funzione riprendiamo in
 considerazione la struttura della coda illustrata in
 
 Per capire meglio il funzionamento della funzione riprendiamo in
 considerazione la struttura della coda illustrata in

-fig.~\ref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
-sarà aggiunto in fondo alla lista inserendo una nuova struttura \struct{msg},
-il puntatore \var{msg\_last} di \struct{msqid\_ds} verrà aggiornato, come pure
-il puntatore al messaggio successivo per quello che era il precedente ultimo
-messaggio; il valore di \var{mtype} verrà mantenuto in \var{msg\_type} ed il
-valore di \param{msgsz} in \var{msg\_ts}; il testo del messaggio sarà copiato
-all'indirizzo specificato da \var{msg\_spot}.
+fig.~\ref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo
+messaggio sarà aggiunto in fondo alla lista inserendo una nuova struttura
+\kstruct{msg}, il puntatore \var{msg\_last} di \kstruct{msqid\_ds} verrà
+aggiornato, come pure il puntatore al messaggio successivo per quello che era
+il precedente ultimo messaggio; il valore di \var{mtype} verrà mantenuto in
+\var{msg\_type} ed il valore di \param{msgsz} in \var{msg\_ts}; il testo del
+messaggio sarà copiato all'indirizzo specificato da \var{msg\_spot}.

 
 Il valore dell'argomento \param{flag} permette di specificare il comportamento
 della funzione. Di norma, quando si specifica un valore nullo, la funzione
 
 Il valore dell'argomento \param{flag} permette di specificare il comportamento
 della funzione. Di norma, quando si specifica un valore nullo, la funzione


@@ -2408,18 +2409,20 @@ versioni delle librerie del C, come le \acr{libc5}).
 
 \begin{figure}[!htb]
   \centering \includegraphics[width=12cm]{img/semtruct}
 
 \begin{figure}[!htb]
   \centering \includegraphics[width=12cm]{img/semtruct}

-  \caption{Schema della struttura di un insieme di semafori.}
+  \caption{Schema delle varie strutture di un insieme di semafori
+    (\kstructd{semid\_ds}, \kstructd{sem}, \kstructd{sem\_queue} e
+    \kstructd{sem\_undo}).}

   \label{fig:ipc_sem_schema}
 \end{figure}
 
 Alla creazione di un nuovo insieme viene allocata una nuova strutture
   \label{fig:ipc_sem_schema}
 \end{figure}
 
 Alla creazione di un nuovo insieme viene allocata una nuova strutture

-\struct{semid\_ds} ed il relativo vettore di strutture \struct{sem}. Quando si
-richiede una operazione viene anzitutto verificato che tutte le operazioni
+\kstruct{semid\_ds} ed il relativo vettore di strutture \kstruct{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 crea una struttura \kstruct{sem\_queue} che viene aggiunta in fondo
 alla coda di attesa associata a ciascun insieme di semafori, che viene
 referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last} di
 possono avere successo; se una di esse comporta il blocco del processo il
 kernel crea una struttura \kstruct{sem\_queue} che viene aggiunta in fondo
 alla coda di attesa associata a ciascun insieme di semafori, che viene
 referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last} di

-\struct{semid\_ds}.  Nella struttura viene memorizzato il riferimento alle
+\kstruct{semid\_ds}.  Nella struttura viene memorizzato il riferimento alle

 operazioni richieste (nel campo \var{sops}, che è un puntatore ad una
 struttura \struct{sembuf}) e al processo corrente (nel campo \var{sleeper})
 poi quest'ultimo viene messo stato di attesa e viene invocato lo
 operazioni richieste (nel campo \var{sops}, che è un puntatore ad una
 struttura \struct{sembuf}) e al processo corrente (nel campo \var{sleeper})
 poi quest'ultimo viene messo stato di attesa e viene invocato lo


@@ -3702,7 +3705,7 @@ una coda di messaggi POSIX è \funcd{mq\_open}, ed il suo prototipo è:
 La funzione apre la coda di messaggi identificata dall'argomento \param{name}
 restituendo il descrittore ad essa associato, del tutto analogo ad un file
 descriptor, con l'unica differenza che lo standard prevede un apposito tipo
 La funzione apre la coda di messaggi identificata dall'argomento \param{name}
 restituendo il descrittore ad essa associato, del tutto analogo ad un file
 descriptor, con l'unica differenza che lo standard prevede un apposito tipo

-\type{mqd\_t}. Nel caso di Linux si tratta in effetti proprio di un normale
+\typed{mqd\_t}. Nel caso di Linux si tratta in effetti proprio di un normale

 file descriptor; pertanto, anche se questo comportamento non è portabile, lo
 si può tenere sotto osservazione con le funzioni dell'I/O multiplexing (vedi
 sez.~\ref{sec:file_multiplexing}) come possibile alternativa all'uso
 file descriptor; pertanto, anche se questo comportamento non è portabile, lo
 si può tenere sotto osservazione con le funzioni dell'I/O multiplexing (vedi
 sez.~\ref{sec:file_multiplexing}) come possibile alternativa all'uso


@@ -4479,10 +4482,9 @@ Si tenga presente che, come accennato in sez.~\ref{sec:ipc_posix_generic}, i
 semafori usano la semantica standard dei file per quanto riguarda i controlli
 di accesso, questo significa che un nuovo semaforo viene sempre creato con
 l'\ids{UID} ed il \ids{GID} effettivo del processo chiamante, e che i permessi
 semafori usano la semantica standard dei file per quanto riguarda i controlli
 di accesso, questo significa che un nuovo semaforo viene sempre creato con
 l'\ids{UID} ed il \ids{GID} effettivo del processo chiamante, e che i permessi

-indicati con \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.
+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.

 
 La funzione restituisce in caso di successo un puntatore all'indirizzo del
 semaforo con un valore di tipo \ctyp{sem\_t *}, è questo valore che dovrà
 
 La funzione restituisce in caso di successo un puntatore all'indirizzo del
 semaforo con un valore di tipo \ctyp{sem\_t *}, è questo valore che dovrà