fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel
nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
fifo non è adatta a risolvere questo tipo di problemi, che possono essere
-affrontati in maniera più semplice ed efficace o usando i
-\textit{socket}\index{socket} (che tratteremo in dettaglio a partire da
-cap.~\ref{cha:socket_intro}) o ricorrendo a meccanismi di comunicazione
-diversi, come quelli che esamineremo in seguito.
+affrontati in maniera più semplice ed efficace o usando i socket (che
+tratteremo in dettaglio a partire da cap.~\ref{cha:socket_intro}) o ricorrendo
+a meccanismi di comunicazione diversi, come quelli che esamineremo in seguito.
Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il
problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
\textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo l'argomento
-dei \textit{socket}\index{socket} in cap.~\ref{cha:socket_intro},\footnote{si
- tratta comunque di oggetti di comunicazione che, come le pipe, sono
- utilizzati attraverso dei file descriptor.} nell'ambito dell'interfaccia
-generale che essi forniscono per la programmazione di rete; e vedremo anche
+dei socket in cap.~\ref{cha:socket_intro},\footnote{si tratta comunque di
+ oggetti di comunicazione che, come le pipe, sono utilizzati attraverso dei
+ file descriptor.} nell'ambito dell'interfaccia generale che essi forniscono
+per la programmazione di rete; e vedremo anche
(in~sez.~\ref{sec:sock_sa_local}) come si possono definire dei file speciali
-(di tipo \textit{socket}, analoghi a quello associati alle fifo) cui si accede
-però attraverso quella medesima interfaccia; vale però la pena esaminare qui
-una modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
+(di tipo socket, analoghi a quello associati alle fifo) cui si accede però
+attraverso quella medesima interfaccia; vale però la pena esaminare qui una
+modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
stata introdotta in BSD4.4, ma è supportata in genere da qualunque sistema
che fornisca l'interfaccia dei socket.} che li rende sostanzialmente
identici ad una pipe bidirezionale.
La funzione \funcd{socketpair} infatti consente di creare una coppia di file
-descriptor connessi fra di loro (tramite un socket\index{socket}, appunto),
-senza dover ricorrere ad un file speciale sul filesystem, i descrittori sono
-del tutto analoghi a quelli che si avrebbero con una chiamata a \func{pipe},
-con la sola differenza è che in questo caso il flusso dei dati può essere
-effettuato in entrambe le direzioni. Il prototipo della funzione è:
+descriptor connessi fra di loro (tramite un socket, appunto), senza dover
+ricorrere ad un file speciale sul filesystem, i descrittori sono del tutto
+analoghi a quelli che si avrebbero con una chiamata a \func{pipe}, con la sola
+differenza è che in questo caso il flusso dei dati può essere effettuato in
+entrambe le direzioni. Il prototipo della funzione è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/socket.h}
\funcdecl{int socketpair(int domain, int type, int protocol, int sv[2])}
- Crea una coppia di socket\index{socket} connessi fra loro.
+ Crea una coppia di socket connessi fra loro.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EAFNOSUPPORT}] I socket\index{socket} locali non sono
- supportati.
+ \item[\errcode{EAFNOSUPPORT}] I socket locali non sono supportati.
\item[\errcode{EPROTONOSUPPORT}] Il protocollo specificato non è supportato.
\item[\errcode{EOPNOTSUPP}] Il protocollo specificato non supporta la
- creazione di coppie di socket\index{socket}.
+ creazione di coppie di socket.
\end{errlist}
ed inoltre \errval{EMFILE}, \errval{EFAULT}.
}
La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di
loro: quello che si scrive su uno di essi sarà ripresentato in input
sull'altro e viceversa. Gli argomenti \param{domain}, \param{type} e
-\param{protocol} derivano dall'interfaccia dei socket\index{socket} (vedi
+\param{protocol} derivano dall'interfaccia dei socket (vedi
sez.~\ref{sec:sock_creation}) che è quella che fornisce il substrato per
connettere i due descrittori, ma in questo caso i soli valori validi che
possono essere specificati sono rispettivamente \const{AF\_UNIX},
\const{SOCK\_STREAM} e \val{0}.
L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
-può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei
-socket\index{socket} locali in generale) permette di trasmettere attraverso le
-linea non solo dei dati, ma anche dei file descriptor: si può cioè passare da
-un processo ad un altro un file descriptor, con una sorta di duplicazione
-dello stesso non all'interno di uno stesso processo, ma fra processi distinti
-(torneremo su questa funzionalità in sez.~\ref{sec:sock_fd_passing}).
+può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei socket
+locali in generale) permette di trasmettere attraverso le linea non solo dei
+dati, ma anche dei file descriptor: si può cioè passare da un processo ad un
+altro un file descriptor, con una sorta di duplicazione dello stesso non
+all'interno di uno stesso processo, ma fra processi distinti (torneremo su
+questa funzionalità in sez.~\ref{sec:sock_fd_passing}).
\section{Il sistema di comunicazione fra processi di System V}
In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
hanno delle caratteristiche ulteriori, consentendo una classificazione dei
messaggi ed un accesso non rigidamente sequenziale; due caratteristiche che
-sono impossibili da ottenere con le pipe e i socket\index{socket} di
-\func{socketpair}. A queste esigenze però si può comunque ovviare in maniera
-diversa con un uso combinato della memoria condivisa e dei meccanismi di
-sincronizzazione, per cui alla fine l'uso delle code di messaggi classiche è
-relativamente poco diffuso.
+sono impossibili da ottenere con le pipe e i socket di \func{socketpair}. A
+queste esigenze però si può comunque ovviare in maniera diversa con un uso
+combinato della memoria condivisa e dei meccanismi di sincronizzazione, per
+cui alla fine l'uso delle code di messaggi classiche è relativamente poco
+diffuso.
\subsection{I \textsl{file di lock}}
\label{sec:ipc_file_lock}
{\textsf{http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}}, questi sono
stati inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}. In
generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
-usate, dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono
+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.
projects / gapil.git / blobdiff