\chapter{La comunicazione fra processi}
\label{cha:IPC}


Uno degli aspetti fondamentali della programmazione in un sistema unix-like è
la comunicazione fra processi. In questo capitolo affronteremo solo i
meccanismi più elementari che permettono di mettere in comunicazione processi
diversi, come quelli tradizionali che coinvolgono \textit{pipe} e
\textit{fifo} e i meccanismi di intercomunicazione di System V.

Tralasceremo invece tutte le problematiche relative alla comunicazione
attraverso la rete (e le relative interfacce) che saranno affrontate in
dettaglio in un secondo tempo.  Non affronteremo invece meccanismi più
complessi ed evoluti come le RPC (\textit{Remote Procedure Calls}) e CORBA
(\textit{Common Object Request Brocker Architecture}) che in genere sono
implementati con un ulteriore livello sopra i meccanismi elementari.



\section{La comunicazione fra processi tradizionale}
\label{sec:ipc_unix}

Il primo meccanismo di comunicazione fra processi usato dai sistemi unix-like,
e quello che viene correntemente usato di più, è quello delle \textit{pipe},
che sono una delle caratteristiche peculiari del sistema, in particolar modo
dell'interfaccia a linea di comando. In questa sezione descriveremo le sue
basi, le funzioni che ne gestiscono l'uso e le varie forme in cui si è
evoluto.


\subsection{Le \textit{pipe} standard}
\label{sec:ipc_pipes}

Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, e tuttora
uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
sostanza di uno speciale tipo di file descriptor, più precisamente una coppia
di file descriptor,\footnote{si tenga presente che le pipe sono oggetti creati
  dal kernel e non risiedono su disco.}  su cui da una parte si scrive e da
un'altra si legge. Si viene così a costituire un canale di comunicazione
tramite i due file descriptor, nella forma di un \textsl{tubo} (da cui il
nome) in cui in genere un processo immette dati che poi arriveranno ad un
altro.

La funzione che permette di creare una pipe è appunto \func{pipe}; il suo
prototipo è:
\begin{prototype}{unistd.h}
{int pipe(int filedes[2])} 
  
Crea una coppia di file descriptor associati ad una pipe.
  
  \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
    errore, nel qual caso \var{errno} potrà assumere i valori \macro{EMFILE},
    \macro{ENFILE} e \macro{EFAULT}.}
\end{prototype}

La funzione restituisce una coppia di file descriptor nell'array
\param{filedes}; il primo aperto in lettura ed il secondo in scrittura. Il
concetto di funzionamento di una pipe è relativamente semplice, quello che si
scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
nel file descriptor aperto in lettura, da cui può essere riletto.

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 \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 indicano la direzione del flusso dei dati
attaverso la pipe.

\begin{figure}[htb]
  \centering
  \includegraphics[height=5cm]{img/pipe}
  \caption{Schema della struttura di una pipe.}
  \label{fig:ipc_pipe_singular}
\end{figure}

Chiaramente creare una pipe all'interno di un processo non serve a niente; se
però ricordiamo quanto esposto in \secref{sec:file_sharing} riguardo al
comportamento dei file descriptor nei processi figli, è immediato capire come
una pipe possa diventare un meccanismo di intercomunicazione. Un processo
figlio infatti condivide gli stessi file descriptor del padre, compresi quelli
associati ad una pipe (secondo la situazione illustrata in
\figref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
capo della pipe, l'altro può leggere.

\begin{figure}[htb]
  \centering
  \includegraphics[height=5cm]{img/pipefork}
  \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
  processo attraverso una \func{fork}.}
  \label{fig:ipc_pipe_fork}
\end{figure}

Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
comunicazione fra processi attraverso una pipe, utilizzando le ordinarie
proprietà dei file, ma ci mostra anche qual'è il principale\footnote{Stevens
  riporta in APUE come limite anche il fatto che la comunicazione è
  unidirezionale, in realtà questo è un limite facilmente risolvibile usando
  una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
processi possano condividere i file descriptor della pipe, e per questo essi
devono comunque derivare da uno stesso processo padre che ha aperto la pipe,
o, più comunemente, essere nella relazione padre/figlio.



\subsection{Un esempio dell'uso delle pipe}
\label{sec:ipc_pipe_use}

Per capire meglio il funzionamento di una pipe faremo un esempio di quello che
è il loro uso più comune, analogo a quello effettuato della shell, e che
consiste nell'inviare l'output di un processo (lo standard output) sull'input
di un'altro. Realizzaremo il programma nella forma di un
\textit{cgi-bin}\footnote{breve descrizione, da fare, di cosa è un cgi-bin.}
per apache, che genera una immagine JPEG di un codice a barre, specificato
come parametro di input.

Per fare questo useremo i programmi \cmd{barcode} e \cmd{gs}, il primo infatti
è in grado di generare immagini postscript di codici a barre corrispondenti ad
una qualunque stringa, data come parametro, mentre il secondo è in grado di
convertire un file postscript in una immagine JPEG. Usando l'ouptut del primo
come input del secondo attraverso una pipe potremo generare immagini JPEG del
codice a barre di una stringa qualunque. 

Si potrebbe obiettare che sarebbe molto più semplice ottenere lo stesso
risultato salvando il tutto in un file temporaneo, ma si dovrebbe comunque
risolvere il problema di come comunicare il nome di questo file da un processo
all'altro, dato che utilizzare lo stesso file porterebbe ad inevitabili
sovrascritture nell'accavallarsi di diversi processi. L'uso di una pipe
permette di risolvere il problema in maniera semplice ed elegante.

Il programma ci servirà anche come esempio dell'uso di alcune delle funzioni
di manipolazione dei file descriptor, come \func{dup} e \func{dup2}, viste in 
\secref{sec:file_dup}



\subsection{Le \textit{pipe} con nome, o \textit{fifo}}
\label{sec:ipc_named_pipe}

Per poter superare il problema delle \textit{pipe}, illustrato in
\secref{sec:ipc_pipes}, che ne consente l'uso solo fra procesi con un
progenitore comune o nella relazione padre/figlio, lo standard POSIX.1
definisce dei nuovi oggetti, le \textit{fifo}, che invece possono risiedere
sul filesystem, e che i processi possono usare per le comunicazioni senza
dovere per forza essere in relazione diretta.



  
\section{La comunicazione fra processi di System V}
\label{sec:ipc_sysv}

Per ovviare ai vari limiti dei meccanismo tradizionale di comunicazione fra
processi visto in \secref{sec:ipc_unix}, nello sviluppo di System V vennero
introdotti una serie di nuovi oggetti e relative interdacce che garantissero
una maggiore flessibilità; in questa sezione esamineremo quello che viene
ormai chiamato il \textit{System V Inter-Process Comunication System}, più
comunemente noto come \textit{SystemV IPC}.
 

\subsection{Code di messaggi}
\label{sec:ipc_messque}

Il primo oggetto introdotto dal \textit{SystemV IPC} è quello delle code di
messaggi.

\subsection{Semafori}
\label{sec:ipc_semaph}

Il secondo oggetto introdotto dal \textit{SystemV IPC} è quello dei semafori.


\subsection{Memoria condivisa}
\label{sec:ipc_shar_mem}

Il terzo oggetto introdotto dal \textit{SystemV IPC} è quello della memoria
condivisa.

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "gapil"
%%% End: 
