ipc.tex

   1 \chapter{La comunicazione fra processi}
   2 \label{cha:IPC}
   3
   4
   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.
  10
  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.
  17
  18
  19
  20 \section{La comunicazione fra processi tradizionale}
  21 \label{sec:ipc_unix}
  22
  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 è
  28 evoluto.
  29
  30
  31 \subsection{Le \textit{pipe} standard}
  32 \label{sec:ipc_pipes}
  33
  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
  42 altro.
  43
  44 La funzione che permette di creare una pipe è appunto \func{pipe}; il suo
  45 prototipo è:
  46 \begin{prototype}{unistd.h}
  47 {int pipe(int filedes[2])}
  48
  49 Crea una coppia di file descriptor associati ad una pipe.
  50
  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}.}
  54 \end{prototype}
  55
  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.
  61
  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
  68 attraverso la pipe.
  69
  70 \begin{figure}[htb]
  71   \centering
  72   \includegraphics[height=5cm]{img/pipe}
  73   \caption{Schema della struttura di una pipe.}
  74   \label{fig:ipc_pipe_singular}
  75 \end{figure}
  76
  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.
  85
  86 \begin{figure}[htb]
  87   \centering
  88   \includegraphics[height=5cm]{img/pipefork}
  89   \caption{Schema dei collegamenti ad una pipe, condivisi fra processo padre e
  90     figlio dopo l'esecuzione \func{fork}.}
  91   \label{fig:ipc_pipe_fork}
  92 \end{figure}
  93
  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   in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
  98   unidirezionale, in realtà questo è un limite facilmente superabile 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.
 103
 104 A differenza di quanto avviene con i file normali la lettura da una pipe può
 105 essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
 106 pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
 107 (vale a dire che la funzione \func{read} ritornerà restituendo 0).  Se invece
 108 si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
 109 processo riceverà il segnale \macro{EPIPE}, e la funzione di scrittura
 110 restituirà un errore di \macro{EPIPE} (al ritorno del manipolatore, o qualora
 111 il segnale sia ignorato o bloccato).
 112
 113
 114
 115 \subsection{Un esempio dell'uso delle pipe}
 116 \label{sec:ipc_pipe_use}
 117
 118 Per capire meglio il funzionamento di una pipe faremo un esempio di quello che
 119 è il loro uso più comune, analogo a quello effettuato della shell, e che
 120 consiste nell'inviare l'output di un processo (lo standard output) sull'input
 121 di un'altro. Realizzaremo il programma nella forma di un
 122 \textit{CGI}\footnote{Un CGI (\textit{Common Gateway Interface}) è un programma
 123   che permette la creazione dinamica di un oggetto da inserire all'interno di
 124   una pagina HTML.}  per apache, che genera una immagine JPEG di un codice a
 125 barre, specificato come parametro di input.
 126
 127 Un programma che deve essere eseguito come \textit{CGI} deve rispondere a
 128 delle caratteristiche specifiche, esso infatti non viene lanciato da una
 129 shell, ma dallo stesso web server, alla richiesta di una specifica URL, che di
 130 solito ha la forma:
 131 \begin{verbatim}
 132     http://www.sito.it/cgi-bin/programma?parametro
 133 \end{verbatim}
 134 ed il risultato dell'elaborazione deve essere presentato (con una intestazione
 135 che ne descrive il mime-type) sullo standard output, in modo che il web-server
 136 possa reinviarlo al browser che ha effettuato la richiesta, che in questo modo
 137 è in grado di visualizzarlo opportunamente.
 138
 139 Per fare questo useremo in sequenza i programmi \cmd{barcode} e \cmd{gs}, il
 140 primo infatti è in grado di generare immagini postscript di codici a barre
 141 corrispondenti ad una qualunque stringa, mentre il secondo serve per poter
 142 effettuare la conversione della stessa immagine in formato JPEG. Usando una
 143 pipe potremo inviare l'output del primo sull'input del secondo, secondo lo
 144 schema mostrato in \figref{fig:ipc_pipe_use}, in cui la direzione del flusso
 145 dei dati è data dalle frecce continue.
 146
 147 \begin{figure}[htb]
 148   \centering
 149   \includegraphics[height=5cm]{img/pipeuse}
 150   \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
 151     due processi attraverso attraverso l'esecuzione una \func{fork} e la
 152     chiusura dei capi non utilizzati.}
 153   \label{fig:ipc_pipe_use}
 154 \end{figure}
 155
 156 Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
 157 intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
 158 \textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
 159 evidente race condition in caso di accesso simultaneo a detto
 160 file.\footnote{il problema potrebbe essere superato determinando in anticipo
 161   un nome appropiato per il file temporaneo, che verrebbe utilizzato dai vari
 162   sotto-processi, e cancellato alla fine della loro esecuzione; ma a questo le
 163   cose non sarebbero più tanto semplici.}  L'uso di una pipe invece permette
 164 di risolvere il problema in maniera semplice ed elegante.
 165
 166 Il programma ci servirà anche come esempio dell'uso delle funzioni di
 167 duplicazione dei file descriptor che abbiamo trattato in
 168 \secref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
 169 funzioni infatti che è possibile dirottare gli stream standard dei processi
 170 (che abbiamo visto in \secref{sec:file_std_descr} e
 171 \secref{sec:file_std_stream}) sulla pipe. In \figref{fig:ipc_barcodepage_code}
 172 abbiamo riportato il corpo del programma, il cui codice completo è disponibile
 173 nel file \file{BarCodePage.c} che si trova nella directory dei sorgenti.
 174
 175
 176 \begin{figure}[!htb]
 177   \footnotesize \centering
 178   \begin{minipage}[c]{15cm}
 179     \begin{lstlisting}{}
 180 int main(int argc, char *argv[], char *envp[])
 181 {
 182     ...
 183     /* create two pipes to handle process communication */
 184     if ( (retval = pipe(pipein)) ) {
 185         WriteMess("input pipe creation error");
 186         exit(0);
 187     }
 188     if ( (retval = pipe(pipeout)) ) {
 189         WriteMess("output pipe creation error");
 190         exit(0);
 191     }
 192     /* First fork: use child to run barcode program */
 193     if ( (pid = fork()) == -1) {          /* on error exit */
 194         WriteMess("child creation error");
 195         exit(0);
 196     }
 197     /* if child */
 198     if (pid == 0) {
 199         close(pipein[1]);                /* close pipe write end  */
 200         dup2(pipein[0], STDIN_FILENO);   /* remap stdin to pipe read end */
 201         close(pipeout[0]);
 202         dup2(pipeout[1], STDOUT_FILENO); /* remap stdout in pipe output */
 203         execlp("barcode", "barcode", size, NULL); //"-o", "-",  NULL);
 204     }
 205     close(pipein[0]);                    /* close input side of input pipe */
 206     write(pipein[1], argv[1], strlen(argv[1]));  /* write parameter to pipe */
 207     close(pipein[1]);                    /* closing write end */
 208     waitpid(pid, NULL, 0);               /* wait child completion */
 209     /* Second fork: use child to run ghostscript */
 210     if ( (pid = fork()) == -1) {          /* on error exit */
 211         WriteMess("child creation error");
 212         exit(0);
 213     }
 214     /* second child, convert PS to JPEG  */
 215     if (pid == 0) {
 216         close(pipeout[1]);              /* close write end */
 217         dup2(pipeout[0], STDIN_FILENO); /* remap read end to stdin */
 218         /* send mime type */
 219         write(STDOUT_FILENO, content, strlen(content));
 220         execlp("gs", "gs", "-q", "-sDEVICE=jpeg", "-sOutputFile=-", "-", NULL);
 221     }
 222     /* still parent */
 223     close(pipeout[1]);
 224     waitpid(pid, NULL, 0);
 225     exit(0);
 226 }
 227     \end{lstlisting}
 228   \end{minipage}
 229   \normalsize
 230   \caption{Sezione principale del codice del \textit{CGI}
 231     \file{BarCodePage.c}.}
 232   \label{fig:ipc_barcodepage_code}
 233 \end{figure}
 234
 235 La prima operazione del programma (\texttt{\small 4--12}) è quella di creare
 236 le due pipe che serviranno per la comunicazione fra i due comandi utilizzati
 237 per produrre il codice a barre; si ha cura di controllare la riuscita della
 238 chiamata, inviando in caso di errore un messaggio invece dell'immagine
 239 richiesta.\footnote{la funzione \func{WriteMess}, non è riportata in
 240   \secref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
 241   formattare l'uscita alla maniera dei CGI, aggiungendo l'opportuno
 242   \textit{mime type}, e formattando il messaggio in HTML, in modo che
 243   quest'ultimo possa essere visualizzato correttamente da un browser.}
 244
 245 Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
 246 primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
 247 \cmd{barcode}. Quest'ultimo legge dallo standard input una stringa di
 248 caratteri, la converte nell'immagine postscript del codice a barre ad essa
 249 corrispondente, e poi scrive il risultato direttamente sullo standard output.
 250
 251 Per poter utilizzare queste caratteristiche prima di eseguire \cmd{barcode} si
 252 chiude (\texttt{\small 20}) il capo aperto in scrittura della prima pipe, e se
 253 ne collega (\texttt{\small 21}) il capo in lettura allo standard input, usando
 254 \func{dup2}. Si ricordi che invocando \func{dup2} il secondo file, qualora
 255 risulti aperto, viene, come nel caso corrente, chiuso prima di effettuare la
 256 duplicazione. Allo stesso modo, dato che \cmd{barcode} scrive l'immagine
 257 postscript del codice a barre sullo standard output, per poter effettuare una
 258 ulteriore redirezione il capo in lettura della seconda pipe viene chiuso
 259 (\texttt{\small 22}) mentre il capo in scrittura viene collegato allo standard
 260 output (\texttt{\small 23}).
 261
 262 In questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} (cui si
 263 passa in \var{size} la dimensione della pagina per l'immagine) quest'ultimo
 264 leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
 265 padre, e scriverà l'immagine postscript del codice a barre sulla seconda.
 266
 267 Al contempo una volta lanciato il primo figlio, il processo padre prima chiude
 268 (\texttt{\small 26}) il capo inutilizzato della prima pipe (quello in input) e
 269 poi scrive (\texttt{\small 27}) la stringa da convertire sul capo in output,
 270 così che \cmd{barcode} possa riceverla dallo standard input. A questo punto
 271 l'uso della prima pipe da parte del padre è finito ed essa può essere
 272 definitivamente chiusa (\texttt{\small 28}), si attende poi (\texttt{\small
 273   29}) che l'esecuzione di \cmd{barcode} sia completata.
 274
 275 Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
 276 postscript del codice a barre sul capo in scrittura della seconda pipe; a
 277 questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
 278 programma \cmd{gs}. Per questo si crea (\texttt{\small 30--34}) un secondo
 279 processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
 280 leggendo l'immagine postscript creata da \cmd{barcode} dallo standard input,
 281 per convertirla in JPEG.
 282
 283 Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
 284 scrittura della seconda pipe, e se ne collega (\texttt{\small 38}) il capo in
 285 lettura allo standard input. Per poter formattare l'output del programma in
 286 maniera utilizzabile da un browser, si provvede anche \texttt{\small 40}) alla
 287 scrittura dell'apposita stringa di identificazione del mime-type in testa allo
 288 standard output. A questo punto si può invocare \texttt{\small 41}) \cmd{gs},
 289 provvedendo gli appositi switch che consentono di leggere il file da
 290 convertire dallo standard input e di inviare la conversione sullo standard
 291 output.
 292
 293 Per completare le operazioni il processo padre chiude (\texttt{\small 44}) il
 294 capo in scrittura della seconda pipe, e attende la conclusione del figlio
 295 (\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
 296 conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
 297 necessaria, infatti, se non venisse chiusa, \cmd{gs}, che legge il suo
 298 stardard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati
 299 in ingresso (l'unico modo che un programma ha per sapere che l'input è
 300 terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
 301 non ritornerebbe.
 302
 303
 304 \subsection{Le funzioni \func{popen} e \func{pclose}}
 305 \label{sec:ipc_popen}
 306
 307 Come si è visto la modalità più comune di utilizzo di una pipe è quella di
 308 utilizzarla per fare da tramite fra output ed input di due programmi invocati
 309 in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
 310 che permettono di sintetizzare queste operazioni. La prima di esse si chiama
 311 \func{popen} ed il suo prototipo è:
 312 \begin{prototype}{stdio.h}
 313 {FILE *popen(const char *command, const char *type)}
 314
 315 Esegue il programma \param{command}, di cui, a seconda di \param{type},
 316 restituisce, lo standard input o lo standard output nella pipe collegata allo
 317 stream restituito come valore di ritorno.
 318
 319 \bodydesc{La funzione restituisce l'indirizzo dello stream associato alla pipe
 320   in caso di successo e \macro{NULL} per un errore, nel qual caso \var{errno}
 321   potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
 322   e \func{fork} o \macro{EINVAL} se \param{type} non è valido.}
 323 \end{prototype}
 324
 325 La funzione crea una pipe, esegue una \func{fork}, ed invoca il programma
 326 \param{command} attraverso la shell (in sostanza esegue \file{/bin/sh} con il
 327 flag \code{-c}); l'argomento \param{type} deve essere una delle due stringhe
 328 \verb|"w"| o \verb|"r"|, per indicare se la pipe sarà collegata allo standard
 329 input o allo standard output del comando invocato.
 330
 331 La funzione restituisce il puntatore allo stream associato alla pipe creata,
 332 che sarà aperto in sola lettura (e quindi associato allo standard output del
 333 programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
 334 quindi associato allo standard input) in caso di \code{"w"}.
 335
 336 Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
 337 stream visti in \secref{cha:files_std_interface}, anche se è collegato ad una
 338 pipe e non ad un inode, e viene sempre aperto in modalità
 339 \textit{fully-buffered} (vedi \secref{sec:file_buffering}); l'unica differenza
 340 con gli usuali stream è che dovrà essere chiuso dalla seconda delle due nuove
 341 funzioni, \func{pclose}, il cui prototipo è:
 342 \begin{prototype}{stdio.h}
 343 {int pclose(FILE *stream)}
 344
 345 Chiude il file \param{stream}, restituito da una prededente \func{popen}
 346 attendendo la terminazione del processo ad essa associato.
 347
 348 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
 349   errore; nel quel caso il valore di \func{errno} deriva dalle sottostanti
 350   chiamate.}
 351 \end{prototype}
 352 \noindent che oltre alla chiusura dello stream si incarica anche di attendere
 353 (tramite \func{wait4}) la conclusione del processo creato dalla precedente
 354 \func{popen}.
 355
 356 Per illustrare l'uso di queste due funzioni riprendiamo il problema
 357 precedente: il programma mostrato in \figref{fig:ipc_barcodepage_code} per
 358 quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
 359 inoltre nella pratica sconta un problema di \cmd{gs} che non è in
 360 grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
 361 riconoscere correttamente l'encapsulated postscript, per cui deve essere usato
 362 il postscript e tutte le volte viene generata una pagina intera, invece che
 363 una immagine delle dimensioni corrispondenti al codice a barre.
 364
 365 Se si vuole generare una immagine di dimensioni appropriate si deve usare un
 366 approccio diverso. Una possibilità sarebbe quella di ricorrere ad ulteriore
 367 programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
 368 generato da \cmd{barcode} utilizzando lo switch \cmd{-E}).  Utilizzando un PDF
 369 al posto di un EPS \cmd{gs} esegue la conversione rispettando le dimensioni
 370 originarie del codice a barre e produce un JPEG delle dimensioni adeguate.
 371
 372 Questo però ci porta a scontrarci con una caratteristica peculiare delle pipe,
 373 che a prima vista non è evidente. Per poter effettuare la conversione di un
 374 PDF infatti è necessario, per la struttura del formato, dover eseguire delle
 375 \func{lseek} sul file da convertire; se si esegue \cmd{gs} su un file normale
 376 non ci sono problemi, ma una pipe però è rigidamente sequenziale, ed il
 377 tentativo di eseguire detta operazione su una pipe comporta l'immediato
 378 fallimento con un errore di \macro{ESPIPE}.  Questo ci dice che in generale la
 379 concatenazione di vari programmi funzionerà soltanto quando tutti prevedono
 380 una lettura sequenziale del loro input.
 381
 382 Per questo motivo si è dovuto utilizzare una strada diversa, che prevede la
 383 conversione attraverso \cmd{gs} del PS in un altro formato intermedio, il
 384 PPM,\footnote{il \textit{Portable PixMap file format} è un formato usato
 385   spesso come formato intermedio per effettuare conversioni, è estremamente
 386   inefficiente, ma molto facile da manipolare dato che usa caratteri ASCII per
 387   memorizzare le immagini.} dal quale poi si può ottenere un'immagine di
 388 dimensioni corrette attraverso vari programmi di manipolazione (\cmd{pnmcrop},
 389 \cmd{pnmmargin}) che può essere infine trasformata in PNG (con \cmd{pnm2png}).
 390
 391 In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
 392 inviando l'output di ciascuno all'input del successivo, per poi ottenere il
 393 risultato finale sullo standard output: un caso classico di utilizzazione
 394 delle pipe, in cui l'uso di \func{popen} e \func{pclose} permette di
 395 semplificare notevolmente la stesura del codice.
 396
 397 Nel nostro caso, dato che ciascun processo deve scrivere il suo output sullo
 398 standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
 399 scrittura. Il codice del nuovo programma è riportato in
 400 \figref{fig:ipc_barcode_code}.  Come si può notare l'ordine di invocazione dei
 401 programmi è l'inverso di quello in cui ci si aspetta che vengano
 402 effettivamente eseguiti. Questo non comporta nessun problema dato che la
 403 lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
 404 per primo, si bloccherà in attesa di ricevere sullo standard input il
 405 risultato dell'elaborazione del precendente, benchè quest'ultimo venga
 406 invocato dopo.
 407
 408 \begin{figure}[!htb]
 409   \footnotesize \centering
 410   \begin{minipage}[c]{15cm}
 411     \begin{lstlisting}{}
 412 int main(int argc, char *argv[], char *envp[])
 413 {
 414     FILE *pipe[4];
 415     FILE *pipein;
 416     char *cmd_string[4]={
 417         "pnmtopng",
 418         "pnmmargin -white 10",
 419         "pnmcrop",
 420         "gs -sDEVICE=ppmraw -sOutputFile=- -sNOPAUSE -q - -c showpage -c quit"
 421     };
 422     char content[]="Content-type: image/png\n\n";
 423     int i;
 424     /* write mime-type to stout */
 425     write(STDOUT_FILENO, content, strlen(content));
 426     /* execute chain of command */
 427     for (i=0; i<4; i++) {
 428         pipe[i] = popen(cmd_string[i], "w");
 429         dup2(fileno(pipe[i]), STDOUT_FILENO);
 430     }
 431     /* create barcode (in PS) */
 432     pipein = popen("barcode", "w");
 433     /* send barcode string to barcode program */
 434     write(fileno(pipein), argv[1], strlen(argv[1]));
 435     /* close all pipes (in reverse order) */
 436     for (i=4; i==0; i--) {
 437         pclose((pipe[i]));
 438     }
 439     exit(0);
 440 }
 441     \end{lstlisting}
 442   \end{minipage}
 443   \normalsize
 444   \caption{Codice completo del \textit{CGI} \file{BarCode.c}.}
 445   \label{fig:ipc_barcode_code}
 446 \end{figure}
 447
 448 Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il mime-type
 449 sullo standard output; a questo punto il processo padre non necessita più di
 450 eseguire ulteriori operazioni sullo standard output e può tranquillamente
 451 provvedere alla redirezione.
 452
 453 Dato che i vari programmi devono essere lanciati in successione, si è
 454 approntato un ciclo (\texttt{\small 15--19}) che esegue le operazioni in
 455 sequenza: prima crea una pipe (\texttt{\small 17}) per la scrittura eseguendo
 456 il programma con \func{popen}, in modo che essa sia collegata allo standard
 457 input, e poi redirige (\texttt{\small 18}) lo standard output su detta pipe.
 458
 459 In questo modo il primo processo ad essere invocato (che è l'ultimo della
 460 catena) scriverà ancora sullo standard output del processo padre, ma i
 461 successivi, a causa di questa redirezione, scriveranno sulla pipe associata
 462 allo standard input del processo invocato nel ciclo precedente.
 463
 464 Alla fine tutto quello che resta da fare è lanciare (\texttt{\small 21}) il
 465 primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
 466 (\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
 467 al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
 468 ciclo, che chiuda, nell'ordine inverso rispetto a quello in cui le si sono
 469 create, tutte le pipe create con \func{pclose}.
 470
 471
 472 \subsection{Le \textit{pipe} con nome, o \textit{fifo}}
 473 \label{sec:ipc_named_pipe}
 474
 475 Come accennato in \secref{sec:ipc_pipes} il problema delle \textit{pipe} è che
 476 esse possono essere utilizzate solo da processi con un progenitore comune o
 477 nella relazione padre/figlio; per superare questo problema lo standard POSIX.1
 478 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
 479 caratteristiche delle pipe, ma che invece di essere strutture interne del
 480 kernel, visibili solo attraverso un file descriptor, sono accessibili
 481 attraverso un inode che risiede sul filesystem, così che i processi le possono
 482 usare senza dovere per forza essere in una relazione di \textsl{parentela}.
 483
 484 Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
 485 attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
 486 l'inode allocato sul filesystem serve infatti solo a fornire un punto di
 487 riferimento per i processi, che permetta loro di accedere alla stessa fifo; il
 488 comportamento delle funzioni di lettura e scrittura è identico a quello
 489 illustrato per le pipe in \secref{sec:ipc_pipes}.
 490
 491 Abbiamo già visto in \secref{sec:file_mknod} le funzioni \func{mknod} e
 492 \func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
 493 processo non avrà che da aprire il relativo file speciale o in lettura o
 494 scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
 495 leggere, nel secondo al capo di ingresso, e dovrà scrivere.
 496
 497 Il kernel crea una sigola pipe per ciascuna fifo che sia stata aperta, che può
 498 essere acceduta contemporaneamente da più processi, sia in lettura che in
 499 scrittura. Dato che per funzionare deve essere aperta in entrambe le
 500 direzioni, per una fifo di norma la funzione \func{open} si blocca se viene
 501 eseguita quando l'altro capo non è aperto.
 502
 503 Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
 504 nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
 505 l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
 506 l'errore di \macro{ENXIO} fintanto che non verrà aperto il capo in lettura.
 507
 508 In Linux\footnote{lo standard POSIX lascia indefinito questo comportamento.} è
 509 possibile aprire le fifo anche in lettura/scrittura, operazione che avrà
 510 sempre successo qualunque sia la modalità di apertura (bloccante e non
 511 bloccante); questo può essere utilizzato per aprire comunque una fifo in
 512 scrittura anche se non ci sono ancora processi il lettura; è possibile anche
 513 usare la fifo all'interno di un solo processo, nel qual caso però occorre
 514 stare molto attenti alla possibili deadlock.\footnote{se si cerca di leggere
 515   da una fifo che non contiene dati si avrà un deadlock immediato, dato che il
 516   processo si blocca e non potrà quindi mai eseguire le funzioni di
 517   scrittura.}
 518
 519
 520
 521 \section{La comunicazione fra processi di System V}
 522 \label{sec:ipc_sysv}
 523
 524 Per ovviare ai vari limiti dei meccanismo tradizionale di comunicazione fra
 525 processi visto in \secref{sec:ipc_unix}, nello sviluppo di System V vennero
 526 introdotti una serie di nuovi oggetti e relative interfacce che garantissero
 527 una maggiore flessibilità; in questa sezione esamineremo quello che viene
 528 ormai chiamato il \textit{System V Inter-Process Comunication System}, più
 529 comunemente noto come \textit{SystemV IPC}.
 530
 531
 532 \subsection{Code di messaggi}
 533 \label{sec:ipc_messque}
 534
 535 Il primo oggetto introdotto dal \textit{SystemV IPC} è quello delle code di
 536 messaggi.
 537
 538 \subsection{Semafori}
 539 \label{sec:ipc_semaph}
 540
 541 Il secondo oggetto introdotto dal \textit{SystemV IPC} è quello dei semafori.
 542
 543
 544 \subsection{Memoria condivisa}
 545 \label{sec:ipc_shar_mem}
 546
 547 Il terzo oggetto introdotto dal \textit{SystemV IPC} è quello della memoria
 548 condivisa.
 549
 550 %%% Local Variables:
 551 %%% mode: latex
 552 %%% TeX-master: "gapil"
 553 %%% End: