+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 è:
+\begin{prototype}{unistd.h}
+{int pipe(int filedes[2])}
+
+Crea una coppia di file descriptor associati ad una \textit{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},
+ \macro{ENFILE} e \macro{EFAULT}.}
+\end{prototype}
+
+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.
+
+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.
+
+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
+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.
+
+
+
+