\subsection{Considerazioni generali}
\label{sec:ipc_posix_generic}
-In Linux non tutti gli oggetti del POSIX IPC sono pienamente supportati nel
-kernel ufficiale; solo la memoria condivisa è presente con l'interfaccia
-completa, ma solo a partire dal kernel 2.4.x, i semafori sono forniti dalle
-\acr{glibc} nella sezione che implementa i thread POSIX, le code di messaggi
-non hanno alcun tipo di supporto ufficiale. Per queste ultime esistono
-tuttavia dei patch e una libreria aggiuntiva.
+Oggi Linux supporta tutti gli oggetti definito nello standard POSIX per l'IPC,
+ma a lungo non è stato così; la memoria condivisa è presente a partire dal
+kernel 2.4.x, i semafori sono forniti dalle \acr{glibc} nella sezione che
+implementa i thread POSIX di nuova generazione che richiedono il kernel 2.6,
+le code di messaggi sono supportate a partire dal kernel 2.6.6.
La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
degli identificatori e delle chiavi visti nel SysV IPC, per passare ai
\label{sec:ipc_posix_mq}
Le code di messaggi POSIX sono supportate da Linux a partire dalla versione
-2.6.6-rc1 del kerne;, \footnote{l'implementazione è dovuta a Michal Wronski e
+2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e
Krzysztof Benedyczak, e le relative informazioni si possono trovare su
\href{http://www.geocities.com/wronski12/posix_ipc/index.html}
{\texttt{http://www.geocities.com/wronski12/posix\_ipc/index.html}}.} In
generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e
che in casi più complessi la comunicazione può essere gestita direttamente con
-mutex e memoria condivisa con tutta la flessibilità che occorre.
+mutex (o semafori) e memoria condivisa con tutta la flessibilità che occorre.
Per poter utilizzare le code di messaggi, oltre ad utilizzare un kernel
superiore al 2.6.6 (o precedente, purché cui siano stati opportunamente
\const{MQ\_PRIO\_MAX}, che nel caso è pari a 32768.
Qualora la coda sia piena, entrambe le funzioni si bloccano, a meno che non
-sia stata selezionata in fase di apertura la modalità non bloccante, nel qual
-caso entrambe ritornano \errcode{EAGAIN}. La sola differenza fra le due
-funzioni è che la seconda, passato il tempo massimo impostato con l'argomento
-\param{abs\_timeout}, ritorna comunque con un errore di \errcode{ETIMEDOUT}.
-
+sia stata selezionata in fase di apertura la modalità non
+bloccante,\footnote{o si sia impostato il flag \const{O\_NONBLOCK} sul fie
+ descriptor della coda.} nel qual caso entrambe ritornano \errcode{EAGAIN}.
+La sola differenza fra le due funzioni è che la seconda, passato il tempo
+massimo impostato con l'argomento \param{abs\_timeout},\footnote{deve essere
+ specificato un tempo assoluto tramite una struttura \struct{timespec} (vedi
+ fig.~\ref{fig:sys_timeval_struct}) indicato in numero di secondi e
+ nanosecondi a partire dal 1 gennaio 1970.} ritorna comunque con un errore di
+\errcode{ETIMEDOUT}, se invece il tempo è già scaduto al momento della
+chiamata e la coda è vuota la funzione ritorna immediatamente.
Come per l'inserimento, anche per l'estrazione dei messaggi da una coda sono
previste due funzioni, \funcd{mq\_receive} e \funcd{mq\_timedreceive}, i cui
La funzione estrae dalla coda il messaggio a priorità più alta, o il più
vecchio fra quelli della stessa priorità. Una volta ricevuto il messaggio
viene tolto dalla coda e la sua dimensione viene restituita come valore di
-ritorno.
+ritorno.\footnote{si tenga presente che 0 è una dimensione valida la
+ condizione di errore è restituita dal valore -1; Stevens in \cite{UNP2} fa
+ notare che questo è uno dei casi in cui vale ciò che lo standard
+ \textsl{non} dice, una dimenzione nulla infatti, pur non essendo citata, non
+ viene proibita.}
Se la dimensione specificata da \param{msg\_len} non è sufficiente a contenere
il messaggio, entrambe le funzioni, al contrario di quanto avveniva nelle code
Si noti che con le code di messaggi POSIX non si ha la possibilità di
selezionare quale messaggio estrarre con delle condizioni sulla priorità, a
differenza di quanto avveniva con le code di messaggi di SysV che permettono
-invece la selezione in base al valore del campo \var{mtype}. Qualora non
-interessi usare la priorità dei messaggi si
+invece la selezione in base al valore del campo \var{mtype}.
-% TODO vericare questa interruzione di paragrafo
% TODO inserire i dati di /proc/sys/fs/mqueue
Qualora la coda sia vuota entrambe le funzioni si bloccano, a meno che non si
0. Questo ci dice che, se si effettua la ricezione dei messaggi usando
esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni
sul processo che ha inserito un messaggio usando un gestore per il segnale in
-forma estesa\footnote{di nuovo si faccia riferimento a quanto detto al
+forma estesa.\footnote{di nuovo si faccia riferimento a quanto detto al
proposito in sez.~\ref{sec:sig_sigaction} e sez.~\ref{sec:sig_real_time}.}
projects / gapil.git / blobdiff