\file{/dev/zero}. In tal caso i valori scritti nella regione mappata non
vengono ignorati (come accade qualora si scriva direttamente sul file), ma
restano in memoria e possono essere riletti secondo le stesse modalità usate
- nel \textit{memory mapping} anonimo.} Un esempio di utilizzo di questa
-tecnica è mostrato in
+ nel \textit{memory mapping} anonimo.} Vedremo come utilizzare questa tecnica
+più avanti, quando realizzeremo una nuova versione del monitor visto in
+\secref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
una interfaccia completamente nuova, che tratteremo in questa sezione.
-
\subsection{Considerazioni generali}
\label{sec:ipc_posix_generic}
-Il Linux non tutti gli oggetti del POSIX IPC sono supportati nel kernel
-ufficiale; solo la memoria condivisa è presente, ma solo a partire dal kernel
-2.4.x, per gli altri oggetti esistono patch e librerie non ufficiali.
-Nonostante questo è importante esaminare questa interfaccia per la sua netta
-superiorità nei confronti di quella del \textit{SysV IPC}.
+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, e sono utilizzabili
+solo all'interno dei thread generati dallo stesso processo,\footnote{sono cioè
+ oggetti che non possono, al contrario dei semafori del SysV IPC, essere
+ utilizzati per sincronizzare processi diversi.} le code di messaggi non
+hanno alcun tipo di supporto ufficiale. Esistono tuttavia dei patch e delle
+librerie aggiuntive che supportano alcune di queste interfacce, anche se
+sperimentali e di uso limitato.
+
+La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
+degli identificatori e delle chiavi visti nel SysV IPC, per passare ai
+\textit{Posix IPC names}\index{Posix IPC names}, che sono sostanzialmente
+equivalenti ai nomi dei file. Tutte le funzioni che creano un oggetto di IPC
+Posix prendono come primo argomento una stringa che indica uno di questi nomi;
+lo standard è molto generico riguardo l'implementazione, ed i nomi stessi
+possono avere o meno una corrispondenza sul filesystem.
+
+
+ le caratteristiche di questi nomi,
+per i quali richiede che:
+\begin{itemize}
+\item debbano essere conformi alle regole che caratterizzano i
+ \textit{pathname}, in particolare non essere più lunghi di \const{PATH\_MAX}
+ byte e terminati da un carattere nullo.
+\item se il nome inizia per una \texttt{/}
+\end{itemize}
+
+
\subsection{Code di messaggi}
ufficiale;\footnote{esiste però una proposta di implementazione di Krzysztof
Benedyczak, a partire dal kernel 2.5.50.} inoltre esse possono essere
implementate, usando la memoria condivisa ed i mutex, con funzioni di
-libreria. In generale, come le corrispettive del SysV IPC, sono poco usate,
+libreria. In generale, come le corrispettive del SysV IPC, sono poco usate,
dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono più
comodi, e negli altri casi la comunicazione può essere gestita direttamente
-con mutex e memoria condivisa. Per questo ci limiteremo ad una descrizione
-essenziale.
+con mutex e memoria condivisa. Per questo, in assenza di una implementazione
+uffiale, ne tralasciamo la descrizione.
livello di libreria ed è fornita dalla libreria dei thread; questa però li
implementa solo a livello di thread e non di processi. Esiste un'altra
versione, realizzata da Konstantin Knizhnik, che reimplementa l'interfaccia
-POSIX usando i semafori di SysV IPC.
+POSIX usando i semafori di SysV IPC.
+
+
\subsection{Memoria condivisa}
projects / gapil.git / blobdiff