X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=916a27c58855851a26021e1cdb749a1844ce22b1;hp=09017aaebc8e1f8215e47aac32fb57f7131b7231;hb=d46995abfd6f4e2fcd46cdb8ba369dbb6ba36492;hpb=4d9f9d2efab74ce8580fddb05dbdbe754014cdea diff --git a/ipc.tex b/ipc.tex index 09017aa..916a27c 100644 --- a/ipc.tex +++ b/ipc.tex @@ -675,7 +675,7 @@ di end-of-file). Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque client non apre a sua volta la fifo nota in scrittura per effettuare la sua -richiesta. Pertanto all'inizio non ci sono probelmi, il client però, una volta +richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo. A questo punto il server resta (se non ci sono altri client che stanno effettuando richieste) con la fifo chiusa sul lato in lettura e a questo punto @@ -780,13 +780,12 @@ server che a questo punto non serve pi Inoltrata la richiesta si può passare alla lettura della risposta; anzitutto si apre (\texttt{\small 26--30}) la fifo appena creata, da cui si deve -riceverla, dopodiché si effettua una lettura (\texttt{\small 31}) +riceverla, dopo di che si effettua una lettura (\texttt{\small 31}) nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate 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} @@ -933,7 +983,7 @@ file sono su dispositivi con lo stesso \textit{minor number}, come \file{/dev/hda1} e \file{/dev/sda1}. In genere quello che si fa è utilizzare un file comune usato dai programmi che -devono comunicare (ad esempio un haeder comune, o uno dei programmi che devono +devono comunicare (ad esempio un header comune, o uno dei programmi che devono usare l'oggetto in questione), utilizzando il numero di progetto per ottenere le chiavi che interessano. In ogni caso occorre sempre controllare, prima di creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va @@ -1051,7 +1101,7 @@ Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino al kernel 2.2.x questi valori, definiti dalle costanti \macro{MSGMNI}, \macro{SEMMNI} e \macro{SHMMNI}, potevano essere cambiati (come tutti gli altri limiti relativi al \textit{System V IPC}) solo con una ricompilazione - del kernel, andando a modificarne la definizione nei relativi haeder file. + del kernel, andando a modificarne la definizione nei relativi header file. A partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo scrivendo sui file \file{shmmni}, \file{msgmni} e \file{sem} di \file{/proc/sys/kernel} o con l'uso di \texttt{syscntl}.} e per ciascuno di @@ -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 @@ -1660,7 +1710,7 @@ di altri due ben pi Il primo grave difetto è che non esiste una funzione che permetta di creare ed inizializzare un semaforo in un'unica chiamata; occorre prima creare l'insieme dei semafori con \func{semget} e poi inizializzarlo con \func{semctl}, si -perde così ogni possibilità di esegure atomicamente questa operazione. +perde così ogni possibilità di eseguire atomicamente questa operazione. Il secondo difetto deriva dalla caratteristica generale degli oggetti del System V IPC di essere risorse globali di sistema, che non vengono cancellate @@ -1706,7 +1756,7 @@ alterare il semaforo), per quanto riguarda gli altri campi invece: effettuata, viene inizializzato a zero. \end{itemize*} -Ciascun semaforo dell'isnsieme è realizzato come una struttura di tipo +Ciascun semaforo dell'insieme è realizzato come una struttura di tipo \var{sem} che ne contiene i dati essenziali, la sua definizione\footnote{si è riportata la definizione originaria del kernel 1.0, che contiene la prima realizzazione del System V IPC in Linux. In realtà questa struttura ormai è @@ -1734,7 +1784,7 @@ struct sem { \end{lstlisting} \end{minipage} \normalsize - \caption{La struttura \var{sem}, che contiene i dati di un signolo semaforo.} + \caption{La struttura \var{sem}, che contiene i dati di un singolo semaforo.} \label{fig:ipc_sem} \end{figure} @@ -1803,7 +1853,7 @@ loro inizializzazione) La funzione può avere tre o quattro parametri, a seconda dell'operazione specificata con \param{cmd}, ed opera o sull'intero insieme specificato da -\param{semid} o sul sigolo semaforo di un insieme, specificato da +\param{semid} o sul singolo semaforo di un insieme, specificato da \param{semnum}. Qualora la funzione operi con quattro argomenti \param{arg} è un argomento generico che deve essere una \var{union semun}, si è riportato la relativa definizione in \figref{fig:ipc_semun}. @@ -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]