X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=b8c703a773d7bb2524c5862c48daa1280215ef6d;hp=bb175495677ccd7c52a83b7db0ac7eac36b3f00e;hb=21f7d0f48d68450dd105427b89df37b765616033;hpb=a0fdff527cf9690c0d16c48182bda2865b79f501 diff --git a/ipc.tex b/ipc.tex index bb17549..b8c703a 100644 --- 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 -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 @@ -20,9 +20,12 @@ implementati con un ulteriore livello sopra i meccanismi elementari. \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} @@ -37,12 +40,12 @@ 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 è: +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 \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}, @@ -51,48 +54,68 @@ 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 -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 -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 -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 è 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. - - + 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} 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.