X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=352a7197b9435ea9ff4217540c72efb3ef18dc47;hp=6c1041ef5271eadb33f5027e1b0fd98d9080868d;hb=30a6a42996cb5bf0d7c0b2b607743893dc964cdd;hpb=525464ecdd7e6cbdccc733e73b5f1cc9dbe6022a diff --git a/ipc.tex b/ipc.tex index 6c1041e..352a719 100644 --- a/ipc.tex +++ b/ipc.tex @@ -3,72 +3,166 @@ Uno degli aspetti fondamentali della programmazione in un sistema unix-like è -la comunicazione fra processi. In questo capitolo affronteremo solo alcuni dei +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. -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. Inoltre tratteremo nei -capitoli successivi tutta la problematica relativa alla comunicazione -attraverso la rete. +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. \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, e più -comunemente usato, meccanismo di comunicazione fra processi. Esse sono un file -speciale 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 immette dati che arriveranno -all'altro. - -Perché questo accada però, e questo è il principale limite nell'uso delle -\textit{pipe}, è necessario che questi processi possano condividere il file -descriptor della \textit{pipe}; per questo essi devono comunque derivare da -uno stesso processo padre, o, più comunemente, essere nella relazione -padre/figlio. +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])} + +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 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} -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} \label{sec:ipc_sysv} Per ovviare ai 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 -\textit{System V Inter Process Comunication system}, più comunemente noto come -\textit{SystemV IPC}. +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. +messaggi. \subsection{Semafori} \label{sec:ipc_semaph}