X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=080d33bcc4e37f35a6bc79d01d612b3911120e7d;hp=d3bc3e6307a554f91e88e80c2ba6cce73223eb78;hb=74b559a3958675adf01c9a906cdd485eaf399290;hpb=c1d39844362623e9806b0842f30447eb2cd1c90b diff --git a/ipc.tex b/ipc.tex index d3bc3e6..080d33b 100644 --- a/ipc.tex +++ b/ipc.tex @@ -707,10 +707,9 @@ complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens, 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. @@ -720,40 +719,39 @@ 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}. } @@ -762,19 +760,19 @@ effettuato in entrambe le direzioni. Il prototipo della funzione 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} @@ -3012,11 +3010,11 @@ incorrere nelle complicazioni introdotte dal \textit{SysV IPC}. 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} @@ -3320,7 +3318,7 @@ trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc} {\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.