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 e quelli POSIX.
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 introdotto nei sistemi Unix,
24 è quello delle cosiddette \textit{pipe}; esse costituiscono una delle
25 caratteristiche peculiari del sistema, in particolar modo dell'interfaccia a
26 linea di comando. In questa sezione descriveremo le sue basi, le funzioni che
27 ne gestiscono l'uso e le varie forme in cui si è evoluto.
30 \subsection{Le \textit{pipe} standard}
33 Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, e tuttora
34 uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
35 sostanza di una una coppia di file descriptor\footnote{si tenga presente che
36 le pipe sono oggetti creati dal kernel e non risiedono su disco.} connessi
37 fra di loro in modo che se quanto scrive su di uno si può rileggere
38 dall'altro. Si viene così a costituire un canale di comunicazione tramite i
39 due file descriptor, nella forma di un \textsl{tubo} (da cui il nome)
40 attraverso cui fluiscono i dati.
42 La funzione che permette di creare questa speciale coppia di file descriptor
43 associati ad una \textit{pipe} è appunto \func{pipe}, ed il suo prototipo è:
44 \begin{prototype}{unistd.h}
45 {int pipe(int filedes[2])}
47 Crea una coppia di file descriptor associati ad una \textit{pipe}.
49 \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
50 errore, nel qual caso \var{errno} potrà assumere i valori \macro{EMFILE},
51 \macro{ENFILE} e \macro{EFAULT}.}
54 La funzione restituisce la coppia di file descriptor nell'array
55 \param{filedes}; il primo è aperto in lettura ed il secondo in scrittura. Come
56 accennato concetto di funzionamento di una pipe è semplice: quello che si
57 scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
58 nel file descriptor aperto in lettura. I file descriptor infatti non sono
59 connessi a nessun file reale, ma ad un buffer nel kernel, la cui dimensione è
60 specificata dalla costante \macro{PIPE\_BUF}, (vedi
61 \secref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
62 illustrato in \figref{fig:ipc_pipe_singular}, in cui sono illustrati i due
63 capi della pipe, associati a ciascun file descriptor, con le frecce che
64 indicano la direzione del flusso dei dati.
68 \includegraphics[height=5cm]{img/pipe}
69 \caption{Schema della struttura di una pipe.}
70 \label{fig:ipc_pipe_singular}
73 Chiaramente creare una pipe all'interno di un singolo processo non serve a
74 niente; se però ricordiamo quanto esposto in \secref{sec:file_sharing}
75 riguardo al comportamento dei file descriptor nei processi figli, è immediato
76 capire come una pipe possa diventare un meccanismo di intercomunicazione. Un
77 processo figlio infatti condivide gli stessi file descriptor del padre,
78 compresi quelli associati ad una pipe (secondo la situazione illustrata in
79 \figref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
80 capo della pipe, l'altro può leggere.
84 \includegraphics[height=5cm]{img/pipefork}
85 \caption{Schema dei collegamenti ad una pipe, condivisi fra processo padre e
86 figlio dopo l'esecuzione \func{fork}.}
87 \label{fig:ipc_pipe_fork}
90 Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
91 comunicazione fra processi attraverso una pipe, utilizzando le proprietà
92 ordinarie dei file, ma ci mostra anche qual'è il principale\footnote{Stevens
93 in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
94 unidirezionale, ma in realtà questo è un limite facilmente superabile usando
95 una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
96 processi possano condividere i file descriptor della pipe, e per questo essi
97 devono comunque derivare da uno stesso processo padre in cui è avvenuta la
98 creazione della pipe, o, più comunemente, essere nella relazione padre/figlio.
100 A differenza di quanto avviene con i file normali, la lettura da una pipe può
101 essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
102 pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
103 (vale a dire che la funzione \func{read} ritornerà restituendo 0). Se invece
104 si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
105 processo riceverà il segnale \macro{EPIPE}, e la funzione di scrittura
106 restituirà un errore di \macro{EPIPE} (al ritorno del manipolatore, o qualora
107 il segnale sia ignorato o bloccato).
109 La dimensione del buffer della pipe (\macro{PIPE\_BUF}) ci dà inoltre un'altra
110 importante informazione riguardo il comportamento delle operazioni di lettura
111 e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
112 quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
113 si effettui una scrittura di una quantità di dati superiore l'operazione verrà
114 effettuata in più riprese, consentendo l'intromissione di scritture effettuate
118 \subsection{Un esempio dell'uso delle pipe}
119 \label{sec:ipc_pipe_use}
121 Per capire meglio il funzionamento delle pipe faremo un esempio di quello che
122 è il loro uso più comune, analogo a quello effettuato della shell, e che
123 consiste nell'inviare l'output di un processo (lo standard output) sull'input
124 di un'altro. Realizzeremo il programma di esempio nella forma di un
125 \textit{CGI}\footnote{Un CGI (\textit{Common Gateway Interface}) è un
126 programma che permette la creazione dinamica di un oggetto da inserire
127 all'interno di una pagina HTML.} per apache, che genera una immagine JPEG
128 di un codice a barre, specificato come parametro di input.
130 Un programma che deve essere eseguito come \textit{CGI} deve rispondere a
131 delle caratteristiche specifiche, esso infatti non viene lanciato da una
132 shell, ma dallo stesso web server, alla richiesta di una specifica URL, che di
135 http://www.sito.it/cgi-bin/programma?parametro
137 ed il risultato dell'elaborazione deve essere presentato (con una intestazione
138 che ne descrive il mime-type) sullo standard output, in modo che il web-server
139 possa reinviarlo al browser che ha effettuato la richiesta, che in questo modo
140 è in grado di visualizzarlo opportunamente.
142 Per realizzare quanto voluto useremo in sequenza i programmi \cmd{barcode} e
143 \cmd{gs}, il primo infatti è in grado di generare immagini postscript di
144 codici a barre corrispondenti ad una qualunque stringa, mentre il secondo
145 serve per poter effettuare la conversione della stessa immagine in formato
146 JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
147 secondo, secondo lo schema mostrato in \figref{fig:ipc_pipe_use}, in cui la
148 direzione del flusso dei dati è data dalle frecce continue.
152 \includegraphics[height=5cm]{img/pipeuse}
153 \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
154 due processi attraverso attraverso l'esecuzione una \func{fork} e la
155 chiusura dei capi non utilizzati.}
156 \label{fig:ipc_pipe_use}
159 Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
160 intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
161 \textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
162 evidente race condition in caso di accesso simultaneo a detto
163 file.\footnote{il problema potrebbe essere superato determinando in anticipo
164 un nome appropriato per il file temporaneo, che verrebbe utilizzato dai vari
165 sotto-processi, e cancellato alla fine della loro esecuzione; ma a questo le
166 cose non sarebbero più tanto semplici.} L'uso di una pipe invece permette
167 di risolvere il problema in maniera semplice ed elegante, oltre ad essere
168 molto più efficiente, dato che non si deve scrivere su disco.
170 Il programma ci servirà anche come esempio dell'uso delle funzioni di
171 duplicazione dei file descriptor che abbiamo trattato in
172 \secref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
173 funzioni infatti che è possibile dirottare gli stream standard dei processi
174 (che abbiamo visto in \secref{sec:file_std_descr} e
175 \secref{sec:file_std_stream}) sulla pipe. In \figref{fig:ipc_barcodepage_code}
176 abbiamo riportato il corpo del programma, il cui codice completo è disponibile
177 nel file \file{BarCodePage.c} che si trova nella directory dei sorgenti.
181 \footnotesize \centering
182 \begin{minipage}[c]{15cm}
184 int main(int argc, char *argv[], char *envp[])
187 /* create two pipes, pipein and pipeout, to handle communication */
188 if ( (retval = pipe(pipein)) ) {
189 WriteMess("input pipe creation error");
192 if ( (retval = pipe(pipeout)) ) {
193 WriteMess("output pipe creation error");
196 /* First fork: use child to run barcode program */
197 if ( (pid = fork()) == -1) { /* on error exit */
198 WriteMess("child creation error");
203 close(pipein[1]); /* close pipe write end */
204 dup2(pipein[0], STDIN_FILENO); /* remap stdin to pipe read end */
206 dup2(pipeout[1], STDOUT_FILENO); /* remap stdout in pipe output */
207 execlp("barcode", "barcode", size, NULL);
209 close(pipein[0]); /* close input side of input pipe */
210 write(pipein[1], argv[1], strlen(argv[1])); /* write parameter to pipe */
211 close(pipein[1]); /* closing write end */
212 waitpid(pid, NULL, 0); /* wait child completion */
213 /* Second fork: use child to run ghostscript */
214 if ( (pid = fork()) == -1) {
215 WriteMess("child creation error");
218 /* second child, convert PS to JPEG */
220 close(pipeout[1]); /* close write end */
221 dup2(pipeout[0], STDIN_FILENO); /* remap read end to stdin */
223 write(STDOUT_FILENO, content, strlen(content));
224 execlp("gs", "gs", "-q", "-sDEVICE=jpeg", "-sOutputFile=-", "-", NULL);
228 waitpid(pid, NULL, 0);
234 \caption{Sezione principale del codice del \textit{CGI}
235 \file{BarCodePage.c}.}
236 \label{fig:ipc_barcodepage_code}
239 La prima operazione del programma (\texttt{\small 4--12}) è quella di creare
240 le due pipe che serviranno per la comunicazione fra i due comandi utilizzati
241 per produrre il codice a barre; si ha cura di controllare la riuscita della
242 chiamata, inviando in caso di errore un messaggio invece dell'immagine
243 richiesta.\footnote{la funzione \func{WriteMess} non è riportata in
244 \secref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
245 formattare l'uscita alla maniera dei CGI, aggiungendo l'opportuno
246 \textit{mime type}, e formattando il messaggio in HTML, in modo che
247 quest'ultimo possa essere visualizzato correttamente da un browser.}
249 Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
250 primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
251 \cmd{barcode}. Quest'ultimo legge dallo standard input una stringa di
252 caratteri, la converte nell'immagine postscript del codice a barre ad essa
253 corrispondente, e poi scrive il risultato direttamente sullo standard output.
255 Per poter utilizzare queste caratteristiche prima di eseguire \cmd{barcode} si
256 chiude (\texttt{\small 20}) il capo aperto in scrittura della prima pipe, e se
257 ne collega (\texttt{\small 21}) il capo in lettura allo standard input, usando
258 \func{dup2}. Si ricordi che invocando \func{dup2} il secondo file, qualora
259 risulti aperto, viene, come nel caso corrente, chiuso prima di effettuare la
260 duplicazione. Allo stesso modo, dato che \cmd{barcode} scrive l'immagine
261 postscript del codice a barre sullo standard output, per poter effettuare una
262 ulteriore redirezione il capo in lettura della seconda pipe viene chiuso
263 (\texttt{\small 22}) mentre il capo in scrittura viene collegato allo standard
264 output (\texttt{\small 23}).
266 In questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} (cui si
267 passa in \var{size} la dimensione della pagina per l'immagine) quest'ultimo
268 leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
269 padre, e scriverà l'immagine postscript del codice a barre sulla seconda.
271 Al contempo una volta lanciato il primo figlio, il processo padre prima chiude
272 (\texttt{\small 26}) il capo inutilizzato della prima pipe (quello in input) e
273 poi scrive (\texttt{\small 27}) la stringa da convertire sul capo in output,
274 così che \cmd{barcode} possa riceverla dallo standard input. A questo punto
275 l'uso della prima pipe da parte del padre è finito ed essa può essere
276 definitivamente chiusa (\texttt{\small 28}), si attende poi (\texttt{\small
277 29}) che l'esecuzione di \cmd{barcode} sia completata.
279 Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
280 postscript del codice a barre sul capo in scrittura della seconda pipe; a
281 questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
282 programma \cmd{gs}. Per questo si crea (\texttt{\small 30--34}) un secondo
283 processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
284 leggendo l'immagine postscript creata da \cmd{barcode} dallo standard input,
285 per convertirla in JPEG.
287 Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
288 scrittura della seconda pipe, e se ne collega (\texttt{\small 38}) il capo in
289 lettura allo standard input. Per poter formattare l'output del programma in
290 maniera utilizzabile da un browser, si provvede anche \texttt{\small 40}) alla
291 scrittura dell'apposita stringa di identificazione del mime-type in testa allo
292 standard output. A questo punto si può invocare \texttt{\small 41}) \cmd{gs},
293 provvedendo gli appositi switch che consentono di leggere il file da
294 convertire dallo standard input e di inviare la conversione sullo standard
297 Per completare le operazioni il processo padre chiude (\texttt{\small 44}) il
298 capo in scrittura della seconda pipe, e attende la conclusione del figlio
299 (\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
300 conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
301 necessaria, infatti, se non venisse chiusa, \cmd{gs}, che legge il suo
302 standard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati
303 in ingresso (l'unico modo che un programma ha per sapere che l'input è
304 terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
308 \subsection{Le funzioni \func{popen} e \func{pclose}}
309 \label{sec:ipc_popen}
311 Come si è visto la modalità più comune di utilizzo di una pipe è quella di
312 utilizzarla per fare da tramite fra output ed input di due programmi invocati
313 in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
314 che permettono di sintetizzare queste operazioni. La prima di esse si chiama
315 \func{popen} ed il suo prototipo è:
316 \begin{prototype}{stdio.h}
317 {FILE *popen(const char *command, const char *type)}
319 Esegue il programma \param{command}, di cui, a seconda di \param{type},
320 restituisce, lo standard input o lo standard output nella pipe collegata allo
321 stream restituito come valore di ritorno.
323 \bodydesc{La funzione restituisce l'indirizzo dello stream associato alla pipe
324 in caso di successo e \macro{NULL} per un errore, nel qual caso \var{errno}
325 potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
326 e \func{fork} o \macro{EINVAL} se \param{type} non è valido.}
329 La funzione crea una pipe, esegue una \func{fork}, ed invoca il programma
330 \param{command} attraverso la shell (in sostanza esegue \file{/bin/sh} con il
331 flag \code{-c}); l'argomento \param{type} deve essere una delle due stringhe
332 \verb|"w"| o \verb|"r"|, per indicare se la pipe sarà collegata allo standard
333 input o allo standard output del comando invocato.
335 La funzione restituisce il puntatore allo stream associato alla pipe creata,
336 che sarà aperto in sola lettura (e quindi associato allo standard output del
337 programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
338 quindi associato allo standard input) in caso di \code{"w"}.
340 Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
341 stream visti in \secref{cha:files_std_interface}, anche se è collegato ad una
342 pipe e non ad un inode, e viene sempre aperto in modalità
343 \textit{fully-buffered} (vedi \secref{sec:file_buffering}); l'unica differenza
344 con gli usuali stream è che dovrà essere chiuso dalla seconda delle due nuove
345 funzioni, \func{pclose}, il cui prototipo è:
346 \begin{prototype}{stdio.h}
347 {int pclose(FILE *stream)}
349 Chiude il file \param{stream}, restituito da una precedente \func{popen}
350 attendendo la terminazione del processo ad essa associato.
352 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
353 errore; nel quel caso il valore di \func{errno} deriva dalle sottostanti
356 \noindent che oltre alla chiusura dello stream si incarica anche di attendere
357 (tramite \func{wait4}) la conclusione del processo creato dalla precedente
360 Per illustrare l'uso di queste due funzioni riprendiamo il problema
361 precedente: il programma mostrato in \figref{fig:ipc_barcodepage_code} per
362 quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
363 inoltre nella pratica sconta un problema di \cmd{gs} che non è in
364 grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
365 riconoscere correttamente l'encapsulated postscript, per cui deve essere usato
366 il postscript e tutte le volte viene generata una pagina intera, invece che
367 una immagine delle dimensioni corrispondenti al codice a barre.
369 Se si vuole generare una immagine di dimensioni appropriate si deve usare un
370 approccio diverso. Una possibilità sarebbe quella di ricorrere ad ulteriore
371 programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
372 generato da \cmd{barcode} utilizzando lo switch \cmd{-E}). Utilizzando un PDF
373 al posto di un EPS \cmd{gs} esegue la conversione rispettando le dimensioni
374 originarie del codice a barre e produce un JPEG di dimensioni corrette.
376 Questo approccio però non funziona, per via di una delle caratteristiche
377 principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
378 necessario, per la struttura del formato, potersi spostare (con \func{lseek})
379 all'interno del file da convertire; se si eseguela conversione con \cmd{gs} su
380 un file regolare non ci sono problemi, una pipe però è rigidamente
381 sequenziale, e l'uso di \func{lseek} su di essa fallisce sempre con un errore
382 di \macro{ESPIPE}, rendendo impossibile la conversione. Questo ci dice che in
383 generale la concatenazione di vari programmi funzionerà soltanto quando tutti
384 prevedono una lettura sequenziale del loro input.
386 Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
387 prima la conversione (sempre con \cmd{gs}) del PS in un altro formato
388 intermedio, il PPM,\footnote{il \textit{Portable PixMap file format} è un
389 formato usato spesso come formato intermedio per effettuare conversioni, è
390 infatti molto facile da manipolare, dato che usa caratteri ASCII per
391 memorizzare le immagini, anche se per questo è estremamente inefficiente.}
392 dal quale poi si può ottenere un'immagine di dimensioni corrette attraverso
393 vari programmi di manipolazione (\cmd{pnmcrop}, \cmd{pnmmargin}) che può
394 essere infine trasformata in PNG (con \cmd{pnm2png}).
396 In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
397 inviando l'output di ciascuno all'input del successivo, per poi ottenere il
398 risultato finale sullo standard output: un caso classico di utilizzazione
399 delle pipe, in cui l'uso di \func{popen} e \func{pclose} permette di
400 semplificare notevolmente la stesura del codice.
402 Nel nostro caso, dato che ciascun processo deve scrivere il suo output sullo
403 standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
404 scrittura. Il codice del nuovo programma è riportato in
405 \figref{fig:ipc_barcode_code}. Come si può notare l'ordine di invocazione dei
406 programmi è l'inverso di quello in cui ci si aspetta che vengano
407 effettivamente eseguiti. Questo non comporta nessun problema dato che la
408 lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
409 per primo, si bloccherà in attesa di ricevere sullo standard input il
410 risultato dell'elaborazione del precedente, benchè quest'ultimo venga
414 \footnotesize \centering
415 \begin{minipage}[c]{15cm}
417 int main(int argc, char *argv[], char *envp[])
421 char *cmd_string[4]={
423 "pnmmargin -white 10",
425 "gs -sDEVICE=ppmraw -sOutputFile=- -sNOPAUSE -q - -c showpage -c quit"
427 char content[]="Content-type: image/png\n\n";
429 /* write mime-type to stout */
430 write(STDOUT_FILENO, content, strlen(content));
431 /* execute chain of command */
432 for (i=0; i<4; i++) {
433 pipe[i] = popen(cmd_string[i], "w");
434 dup2(fileno(pipe[i]), STDOUT_FILENO);
436 /* create barcode (in PS) */
437 pipein = popen("barcode", "w");
438 /* send barcode string to barcode program */
439 write(fileno(pipein), argv[1], strlen(argv[1]));
440 /* close all pipes (in reverse order) */
441 for (i=4; i==0; i--) {
449 \caption{Codice completo del \textit{CGI} \file{BarCode.c}.}
450 \label{fig:ipc_barcode_code}
453 Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il mime-type
454 sullo standard output; a questo punto il processo padre non necessita più di
455 eseguire ulteriori operazioni sullo standard output e può tranquillamente
456 provvedere alla redirezione.
458 Dato che i vari programmi devono essere lanciati in successione, si è
459 approntato un ciclo (\texttt{\small 15--19}) che esegue le operazioni in
460 sequenza: prima crea una pipe (\texttt{\small 17}) per la scrittura eseguendo
461 il programma con \func{popen}, in modo che essa sia collegata allo standard
462 input, e poi redirige (\texttt{\small 18}) lo standard output su detta pipe.
464 In questo modo il primo processo ad essere invocato (che è l'ultimo della
465 catena) scriverà ancora sullo standard output del processo padre, ma i
466 successivi, a causa di questa redirezione, scriveranno sulla pipe associata
467 allo standard input del processo invocato nel ciclo precedente.
469 Alla fine tutto quello che resta da fare è lanciare (\texttt{\small 21}) il
470 primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
471 (\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
472 al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
473 ciclo che chiuda, nell'ordine inverso rispetto a quello in cui le si sono
474 create, tutte le pipe create con \func{pclose}.
477 \subsection{Le \textit{pipe} con nome, o \textit{fifo}}
478 \label{sec:ipc_named_pipe}
480 Come accennato in \secref{sec:ipc_pipes} il problema delle \textit{pipe} è che
481 esse possono essere utilizzate solo da processi con un progenitore comune o
482 nella relazione padre/figlio; per superare questo problema lo standard POSIX.1
483 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
484 caratteristiche delle pipe, ma che invece di essere strutture interne del
485 kernel, visibili solo attraverso un file descriptor, sono accessibili
486 attraverso un inode che risiede sul filesystem, così che i processi le possono
487 usare senza dovere per forza essere in una relazione di \textsl{parentela}.
489 Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
490 attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
491 l'inode allocato sul filesystem serve infatti solo a fornire un punto di
492 riferimento per i processi, che permetta loro di accedere alla stessa fifo; il
493 comportamento delle funzioni di lettura e scrittura è identico a quello
494 illustrato per le pipe in \secref{sec:ipc_pipes}.
496 Abbiamo già visto in \secref{sec:file_mknod} le funzioni \func{mknod} e
497 \func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
498 processo non avrà che da aprire il relativo file speciale o in lettura o
499 scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
500 leggere, nel secondo al capo di ingresso, e dovrà scrivere.
502 Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
503 essere acceduta contemporaneamente da più processi, sia in lettura che in
504 scrittura. Dato che per funzionare deve essere aperta in entrambe le
505 direzioni, per una fifo di norma la funzione \func{open} si blocca se viene
506 eseguita quando l'altro capo non è aperto.
508 Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
509 nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
510 l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
511 l'errore di \macro{ENXIO} fintanto che non verrà aperto il capo in lettura.
513 In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
514 standard POSIX lascia indefinito il comportamento in questo caso.}
515 operazione che avrà sempre successo immediato qualunque sia la modalità di
516 apertura (bloccante e non bloccante); questo può essere utilizzato per aprire
517 comunque una fifo in scrittura anche se non ci sono ancora processi il
518 lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
519 qual caso però occorre stare molto attenti alla possibili
520 deadlock.\footnote{se si cerca di leggere da una fifo che non contiene dati si
521 avrà un deadlock immediato, dato che il processo si blocca e non potrà
522 quindi mai eseguire le funzioni di scrittura.}
524 Per la loro caratteristica di essere accessibili attraverso il filesystem, è
525 piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
526 situazioni un processo deve ricevere informazioni da altri. In questo caso è
527 fondamentale che le operazioni di scrittura siano atomiche; per questo si deve
528 sempre tenere presente che questo è vero soltanto fintanto che non si supera
529 il limite delle dimensioni di \macro{PIPE\_BUF} (si ricordi quanto detto in
530 \secref{sec:ipc_pipes}).
532 A parte il caso precedente, che resta probabilmente il più comune, Stevens
533 riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
535 \item Da parte dei comandi di shell, per evitare la creazione di file
536 temporanei quando si devono inviare i dati di uscita di un processo
537 sull'input di parecchi altri (attraverso l'uso del comando \cmd{tee}).
539 \item Come canale di comunicazione fra client ed server (il modello
540 \textit{client-server} è illustrato in \secref{sec:net_cliserv}).
543 Nel primo caso quello che si fa è creare tante fifo, da usare come standard
544 input, quanti sono i processi a cui i vogliono inviare i dati, questi ultimi
545 saranno stati posti in esecuzione ridirigendo lo standard input dalle fifo, si
546 potrà poi eseguire il processo che fornisce l'output replicando quest'ultimo,
547 con il comando \cmd{tee}, sulle varie fifo.
549 Il secondo caso è relativamente semplice qualora si debba comunicare con un
550 processo alla volta (nel qual caso basta usare due fifo, una per leggere ed
551 una per scrivere), le cose diventano invece molto più complesse quando si
552 vuole effettuare una comunicazione fra il server ed un numero imprecisato di
553 client; se il primo infatti può ricevere le richieste attraverso una fifo
554 ``nota'', per le risposte non si può fare altrettanto, dato che, per la
555 struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
556 leggerli, quando i dati inviati sono destinati a loro.
558 Per risolvere questo problema, si può usare un'architettura come quella
559 illustrata da Stevens in \cite{APUE}, in cui le risposte vengono inviate su
560 fifo temporanee identificate dal \acr{pid} dei client, ma in ogni caso il
561 sistema è macchinoso e continua ad avere vari inconvenienti\footnote{lo stesso
562 Stevens nota come sia impossibile per il server sapere se un client è andato
563 in crash, con la possibilità di far restare le fifo temporanee sul
564 filesystem, come sia necessario intercettare \macro{SIGPIPE} dato che un
565 client può terminare dopo aver fatto una richiesta, ma prima che la risposta
566 sia inviata, e come occorra gestire il caso in cui non ci sono client attivi
567 (e la lettura dalla fifo nota restituisca al serve un end-of-file.}; in
568 generale infatti l'interfaccia delle fifo non è adatta a risolvere questo tipo
569 di problemi, che possono essere affrontati in maniera più semplice ed efficace
570 o usando i \textit{socket}\index{socket} (che tratteremo in dettaglio a
571 partire da \capref{cha:socket_intro}) o ricorrendo a meccanismi di
572 comunicazione diversi, come quelli che esamineremo in seguito.
576 \section{La comunicazione fra processi di System V}
579 Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
580 limite fondamentale che il meccanismo di comunicazione che forniscono è
581 rigidamente sequenziale: una situazione in cui un processo scrive qualcosa che
582 molti altri devono poter leggere non può essere implementata con una pipe.
584 Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
585 oggetti per la comunicazione fra processi ed una nuova interfaccia di
586 programmazione, che fossero in grado di garantire una maggiore flessibilità;
587 in questa sezione esamineremo quello che viene ormai chiamato il
588 \textsl{Sistema di comunicazione inter-processo} di System V, (o
589 \textit{System V IPC (Inter-Process Comunication)}.
593 \subsection{Considerazioni generali}
594 \label{sec:ipc_sysv_generic}
596 La principale caratteristica del sistema di IPC di System V è quella di essere
597 basato su oggetti permanenti che risiedono nel kernel. Questi, a differenza di
598 quanto avviene per i file descriptor, non mantengono un contatore dei
599 riferimenti, e non vengono cancellati dal sistema una volta che non sono più
600 in uso. Questo comporta che, al contrario di quanto avviene per pipe e fifo,
601 la memoria allocata per questi oggetti non viene rilasciata automaticamente,
602 ed essi devono essere cancellati esplicitamente, altrimenti resteranno attivi
603 fino al riavvio del sistema.
605 Gli oggetti usati nel System V IPC vengono creati direttamente dal kernel, e
606 sono accessibili solo specificando il relativo \textsl{identificatore}. Questo
607 è il numero progressivo che il kernel assengna a ciascuno di questi oggetti
608 quanto vengono creati (il prodedimento è simile a quello con cui si assegna il
609 \acr{pid} ai processi).
611 L'identificatore è in genere restituito dalle funzioni che creano l'oggetto,
612 nasce quindi il problema di come processi diversi possono accedere allo stesso
613 oggetto. Per far questo a ciascuno di essi viene anche associata una
614 \textsl{chiave}, che può essere indicata in fasi di creazione. Usando la
615 stessa chiave due processi diversi potranno ricavare l'identificatore
616 associato ad un oggetto e accedervi entrambi.
618 Il problema che sorge a questo punto è come due processi diversi possono
621 \subsection{Code di messaggi}
622 \label{sec:ipc_messque}
624 Il primo oggetto introdotto dal \textit{System V IPC} è quello delle code di
627 \subsection{Semafori}
628 \label{sec:ipc_semaph}
630 Il secondo oggetto introdotto dal \textit{System V IPC} è quello dei semafori.
633 \subsection{Memoria condivisa}
634 \label{sec:ipc_shar_mem}
636 Il terzo oggetto introdotto dal \textit{System V IPC} è quello della memoria
642 \section{La comunicazione fra processi di POSIX}
643 \label{sec:ipc_posix}
645 Lo standard POSIX.1b ha introdotto dei nuovi meccanismi di comunicazione,
646 rifacendosi a quelli di System V, introducendo una nuova interfaccia che
647 evitasse i principali problemi evidenziati in coda a
648 \secref{sec:ipc_sysv_generic}.
655 %%% TeX-master: "gapil"