\textit{fifo} e i meccanismi di intercomunicazione di System V.
Tralasceremo invece tutte le problematiche relative alla comunicazione
-attraverso la rete (e le relative interfacce) che saranno affrontate in gran
+attraverso la rete (e le relative interfacce) che saranno affrontate in
dettaglio in un secondo tempo. Non affronteremo invece meccanismi più
complessi ed evoluti come le RPC (\textit{Remote Procedure Calls}) e CORBA
(\textit{Common Object Request Brocker Architecture}) che in genere sono
\subsection{Le \textit{pipe} standard}
\label{sec:ipc_pipes}
-Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, ed uno dei
-più usati, meccanismi di comunicazione fra processi. Si tratta in sostanza uno
-speciale tipo di file\footnote{più precisamente un file descriptor; le pipe
- sono create dal kernel e non risiedono su disco.} in cui un processo scrive
-ed un altro legge. Si viene così a costituire un canale di comunicazione fra i
-due processi, nella forma di un \textsl{tubo} (da cui il nome) in cui uno dei
-processi immette dati che poi arriveranno all'altro.
-
+Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, e tuttora
+uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
+sostanza di uno speciale tipo di file descriptor, più precisamente una coppia
+di file descriptor,\footnote{si tenga presente che le pipe sono oggetti creati
+ dal kernel e non risiedono su disco.} su cui da una parte si scrive e da
+un'altra si legge. Si viene così a costituire un canale di comunicazione
+tramite i due file descriptor, nella forma di un \textsl{tubo} (da cui il
+nome) in cui in genere un processo immette dati che poi arriveranno ad un
+altro.
La funzione che permette di creare una pipe è appunto \func{pipe}; il suo
prototipo è:
nel file descriptor aperto in lettura, da cui può essere riletto.
I file descriptor infatti non sono connessi a nessun file reale, ma ad un
-buffer nel kernel (la cui dimensione, vedi \secref{sec:sys_file_limits}, è
-specificata dalla costante \macro{PIPE\_BUF} illustrata in
-\figref{fig:ipc_pipe_singular}, in cui sono illustrati i due capi della pipe,
-associati a ciascun file descriptor, con le frecce che indicano la direzione
-del flusso dei dati attaverso la pipe.
+buffer nel kernel, la cui dimensione è specificata dalla costante
+\macro{PIPE\_BUF}, (vedi \secref{sec:sys_file_limits}); lo schema di
+funzionamento di una pipe è illustrato in \figref{fig:ipc_pipe_singular}, in
+cui sono illustrati i due capi della pipe, associati a ciascun file
+descriptor, con le frecce che indicano la direzione del flusso dei dati
+attaverso la pipe.
\begin{figure}[htb]
\centering
comunicazione fra processi attraverso una pipe, utilizzando le ordinarie
proprietà dei file, ma ci mostra anche qual'è il principale\footnote{Stevens
riporta in APUE come limite anche il fatto che la comunicazione è
- unidirezionale, in realtà questo è un limite facilemente risolvibile usando
+ unidirezionale, in realtà questo è un limite facilmente risolvibile usando
una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
processi possano condividere i file descriptor della pipe, e per questo essi
devono comunque derivare da uno stesso processo padre che ha aperto la pipe,
o, più comunemente, essere nella relazione padre/figlio.
+
+
+\subsection{Un esempio dell'uso delle pipe}
+\label{sec:ipc_pipe_use}
+
Per capire meglio il funzionamento di una pipe faremo un esempio di quello che
-è l'uso più comune, di una pipe, quello fatto dalla shell, che permette di
-inviare automaticamente l'output (usando lo standard output) di un programma
-sull'input di un'altro.
+è il loro uso più comune, analogo a quello effettuato della shell, e che
+consiste nell'inviare l'output di un processo (lo standard output) sull'input
+di un'altro. Realizzaremo il programma nella forma di un
+\textit{cgi-bin}\footnote{breve descrizione, da fare, di cosa è un cgi-bin.}
+per apache, che genera una immagine JPEG di un codice a barre, specificato
+come parametro di input.
+
+Per fare questo useremo i programmi \cmd{barcode} e \cmd{gs}, il primo infatti
+è in grado di generare immagini postscript di codici a barre corrispondenti ad
+una qualunque stringa, data come parametro, mentre il secondo è in grado di
+convertire un file postscript in una immagine JPEG. Usando l'ouptut del primo
+come input del secondo attraverso una pipe potremo generare immagini JPEG del
+codice a barre di una stringa qualunque.
+
+Si potrebbe obiettare che sarebbe molto più semplice ottenere lo stesso
+risultato salvando il tutto in un file temporaneo, ma si dovrebbe comunque
+risolvere il problema di come comunicare il nome di questo file da un processo
+all'altro, dato che utilizzare lo stesso file porterebbe ad inevitabili
+sovrascritture nell'accavallarsi di diversi processi. L'uso di una pipe
+permette di risolvere il problema in maniera semplice ed elegante.
+
+Il programma ci servirà anche come esempio dell'uso di alcune delle funzioni
+di manipolazione dei file descriptor, come \func{dup} e \func{dup2}, viste in
+\secref{sec:file_dup}
\subsection{Le \textit{pipe} con nome, o \textit{fifo}}
\label{sec:ipc_named_pipe}
-Per poter superare il problema delle \textit{pipe} originali, che consentono
-la comunicazione solo fra processi correlati, passando attraverso strutture
-interne del kernel, sono stati introdotti dei nuovi oggetti, le \textit{fifo},
-che invece possono risiedere sul filesystem, e che i processi possono usare
-per le comunicazioni senza dovere per forza essere in relazione diretta.
+Per poter superare il problema delle \textit{pipe}, illustrato in
+\secref{sec:ipc_pipes}, che ne consente l'uso solo fra procesi con un
+progenitore comune o nella relazione padre/figlio, lo standard POSIX.1
+definisce dei nuovi oggetti, le \textit{fifo}, che invece possono risiedere
+sul filesystem, e che i processi possono usare per le comunicazioni senza
+dovere per forza essere in relazione diretta.
+
+
\section{La comunicazione fra processi di System V}
projects / gapil.git / blobdiff