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