1 \chapter{La comunicazione fra processi}
5 Uno degli aspetti fondamentali della programmazione in un sistema unix-like è
6 la comunicazione fra processi. In questo capitolo affronteremo solo i
7 meccanismi più elementari che permettono di mettere in comunicazione processi
8 diversi, come quelli tradizionali che coinvolgono \textit{pipe} e
9 \textit{fifo} e i meccanismi di intercomunicazione di System V.
11 Tralasceremo invece tutte le problematiche relative alla comunicazione
12 attraverso la rete (e le relative interfacce) che saranno affrontate in
13 dettaglio in un secondo tempo. Non affronteremo invece meccanismi più
14 complessi ed evoluti come le RPC (\textit{Remote Procedure Calls}) e CORBA
15 (\textit{Common Object Request Brocker Architecture}) che in genere sono
16 implementati con un ulteriore livello sopra i meccanismi elementari.
20 \section{La comunicazione fra processi tradizionale}
23 Il primo meccanismo di comunicazione fra processi usato dai sistemi unix-like,
24 e quello che viene correntemente usato di più, è quello delle \textit{pipe},
25 che sono una delle caratteristiche peculiari del sistema, in particolar modo
26 dell'interfaccia a linea di comando. In questa sezione descriveremo le sue
27 basi, le funzioni che ne gestiscono l'uso e le varie forme in cui si è
31 \subsection{Le \textit{pipe} standard}
34 Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, e tuttora
35 uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
36 sostanza di uno speciale tipo di file descriptor, più precisamente una coppia
37 di file descriptor,\footnote{si tenga presente che le pipe sono oggetti creati
38 dal kernel e non risiedono su disco.} su cui da una parte si scrive e da
39 un'altra si legge. Si viene così a costituire un canale di comunicazione
40 tramite i due file descriptor, nella forma di un \textsl{tubo} (da cui il
41 nome) in cui in genere un processo immette dati che poi arriveranno ad un
44 La funzione che permette di creare una pipe è appunto \func{pipe}; il suo
46 \begin{prototype}{unistd.h}
47 {int pipe(int filedes[2])}
49 Crea una coppia di file descriptor associati ad una pipe.
51 \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
52 errore, nel qual caso \var{errno} potrà assumere i valori \macro{EMFILE},
53 \macro{ENFILE} e \macro{EFAULT}.}
56 La funzione restituisce una coppia di file descriptor nell'array
57 \param{filedes}; il primo aperto in lettura ed il secondo in scrittura. Il
58 concetto di funzionamento di una pipe è relativamente semplice, quello che si
59 scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
60 nel file descriptor aperto in lettura, da cui può essere riletto.
62 I file descriptor infatti non sono connessi a nessun file reale, ma ad un
63 buffer nel kernel, la cui dimensione è specificata dalla costante
64 \macro{PIPE\_BUF}, (vedi \secref{sec:sys_file_limits}); lo schema di
65 funzionamento di una pipe è illustrato in \figref{fig:ipc_pipe_singular}, in
66 cui sono illustrati i due capi della pipe, associati a ciascun file
67 descriptor, con le frecce che indicano la direzione del flusso dei dati
72 \includegraphics[height=5cm]{img/pipe}
73 \caption{Schema della struttura di una pipe.}
74 \label{fig:ipc_pipe_singular}
77 Chiaramente creare una pipe all'interno di un processo non serve a niente; se
78 però ricordiamo quanto esposto in \secref{sec:file_sharing} riguardo al
79 comportamento dei file descriptor nei processi figli, è immediato capire come
80 una pipe possa diventare un meccanismo di intercomunicazione. Un processo
81 figlio infatti condivide gli stessi file descriptor del padre, compresi quelli
82 associati ad una pipe (secondo la situazione illustrata in
83 \figref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
84 capo della pipe, l'altro può leggere.
88 \includegraphics[height=5cm]{img/pipefork}
89 \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
90 processo attraverso una \func{fork}.}
91 \label{fig:ipc_pipe_fork}
94 Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
95 comunicazione fra processi attraverso una pipe, utilizzando le ordinarie
96 proprietà dei file, ma ci mostra anche qual'è il principale\footnote{Stevens
97 riporta in APUE come limite anche il fatto che la comunicazione è
98 unidirezionale, in realtà questo è un limite facilmente risolvibile usando
99 una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
100 processi possano condividere i file descriptor della pipe, e per questo essi
101 devono comunque derivare da uno stesso processo padre che ha aperto la pipe,
102 o, più comunemente, essere nella relazione padre/figlio.
106 \subsection{Un esempio dell'uso delle pipe}
107 \label{sec:ipc_pipe_use}
109 Per capire meglio il funzionamento di una pipe faremo un esempio di quello che
110 è il loro uso più comune, analogo a quello effettuato della shell, e che
111 consiste nell'inviare l'output di un processo (lo standard output) sull'input
112 di un'altro. Realizzaremo il programma nella forma di un
113 \textit{cgi-bin}\footnote{NdA, inserire una breve descrizione di cosa è un
114 cgi-bin.} per apache, che genera una immagine JPEG di un codice a barre,
115 specificato come parametro di input.
117 Un programma che deve essere eseguito come \textit{cgi-bin} per apache deve
118 rispondere a delle caratteristiche specifiche, esso infatti non viene lanciato
119 da una shell, ma dallo stesso web server, alla richiesta di una specifica URL
120 che di solito ha la forma:
122 http://www.sito.it/cgi-bin/programma?parametro
124 ed il risultato dell'elaborazione deve essere presentato (con una intestazione
125 che ne descrive il mime-type) sullo standard output, in modo che apache possa
126 reinviarlo al browser che ha effettuato la richiesta.
129 Per fare questo useremo in sequenza i programmi \cmd{barcode} e \cmd{gs}, il
130 primo infatti è in grado di generare immagini postscript di codici a barre
131 corrispondenti ad una qualunque stringa, mentre il secondo serve per poter
132 effettuare la conversione della stessa immagine in formato JPEG.
134 Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
135 intermedio su un file temporaneo. Questo però non tiene conto del fatto che il
136 \textit{cgi-bin} deve poter gestire più richieste in concorrenza, e si avrebbe
137 una evidente race condition in caso di accesso simultaneo a detto
138 file.\footnote{la questione potrebbe essere evitata creando prima dei file
139 temporanei, da comunicare poi ai vari sotto-processi, da cancellare alla
140 fine dell'esecuzione; ma a questo punto avremmo perso tutta la semplicità.}
141 L'uso di una pipe invece permette di risolvere il problema in maniera semplice
144 Il programma ci servirà anche come esempio dell'uso di alcune delle funzioni
145 di manipolazione dei file descriptor, come \func{dup} e \func{dup2}, viste in
146 \secref{sec:file_dup}; è attraverso queste funzioni che è possibile dirottare
147 gli stream standard dei processi (che abbiamo visto in
148 \secref{sec:file_std_descr} e \secref{sec:file_std_stream}) sulla pipe. Le
149 sezioni significative del programma è riportato in
150 \figref{fig:ipc_barcode_code}, il codice è disponibile nel file
151 \file{BarCode.c} nella directory dei sorgenti.
155 \footnotesize \centering
156 \begin{minipage}[c]{15cm}
158 int main(int argc, char *argv[], char *envp[])
161 /* create two pipes to handle process communication */
162 if ( (retval = pipe(pipein)) ) {
163 WriteMess("input pipe creation error");
166 if ( (retval = pipe(pipeout)) ) {
167 WriteMess("output pipe creation error");
170 /* First fork: use child to run barcode program */
171 if ( (pid = fork()) == -1) { /* on error exit */
172 WriteMess("child creation error");
177 close(pipein[1]); /* close pipe write end */
178 dup2(pipein[0], STDIN_FILENO); /* remap stdin to pipe read end */
180 dup2(pipeout[1], STDOUT_FILENO); /* remap stdout in pipe output */
181 execlp("barcode", "barcode", size, NULL); //"-o", "-", NULL);
183 close(pipein[0]); /* close input side of input pipe */
184 write(pipein[1], argv[1], strlen(argv[1])); /* write parameter to pipe */
185 close(pipein[1]); /* closing write end */
186 waitpid(pid, NULL, 0); /* wait child completion */
187 /* Second fork: use child to run ghostscript */
188 if ( (pid = fork()) == -1) { /* on error exit */
189 WriteMess("child creation error");
192 /* second child, convert PS to JPEG */
194 close(pipeout[1]); /* close write end */
195 dup2(pipeout[0], STDIN_FILENO); /* remap read end to stdin */
197 write(STDOUT_FILENO, content, strlen(content));
198 execlp("gs", "gs", "-q", "-sDEVICE=jpeg", "-sOutputFile=-", "-", NULL);
202 waitpid(pid, NULL, 0);
208 \caption{Codice del \textit{cgi-bin} \cmd{BarCode}.}
209 \label{fig:ipc_barcode_code}
213 Il primo passo (\texttt{\small 4-12}) è quello di creare le due pipe che
214 servono per la comunicazione fra i due programmi che verranno utilizzati per
215 produrre il codice a barre; si ha cura di controllare la riuscita della
216 chiamata, inviando in caso di errore un messaggio invece dell'immagine
217 richiesta.\footnote{la funzione \func{WriteMess}, non è riportata in
218 \ref{fig:ipc_barcode_code}, ma si incarica semplicemente di formattare
219 l'uscita, aggiungendo un \textit{mime type}, in modo che possa essere
220 interpretata direttamente da un browser.}
222 Una volta create le pipe il programma può creare (\texttt{\small 13-17}) il
223 primo processo figlio, che si incaricherà (\texttt{\small 19-25}) di eseguire
224 il programma \cmd{barcode}: quest'ultimo funziona ricevendo dallo standard
225 input la stringa da convertire nell'immagine postscript del codice a barre,
226 che sarà scritta sullo standard output.
228 Per utilizzare queste caratteristiche il primo figlio chiude (\texttt{\small
229 21}) il capo aperto in scrittura della prima pipe, dato che userà il capo
230 aperto in lettura per ricevere dal padre la stringa da codificare; per far
231 questo collega (\texttt{\small 22}) il capo in lettura allo standard input
236 Analogamente il capo in lettura della seconda pipe sarà chiuso mentre il capo
237 in scrittura viene collegato allo standard output (\texttt{\small 23-24}. In
238 questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} quest'ultimo
239 leggerà la stringa da codificare dalla prima pipe e scriverà l'immagine
240 postscript nella seconda.
242 Dall'altra parte il processo padre prima chiude (\texttt{\small 28-29}) i due
243 capi inutilizzati delle pipe (input della prima ed output della seconda), poi
244 scrive (\texttt{\small 30}) la stringa da convertire sull'output della prima
245 pipe così che \cmd{barcode} possa riceverla dallo standard input; a questo
246 punto l'uso della prima pipe è finito ed essa può essere definitivamente
247 chiusa (\texttt{\small 31}), si attenderà poi (\texttt{\small 32}) che
248 l'esecuzione di \cmd{barcode} venga completata.
250 Alla conclusione della sua esecuzione \cmd{barcode} avrà effettuato inviato
251 l'immagine postscript del codice a barre sul capo in scrittura della seconda
257 \subsection{Le funzioni \func{popen} e \func{pclose}}
258 \label{sec:ipc_popen}
260 Come si è visto la modalità più comune di utilizzo di una pipe è quella di
261 utilizzarla per fare da tramite fra output ed input di due programmi invocati
262 in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
263 che permettono di sintetizzare queste operazioni comuni in una sola
264 chiamata. La prima di esse si chiama \func{popen} ed il suo prototipo è:
267 L'esempio in \figref{fig:ipc_barcode_code} per quanto perfettamente
268 funzionante, è piuttosto complesso; inoltre nella pratica sconta un problema
269 di \cmd{gs} che non è in grado\footnote{nella versione GNU Ghostscript 6.53
270 (2002-02-13).} di riconoscere correttamente l'encapsulated postscript, per
271 cui tutte le volte generata una pagina intera, invece che una semplice figura.
272 Se si vuole generare una immagine di dimensioni corrette si deve allora
273 ricorrere ad ulteriore programma, \cmd{epstopsf}, per convertire in PDF il
274 file EPS generato da \cmd{barcode}, che invece viene trattato correttamente.
281 \subsection{Le \textit{pipe} con nome, o \textit{fifo}}
282 \label{sec:ipc_named_pipe}
284 Per poter superare il problema delle \textit{pipe}, illustrato in
285 \secref{sec:ipc_pipes}, che ne consente l'uso solo fra processi con un
286 progenitore comune o nella relazione padre/figlio, lo standard POSIX.1
287 definisce dei nuovi oggetti, le \textit{fifo}, che invece possono risiedere
288 sul filesystem, e che i processi possono usare per le comunicazioni senza
289 dovere per forza essere in relazione diretta.
294 \section{La comunicazione fra processi di System V}
297 Per ovviare ai vari limiti dei meccanismo tradizionale di comunicazione fra
298 processi visto in \secref{sec:ipc_unix}, nello sviluppo di System V vennero
299 introdotti una serie di nuovi oggetti e relative interfacce che garantissero
300 una maggiore flessibilità; in questa sezione esamineremo quello che viene
301 ormai chiamato il \textit{System V Inter-Process Comunication System}, più
302 comunemente noto come \textit{SystemV IPC}.
305 \subsection{Code di messaggi}
306 \label{sec:ipc_messque}
308 Il primo oggetto introdotto dal \textit{SystemV IPC} è quello delle code di
311 \subsection{Semafori}
312 \label{sec:ipc_semaph}
314 Il secondo oggetto introdotto dal \textit{SystemV IPC} è quello dei semafori.
317 \subsection{Memoria condivisa}
318 \label{sec:ipc_shar_mem}
320 Il terzo oggetto introdotto dal \textit{SystemV IPC} è quello della memoria
325 %%% TeX-master: "gapil"