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.
+\textit{fifo} e i meccanismi di intercomunicazione di System V e quelli POSIX.
Tralasceremo invece tutte le problematiche relative alla comunicazione
attraverso la rete (e le relative interfacce) che saranno affrontate in
restituirà un errore di \macro{EPIPE} (al ritorno del manipolatore, o qualora
il segnale sia ignorato o bloccato).
+La dimensione del buffer della pipe (\macro{PIPE\_BUF}) ci dà inoltre un'altra
+importante informazione riguardo il comportamento delle operazioni di lettura
+e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
+quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
+si effettui una scrittura di una quantità di dati superiore l'operazione verrà
+effettuata in più riprese, consentendo l'intromissione di scritture effettuate
+da altri processi.
\subsection{Un esempio dell'uso delle pipe}
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
+di un'altro. Realizzeremo il programma nella forma di un
\textit{CGI}\footnote{Un CGI (\textit{Common Gateway Interface}) è un programma
che permette la creazione dinamica di un oggetto da inserire all'interno di
una pagina HTML.} per apache, che genera una immagine JPEG di un codice a
\textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
evidente race condition in caso di accesso simultaneo a detto
file.\footnote{il problema potrebbe essere superato determinando in anticipo
- un nome appropiato per il file temporaneo, che verrebbe utilizzato dai vari
+ un nome appropriato per il file temporaneo, che verrebbe utilizzato dai vari
sotto-processi, e cancellato alla fine della loro esecuzione; ma a questo le
cose non sarebbero più tanto semplici.} L'uso di una pipe invece permette
-di risolvere il problema in maniera semplice ed elegante.
+di risolvere il problema in maniera semplice ed elegante, oltre ad essere
+molto più efficiente, dato che non si deve scrivere su disco.
Il programma ci servirà anche come esempio dell'uso delle funzioni di
duplicazione dei file descriptor che abbiamo trattato in
(\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
necessaria, infatti, se non venisse chiusa, \cmd{gs}, che legge il suo
-stardard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati
+standard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati
in ingresso (l'unico modo che un programma ha per sapere che l'input è
terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
non ritornerebbe.
\begin{prototype}{stdio.h}
{int pclose(FILE *stream)}
-Chiude il file \param{stream}, restituito da una prededente \func{popen}
+Chiude il file \param{stream}, restituito da una precedente \func{popen}
attendendo la terminazione del processo ad essa associato.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
effettivamente eseguiti. Questo non comporta nessun problema dato che la
lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
per primo, si bloccherà in attesa di ricevere sullo standard input il
-risultato dell'elaborazione del precendente, benchè quest'ultimo venga
+risultato dell'elaborazione del precedente, benchè quest'ultimo venga
invocato dopo.
\begin{figure}[!htb]
scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
leggere, nel secondo al capo di ingresso, e dovrà scrivere.
-Il kernel crea una sigola pipe per ciascuna fifo che sia stata aperta, che può
+Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
essere acceduta contemporaneamente da più processi, sia in lettura che in
scrittura. Dato che per funzionare deve essere aperta in entrambe le
direzioni, per una fifo di norma la funzione \func{open} si blocca se viene
In Linux\footnote{lo standard POSIX lascia indefinito questo comportamento.} è
possibile aprire le fifo anche in lettura/scrittura, operazione che avrà
-sempre successo qualunque sia la modalità di apertura (bloccante e non
-bloccante); questo può essere utilizzato per aprire comunque una fifo in
+sempre successo immediato qualunque sia la modalità di apertura (bloccante e
+non bloccante); questo può essere utilizzato per aprire comunque una fifo in
scrittura anche se non ci sono ancora processi il lettura; è possibile anche
usare la fifo all'interno di un solo processo, nel qual caso però occorre
stare molto attenti alla possibili deadlock.\footnote{se si cerca di leggere
processo si blocca e non potrà quindi mai eseguire le funzioni di
scrittura.}
-
+Per la loro caratteristica di essere accessibili attraverso il filesystem, è
+piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
+situazioni un processo deve ricevere informazioni dagli altri. In questo caso
+è fondamentale che le operazioni di scrittura siano atomiche; per questo si
+deve sempre tenere presente che questo è vero soltanto fintanto che non si
+supera il limite delle dimensioni di \macro{PIPE\_BUF} (si ricordi quanto
+detto in \secref{sec:ipc_pipes}).
+
+A parte il precedente, che resta probabilmente il più comune, Stevens riporta
+in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
+\begin{itemize}
+\item Da parte dei comandi di shell, per evitare la creazione di file
+ temporanei quando si devono inviare i dati di uscita di un processo
+ sull'input di parecchi altri (attraverso l'uso del comando \cmd{tee}).
+\item Come canale di comunicazione fra un client ed un server (il modello
+ \textit{client-server} è illustrato in \secref{sec:net_cliserv}).
+\end{itemize}
+
+Nel primo caso quello che si fa è creare tante pipe quanti sono i processi a
+cui i vogliono inviare i dati, da usare come standard input per gli stessi; una
+volta che li si saranno posti in esecuzione ridirigendo lo standard input si
+potrà eseguire il processo iniziale replicandone, con il comando \cmd{tee},
+l'output sulle pipe.
+
+Il secondo caso è relativamente semplice qualora si debba comunicare con un
+processo alla volta (nel qual caso basta usare due pipe, una per leggere ed
+una per scrivere), le cose diventano invece molto più complesse quando si
+vuole effettuare una comunicazione fra il server ed un numero imprecisato di
+client; se il primo infatti può ricevere le richieste attraverso una fifo
+``nota'', per le risposte non si può fare altrettanto, dato che per la
+struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
+leggerli, quando i dati inviati sono destinati a loro.
+
+Per risolvere questo problema, si può usare un'architettura come quella
+illustrata da Stevens in \cite{APUE}, in cui le risposte vengono inviate su
+fifo temporanee identificate dal \acr{pid} dei client, ma in ogni caso il
+sistema è macchinoso e continua ad avere vari inconvenienti\footnote{lo stesso
+ Stevens nota come sia impossibile per il server sapere se un client è andato
+ in crash, con la possibilità di far restare le fifo temporanee sul
+ filesystem, come sia necessario intercettare \macro{SIGPIPE} dato che un
+ client può terminare dopo aver fatto una richiesta, ma prima che la risposta
+ sia inviata, e come occorra gestire il caso in cui non ci sono client attivi
+ (e la lettura dalla fifo nota restituisca al serve un end-of-file.}; in
+generale infatti l'interfaccia delle fifo non è adatta a risolvere questo tipo
+di problemi, che possono essere affrontati in maniera più semplice ed efficace
+o usando i \textit{socket}\index{socket} (che tratteremo in dettaglio a
+partire da \capref{cha:socket_intro}) o ricorrendo a diversi meccanismi di
+comunicazione, come quelli che esamineremo in \secref{sec:ipc_sysv}.
+
+
+
\section{La comunicazione fra processi di System V}
\label{sec:ipc_sysv}
-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 interfacce 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}.
+Benché le pipe (e le fifo) siano ancora ampiamente usate, esse presentano
+numerosi limiti, il principale dei quali è che il meccanismo di comunicazione
+è rigidamente sequenziale; per cui una situazione in cui un processo scrive
+qualcosa che molti altri devono poter leggere non può essere implementata in
+maniera semplice con una pipe.
+
+Per superarne questi limiti nello sviluppo di System V vennero introdotti una
+serie di nuovi oggetti di comunicazione e relative interfacce di
+programmazione che garantissero una maggiore flessibilità; in questa sezione
+esamineremo quello che viene ormai chiamato il \textsl{Sistema di
+ comunicazione inter-processo} di System V , più comunemente noto come
+\textit{System V IPC (Inter-Process Comunication)}.
+
+
+
+\subsection{Chiavi ed identificatori}
+\label{sec:ipc_keyid}
+
+La principale caratteristica, ed uno dei maggiori difetti, del sistema di IPC
+di System V è che è basato su oggetti che risiedono permanentemente nel
+kernel, a questi si accede attraverso un identificatore. Il problema è che
+
+
+a cui di deve accedere attraverso un identificatore. Il problema è che
+questi identificatori non
+
\subsection{Code di messaggi}
\label{sec:ipc_messque}
-Il primo oggetto introdotto dal \textit{SystemV IPC} è quello delle code di
+Il primo oggetto introdotto dal \textit{System V IPC} è quello delle code di
messaggi.
\subsection{Semafori}
\label{sec:ipc_semaph}
-Il secondo oggetto introdotto dal \textit{SystemV IPC} è quello dei semafori.
+Il secondo oggetto introdotto dal \textit{System V IPC} è quello dei semafori.
\subsection{Memoria condivisa}
\label{sec:ipc_shar_mem}
-Il terzo oggetto introdotto dal \textit{SystemV IPC} è quello della memoria
+Il terzo oggetto introdotto dal \textit{System V IPC} è quello della memoria
condivisa.
+
+
+
+\section{La comunicazione fra processi di POSIX}
+\label{sec:ipc_posix}
+
+Lo standard POSIX.1b ha introdotto dei nuovi meccanismi di comunicazione,
+rifacendosi a quelli di System V, introducendo una nuova interfaccia che
+evitasse i principali problemi evidenziati in ...
+
+
+
+
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
projects / gapil.git / blobdiff