X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=aa6893c01586c2841dd3244df2550eca7dec8826;hp=1116f2e3634111f717c899ef9e71cb683f31bcb2;hb=57c1291f77a1a179e67c4506b3e05e74ad89d21e;hpb=ce3357edd5e55104fcb94ce5de3c7325ab7b2564 diff --git a/ipc.tex b/ipc.tex index 1116f2e..aa6893c 100644 --- a/ipc.tex +++ b/ipc.tex @@ -56,7 +56,7 @@ accennato concetto di funzionamento di una pipe scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale nel file descriptor aperto in lettura. I file descriptor infatti non sono connessi a nessun file reale, ma ad un buffer nel kernel, la cui dimensione è -specificata dalla costante \macro{PIPE\_BUF}, (vedi +specificata dal parametro di sistema \macro{PIPE\_BUF}, (vedi \secref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è illustrato in \figref{fig:ipc_pipe_singular}, in cui sono illustrati i due capi della pipe, associati a ciascun file descriptor, con le frecce che @@ -786,7 +786,6 @@ dal server siano sempre di dimensioni inferiori a \macro{PIPE\_BUF}, tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa (\texttt{\small 32}) a video la risposta, si chiude (\texttt{\small 33}) la fifo e si cancella (\texttt{\small 34}) il relativo file. - Si noti come la fifo per la risposta sia stata aperta solo dopo aver inviato la richiesta, se non si fosse fatto così si avrebbe avuto uno stallo, in quanto senza la richiesta, il server non avrebbe potuto aprirne il capo in @@ -808,6 +807,57 @@ come quelli che esamineremo in seguito. +\subsection{La funzione \func{socketpair}} +\label{sec:ipc_socketpair} + +Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il +problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti +\textit{socket} locali (o \textit{Unix domain socket}). Tratteremo l'argomento +dei socket in \capref{cha:socket_intro}, nell'ambito dell'interfaccia generale +che essi forniscono per la programmazione di rete; e vedremo +(in~\secref{sec:sock_sa_local}) come in tal caso si possono definire dei file +speciali (di tipo \textit{socket}, analoghi alle fifo) cui si accede però +attraverso quella interfaccia; vale però la pena esaminare qui una +modalità\footnote{la funzione \func{socketpair} è stata introdotta in BSD4.4, + ma è supportata in genere da qualunque sistema che fornisca l'interfaccia + dei socket.} di uso di questi socket che li rende sostanzialmente identici +ad una pipe bidirezionale. + +Attraverso la funzione \func{socketpair} infatti è possibile creare una coppia +di socket (che sono trattati com file descriptor) connessi fra di loro, senza +fare nessun riferimento ad un file speciale sul filesystem, in maniera analoga +a quello che si fa con \func{pipe}; la differenza è che in questo caso il +flusso dei dati è bidirezionale. 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 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[\macro{EAFNOSUPPORT}] I socket locali non sono supportati. + \item[\macro{EPROTONOSUPPORT}] Il protocollo specificato non è supportato. + \item[\macro{EOPNOTSUPP}] Il protocollo specificato non supporta la + creazione di coppie di socket. + \end{errlist} + ed inoltre \macro{EMFILE}, \macro{EFAULT}. +} +\end{functions} + +La funzione restituisce in \param{sv} una coppia di descrittori di socket +(come vedremo in \capref{cha:socket_intro} i file descriptor vengono usati +anche per i socket) connessi fra di loro, così che quello che si scrive da una +parte può essere riletto dall'altra e viceversa. I parametri \param{domain}, +\param{type} e \param{protocol} derivano dall'interfaccia dei socket, ma in +questo caso i soli valori validi sono rispettivamente \macro{AF\_UNIX}, +\macro{SOCK\_STREAM} e \macro{0}. + + + \section{La comunicazione fra processi di System V} \label{sec:ipc_sysv} @@ -1162,7 +1212,7 @@ una \funcdecl{int msgget(key\_t key, int flag)} - Restituisce l'identificatore di una cosa di messaggi. + Restituisce l'identificatore di una coda di messaggi. \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1 in caso di errore, nel qual caso \var{errno} assumerà uno dei valori: @@ -1485,12 +1535,12 @@ interrotta da un segnale (nel qual caso si ha un errore di \macro{EINTR}). Una volta completato con successo l'invio del messaggio sulla coda, la funzione aggiorna i dati mantenuti in \var{msqid\_ds}, in particolare vengono modificati: -\begin{itemize} +\begin{itemize*} \item Il valore di \var{msg\_lspid}, che viene impostato al \acr{pid} del processo chiamante. \item Il valore di \var{msg\_qnum}, che viene incrementato di uno. \item Il valore \var{msg\_stime}, che viene impostato al tempo corrente. -\end{itemize} +\end{itemize*} La funzione che permette di estrarre da una coda un messaggio (che sarà @@ -1540,7 +1590,7 @@ una scansione della struttura mostrata in \figref{fig:ipc_mq_schema}, restituendo il primo messaggio incontrato che corrisponde ai criteri specificati (che quindi, visto che i messaggi vengono sempre inseriti dalla coda, è quello meno recente); in particolare: -\begin{itemize} +\begin{itemize*} \item se \param{msgtyp} è 0 viene estratto il messaggio in cima alla coda, cioè quello fra i presenti che è stato inserito inserito per primo. \item se \param{msgtyp} è positivo viene estratto il primo messaggio il cui @@ -1549,7 +1599,7 @@ coda, \item se \param{msgtyp} è negativo viene estratto il primo fra i messaggi con il tipo di valore più basso, fra tutti quelli con un tipo inferiore al valore assoluto di \param{msgtyp}. -\end{itemize} +\end{itemize*} Il valore di \param{msgflg} permette di controllare il comportamento della funzione, esso può essere nullo o una maschera binaria composta da uno o più @@ -1571,12 +1621,12 @@ segnale (con \var{errno} impostata a \macro{EINTR}). Una volta completata con successo l'estrazione del messaggio dalla coda, la funzione aggiorna i dati mantenuti in \var{msqid\_ds}, in particolare vengono modificati: -\begin{itemize} +\begin{itemize*} \item Il valore di \var{msg\_lrpid}, che viene impostato al \acr{pid} del processo chiamante. \item Il valore di \var{msg\_qnum}, che viene decrementato di uno. \item Il valore \var{msg\_rtime}, che viene impostato al tempo corrente. -\end{itemize} +\end{itemize*} Come esempio dell'uso delle code di messaggi possiamo riscrivere il nostro server di \textit{fortunes} usando queste al posto delle fifo. In questo caso @@ -1884,6 +1934,29 @@ in attesa su di esso reagiscono di conseguenza al cambiamento di valore. Inoltre la coda delle operazioni di ripristino viene cancellata per tutti i semafori il cui valore viene modificato. +\begin{table}[htb] + \footnotesize + \centering + \begin{tabular}[c]{|c|p{8cm}|} + \hline + \textbf{Operazione} & \textbf{Valore restituito} \\ + \hline + \hline + \macro{GETNCNT}& valore di \var{semncnt}.\\ + \macro{GETPID} & valore di \var{sempid}.\\ + \macro{GETVAL} & valore di \var{semval}.\\ + \macro{GETZCNT}& valore di \var{semzcnt}.\\ + \hline + \end{tabular} + \caption{Valori di ritorno della funzione \func{semctl}.} + \label{tab:ipc_semctl_returns} +\end{table} + +Il valore di ritorno della funzione in caso di successo dipende +dall'operazione richiesta; in generale esso è nullo, a meno che non si sia +specificata una delle operazioni riportate in +\tabref{tab:ipc_semctl_returns}, nel qual caso viene restituito il +corrispondente campo della struttura \var{sem}. \begin{figure}[!htb]