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.
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.
\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}
-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};
%
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
\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
-\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
-\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
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
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à
projects / gapil.git / blobdiff