X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=b8c703a773d7bb2524c5862c48daa1280215ef6d;hp=f86a851e9fb41c5b43913f428d8e80354758fd15;hb=21f7d0f48d68450dd105427b89df37b765616033;hpb=fd934ebcf645120b9c92a434ab6b8755c04a3c07

diff --git a/ipc.tex b/ipc.tex
index f86a851..b8c703a 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -2,57 +2,152 @@
 \label{cha:IPC}
 
 
-\section{Introduzione}
-\label{sec:ipc_intro}
+Uno degli aspetti fondamentali della programmazione in un sistema unix-like è
+la comunicazione fra processi. In questo capitolo affronteremo solo i
+meccanismi più elementari che permettono di mettere in comunicazione processi
+diversi, come quelli tradizionali che coinvolgono \textit{pipe} e
+\textit{fifo} e i meccanismi di intercomunicazione di System V.
 
-Uno degli aspetti fondamentali della programmazione in unix è la comunicazione
-fra processi. In questo capitolo affronteremo solo alcuni dei meccanismi più
-elementari che permettono di mettere in comunicazione processi 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
+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
+implementati con un ulteriore livello sopra i meccanismi elementari.
 
-Esistono pure sistemi più complessi ed evoluti come le RPC (\textit{Remote
-  Procedure Calls}) e CORBA (\textit{Common Object Request Brocker
-  Architecture}) che non saranno affrontati qui.
 
 
 \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}
 
+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 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 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 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}); 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
+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 è
+  unidirezionale, in realtà questo è un limite facilemente 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.
+
+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 (usando lo standard output)
+sull'input di un'altro.
+
 
 
 \subsection{Le \textit{pipe} con nome, o \textit{fifo}}
 \label{sec:ipc_named_pipe}
 
+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}
 \label{sec:ipc_sysv}
 
-Per ovviare ad i vari limiti dei meccanismo tradizionale di comunicazione fra
-processi basato sulle \textit{pipe}, nello sviluppo di System V vennero
-introdotti una serie di nuovi oggetti che garantissero una maggiore
-flessibilità; in questa sezione esamineremo quello che viene ormai chiamato il
-sistema \textit{SystemV IPC}.
+Per ovviare ai vari limiti dei meccanismo tradizionale di comunicazione fra
+processi visto in \secref{sec:ipc_unix}, nello sviluppo di System V vennero
+introdotti una serie di nuovi oggetti e relative interdacce che garantissero
+una maggiore flessibilità; in questa sezione esamineremo quello che viene
+ormai chiamato il \textit{System V Inter-Process Comunication System}, più
+comunemente noto come \textit{SystemV IPC}.
+ 
 
 \subsection{Code di messaggi}
 \label{sec:ipc_messque}
 
+Il primo oggetto introdotto dal \textit{SystemV IPC} è quello delle code di
+messaggi.
+
 \subsection{Semafori}
 \label{sec:ipc_semaph}
 
+Il secondo oggetto introdotto dal \textit{SystemV IPC} è quello dei semafori.
+
+
 \subsection{Memoria condivisa}
 \label{sec:ipc_shar_mem}
 
+Il terzo oggetto introdotto dal \textit{SystemV IPC} è quello della memoria
+condivisa.
 
 %%% Local Variables: 
 %%% mode: latex