Sistemata bibliografia, aggiunte ad ioctl e qualcosa in piu` sulle pipe

[gapil.git] / ipc.tex

diff --git a/ipc.tex b/ipc.tex
index bb175495677ccd7c52a83b7db0ac7eac36b3f00e..352a7197b9435ea9ff4217540c72efb3ef18dc47 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -9,7 +9,7 @@ diversi, come quelli tradizionali che coinvolgono \textit{pipe} e
 \textit{fifo} e i meccanismi di intercomunicazione di System V.
 
 Tralasceremo invece tutte le problematiche relative alla comunicazione
 \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
 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


@@ -20,29 +20,33 @@ implementati con un ulteriore livello sopra i meccanismi elementari.
 \section{La comunicazione fra processi tradizionale}
 \label{sec:ipc_unix}
 
 \section{La comunicazione fra processi tradizionale}
 \label{sec:ipc_unix}
 

-Il primo meccanismo di comunicazione fra processi usato dai sistemi unix-like
-è quello delle \textit{pipe}, in questa sezione descriveremo le sue basi, le
-funzioni che ne gestiscono l'uso e le varie forme in cui si è evoluto.
+Il primo meccanismo di comunicazione fra processi usato dai sistemi unix-like,
+e quello che viene correntemente usato di più, è quello delle \textit{pipe},
+che sono una delle caratteristiche peculiari del sistema, in particolar modo
+dell'interfaccia a linea di comando. In questa sezione descriveremo le sue
+basi, le funzioni che ne gestiscono l'uso e le varie forme in cui si è
+evoluto.

 
 
 \subsection{Le \textit{pipe} standard}
 \label{sec:ipc_pipes}
 
 
 
 \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.
-
-
-La funzione che permette di creare una \textit{pipe} è appunto \func{pipe}; il
-suo prototipo è:
+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 è:

 \begin{prototype}{unistd.h}
 {int pipe(int filedes[2])} 
   
 \begin{prototype}{unistd.h}
 {int pipe(int filedes[2])} 
   

-Crea una coppia di file descriptor associati ad una \textit{pipe}.
+Crea una coppia di file descriptor associati ad una pipe.

   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
     errore, nel qual caso \var{errno} potrà assumere i valori \macro{EMFILE},
   
   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
     errore, nel qual caso \var{errno} potrà assumere i valori \macro{EMFILE},


@@ -51,48 +55,94 @@ Crea una coppia di file descriptor associati ad una \textit{pipe}.
 
 La funzione restituisce una coppia di file descriptor nell'array
 \param{filedes}; il primo aperto in lettura ed il secondo in scrittura. Il
 
 La funzione restituisce una coppia di file descriptor nell'array
 \param{filedes}; il primo aperto in lettura ed il secondo in scrittura. Il

-concetto di funzionamento di una \textit{pipe} è relativamente semplice,
-quello che si scrive nel file descriptor aperto in scrittura viene
-ripresentato tale e quale nel file descriptor aperto in lettura, da cui può
-essere riletto.
+concetto di funzionamento di una pipe è relativamente semplice, quello che si
+scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
+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
 
 I file descriptor infatti non sono connessi a nessun file reale, ma ad un

-buffer nel kernel (la cui dimensione è specificata dalla costante
-\macro{PIPE\_BUF}, vedi \secref{sec:sys_file_limits}), di modo che scrivendo
-in uno si può rileggere dall'altro.
+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
+  \includegraphics[height=5cm]{img/pipe}
+  \caption{Schema della struttura di una pipe.}
+  \label{fig:ipc_pipe_singular}
+\end{figure}

 
 Chiaramente creare una pipe all'interno di un processo non serve a niente; se
 però ricordiamo quanto esposto in \secref{sec:file_sharing} riguardo al
 comportamento dei file descriptor nei processi figli, è immediato capire come
 una pipe possa diventare un meccanismo di intercomunicazione. Un processo
 figlio infatti condivide gli stessi file descriptor del padre, compresi quelli
 
 Chiaramente creare una pipe all'interno di un processo non serve a niente; se
 però ricordiamo quanto esposto in \secref{sec:file_sharing} riguardo al
 comportamento dei file descriptor nei processi figli, è immediato capire come
 una pipe possa diventare un meccanismo di intercomunicazione. Un processo
 figlio infatti condivide gli stessi file descriptor del padre, compresi quelli

-associati ad una pipe; in questo modo se uno dei processi scrive su un capo
-della pipe, l'altro può leggere. 
-
-Tutto ciò ci mosta come sia immediato realizzare un meccanismo di
-comunicazione fra processi attraverso una pipe utilizzando le ordinarie
+associati ad una pipe (secondo la situazione illustrata in
+\figref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
+capo della pipe, l'altro può leggere.
+
+\begin{figure}[htb]
+  \centering
+  \includegraphics[height=5cm]{img/pipefork}
+  \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
+  processo attraverso una \func{fork}.}
+  \label{fig:ipc_pipe_fork}
+\end{figure}
+
+Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
+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 è
 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
-  una coppia di \textit{pipe}.} limite nell'uso delle \textit{pipe}. È
-necessario infatti che i processi possano condividere i file descriptor della
-\textit{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.
+  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
+è 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}
 
 
 
 
 \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.