%% ipc.tex
%%
-%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2013 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
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 neanche 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.
+complessi ed evoluti come le RPC (\textit{Remote Procedure Calls}) che in
+genere sono implementati da un ulteriore livello di librerie sopra i
+meccanismi elementari.
\section{L'intercomunicazione fra processi tradizionale}
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 una coppia di file descriptor\footnote{si tenga presente che
- le pipe sono oggetti creati dal kernel e non risiedono su disco.} connessi
-fra di loro in modo che se quanto scrive su di uno si può rileggere
-dall'altro. Si viene così a costituire un canale di comunicazione tramite i
-due file descriptor, nella forma di un \textsl{tubo} (da cui il nome)
-attraverso cui fluiscono i dati.
-
-La funzione che permette di creare questa speciale coppia di file descriptor
-associati ad una \textit{pipe} è appunto \funcd{pipe}, ed 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 \errval{EMFILE},
- \errval{ENFILE} e \errval{EFAULT}.}
-\end{prototype}
+sostanza di una coppia di file descriptor connessi fra di loro in modo che
+quanto scrive su di uno si può rileggere dall'altro. Si viene così a
+costituire un canale di comunicazione realizzato tramite i due file
+descriptor, che costituisce appunto una sorta di \textsl{tubo} (che appunto il
+significato del termine inglese \textit{pipe}) attraverso cui si possono far
+passare i dati.
+
+In pratica si tratta di un buffer circolare in memoria in cui il kernel
+appoggia i dati immessi nel file descriptor su cui si scrive per farli poi
+riemergere dal file descriptor da cui si legge. Si tenga ben presente che in
+questo passaggio di dati non è previsto nessun tipo di accesso al disco e che
+nonostante l'uso dei file descriptor le \textit{pipe} non han nulla a che fare
+con i file di dati di cui si è parlato al cap.~\ref{cha:file_IO_interface}.
+
+La funzione di sistema che permette di creare questa speciale coppia di file
+descriptor associati ad una \textit{pipe} è appunto \funcd{pipe}, ed il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int pipe(int filedes[2])}
+\fdesc{Crea la coppia di file descriptor di una \textit{pipe}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EFAULT}] \param{filedes} non è un indirizzo valido.
+ \end{errlist}
+ ed inoltre \errval{EMFILE} e \errval{ENFILE} nel loro significato generico.}
+\end{funcproto}
La funzione restituisce la coppia di file descriptor nel vettore
-\param{filedes}; il primo è aperto in lettura ed il secondo in scrittura. Come
-accennato concetto di funzionamento di una pipe è semplice: quello che si
-scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
-nel file descriptor aperto in lettura. I file descriptor infatti non sono
-connessi a nessun file reale, ma, come accennato in
-sez.~\ref{sec:file_sendfile_splice}, ad un buffer nel kernel, la cui
-dimensione è specificata dal parametro di sistema \const{PIPE\_BUF}, (vedi
-sez.~\ref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
-illustrato in fig.~\ref{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.
+\param{filedes}, il primo è aperto in lettura ed il secondo in scrittura. Come
+accennato concetto di funzionamento di una \textit{pipe} è semplice: quello
+che si scrive nel file descriptor aperto in scrittura viene ripresentato tale
+e quale nel file descriptor aperto in lettura.
+
+I file descriptor infatti non sono connessi a nessun file reale, ma, come
+accennato, ad un buffer nel kernel la cui dimensione è specificata dal
+parametro di sistema \const{PIPE\_BUF}, (vedi
+sez.~\ref{sec:sys_file_limits}). Lo schema di funzionamento di una
+\textit{pipe} è illustrato in fig.~\ref{fig:ipc_pipe_singular}, in cui sono
+indicati i due capi della \textit{pipe}, associati a ciascun file descriptor,
+con le frecce che indicano la direzione del flusso dei dati.
\begin{figure}[!htb]
\centering
\includegraphics[height=5cm]{img/pipe}
- \caption{Schema della struttura di una pipe.}
+ \caption{Schema della struttura di una \textit{pipe}.}
\label{fig:ipc_pipe_singular}
\end{figure}
-Chiaramente creare una pipe all'interno di un singolo processo non serve a
-niente; se però ricordiamo quanto esposto in sez.~\ref{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
+Della funzione di sistema esiste una seconda versione, \funcd{pipe2},
+introdotta con il kernel 2.6.27 e le \acr{glibc} 2.9 e specifica di Linux
+(utilizzabile solo definendo la macro \macro{\_GNU\_SOURCE}), che consente di
+impostare atomicamente le caratteristiche dei file descriptor restituiti, il
+suo prototipo è:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fhead{fcntl.h}
+\fdecl{int pipe2(int pipefd[2], int flags)}
+\fdesc{Crea la coppia di file descriptor di una \textit{pipe}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] il valore di \param{flags} non valido.
+ \end{errlist}
+ e gli altri già visti per \func{pipe} con lo stesso significato.}
+\end{funcproto}
+
+Utilizzando un valore nullo per \param{flags} la funzione è identica a
+\func{pipe}, si può però passare come valore l'OR aritmetico di uno qualunque
+fra \const{O\_NONBLOCK} o \const{O\_CLOEXEC} che hanno l'effetto di impostare
+su entrambi i file descriptor restituiti dalla funzione i relativi flag, già
+descritti per \func{open} in tab.~\ref{tab:open_operation_flag}, che attivano
+rispettivamente la modalità di accesso \textsl{non-bloccante} ed il
+\textit{close-on-exec} \itindex{close-on-exec}.
+
+Chiaramente creare una \textit{pipe} all'interno di un singolo processo non
+serve a niente; se però ricordiamo quanto esposto in
+sez.~\ref{sec:file_shared_access} riguardo al comportamento dei file
+descriptor nei processi figli, è immediato capire come una \textit{pipe} possa
+diventare un meccanismo di intercomunicazione. Un processo figlio infatti
+condivide gli stessi file descriptor del padre, compresi quelli associati ad
+una \textit{pipe} (secondo la situazione illustrata in
fig.~\ref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
-capo della pipe, l'altro può leggere.
+capo della \textit{pipe}, l'altro può leggere.
\begin{figure}[!htb]
\centering
\includegraphics[height=5cm]{img/pipefork}
- \caption{Schema dei collegamenti ad una pipe, condivisi fra processo padre e
- figlio dopo l'esecuzione \func{fork}.}
+ \caption{Schema dei collegamenti ad una \textit{pipe}, condivisi fra
+ processo padre e figlio dopo l'esecuzione \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 proprietà
-ordinarie dei file, ma ci mostra anche qual è il principale\footnote{Stevens
- in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
- unidirezionale, ma in realtà questo è un limite facilmente superabile 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 essere \textsl{parenti} (dall'inglese \textit{siblings}), cioè
-o derivare da uno stesso processo padre in cui è avvenuta la creazione della
-pipe, o, più comunemente, essere nella relazione padre/figlio.
-
-A differenza di quanto avviene con i file normali, la lettura da una pipe può
-essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
-pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
-(vale a dire che la funzione \func{read} ritornerà restituendo 0). Se invece
-si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
-processo riceverà il segnale \signal{SIGPIPE}, e la funzione di scrittura
-restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
-segnale sia ignorato o bloccato).
-
-La dimensione del buffer della pipe (\const{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}
+comunicazione fra processi attraverso una \textit{pipe}, utilizzando le
+proprietà ordinarie dei file, ma ci mostra anche qual è il principale limite
+nell'uso delle \textit{pipe}.\footnote{Stevens in \cite{APUE} riporta come
+ limite anche il fatto che la comunicazione è unidirezionale, ma in realtà
+ questo è un limite superabile usando una coppia di \textit{pipe}, anche se
+ al costo di una maggiore complessità di gestione.} È necessario infatti che
+i processi possano condividere i file descriptor della \textit{pipe}, e per
+questo essi devono comunque essere \textsl{parenti} (dall'inglese
+\textit{siblings}), cioè o derivare da uno stesso processo padre in cui è
+avvenuta la creazione della \textit{pipe}, o, più comunemente, essere nella
+relazione padre/figlio.
+
+A differenza di quanto avviene con i file normali, la lettura da una
+\textit{pipe} può essere bloccante (qualora non siano presenti dati), inoltre
+se si legge da una \textit{pipe} il cui capo in scrittura è stato chiuso, si
+avrà la ricezione di un EOF (vale a dire che la funzione \func{read} ritornerà
+restituendo 0). Se invece si esegue una scrittura su una \textit{pipe} il cui
+capo in lettura non è aperto il processo riceverà il segnale \signal{SIGPIPE},
+e la funzione di scrittura restituirà un errore di \errcode{EPIPE} (al ritorno
+del gestore, o qualora il segnale sia ignorato o bloccato).
+
+La dimensione del buffer della \textit{pipe} (\const{PIPE\_BUF}) ci dà inoltre
+un'altra importante informazione riguardo il comportamento delle operazioni di
+lettura e scrittura su di una \textit{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.
+
+La dimensione originale del buffer era di 4096 byte (uguale ad una pagina di
+memoria) fino al kernel 2.6.11, ed è stata portata in seguito a 64kb; ma a
+partire dal kernel 2.6.35 è stata resa disponibile l'operazione di controllo
+\const{F\_SETPIPE\_SZ} (vedi sez.~\ref{sec:ipc_pipes}) che consente di
+modificarne la dimensione.
+
+
+
+\subsection{Un esempio dell'uso delle \textit{pipe}}
\label{sec:ipc_pipe_use}
-Per capire meglio il funzionamento delle 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. Realizzeremo il programma di esempio 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 barre, specificato come argomento in ingresso.
+Per capire meglio il funzionamento delle \textit{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. Realizzeremo il programma di esempio nella forma di un
+\textit{CGI}\footnote{quella dei CGI (\textit{Common Gateway Interface}) è una
+ interfaccia che consente ad un server web di eseguire un programma il cui
+ output (che deve essere opportunamente formattato seguendo le specifiche
+ dell'interfaccia) può essere presentato come risposta ad una richiesta HTTP
+ al posto del contenuto di un file, e che ha costituito probabilmente la
+ prima modalità con cui sono state create pagine HTML dinamiche.} che genera
+una immagine JPEG di un codice a barre, specificato come argomento in
+ingresso.
Un programma che deve essere eseguito come \textit{CGI} deve rispondere a
delle caratteristiche specifiche, esso infatti non viene lanciato da una
shell, ma dallo stesso web server, alla richiesta di una specifica URL, che di
solito ha la forma:
-\begin{verbatim}
- http://www.sito.it/cgi-bin/programma?argomento
-\end{verbatim}
+\begin{Verbatim}
+http://www.sito.it/cgi-bin/programma?argomento
+\end{Verbatim}
ed il risultato dell'elaborazione deve essere presentato (con una intestazione
-che ne descrive il mime-type) sullo standard output, in modo che il web-server
-possa reinviarlo al browser che ha effettuato la richiesta, che in questo modo
-è in grado di visualizzarlo opportunamente.
-
-Per realizzare quanto voluto useremo in sequenza 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, mentre il secondo
-serve per poter effettuare la conversione della stessa immagine in formato
-JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
-secondo, secondo lo schema mostrato in fig.~\ref{fig:ipc_pipe_use}, in cui la
-direzione del flusso dei dati è data dalle frecce continue.
+che ne descrive il \textit{mime-type}) sullo \textit{standard output}, in modo
+che il server web possa reinviarlo al browser che ha effettuato la richiesta,
+che in questo modo è in grado di visualizzarlo opportunamente.
\begin{figure}[!htb]
\centering
\includegraphics[height=5cm]{img/pipeuse}
- \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
+ \caption{Schema dell'uso di una \textit{pipe} come mezzo di comunicazione fra
due processi attraverso l'esecuzione una \func{fork} e la chiusura dei
capi non utilizzati.}
\label{fig:ipc_pipe_use}
\end{figure}
+Per realizzare quanto voluto useremo in sequenza 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, mentre il secondo
+serve per poter effettuare la conversione della stessa immagine in formato
+JPEG. Usando una \textit{pipe} potremo inviare l'output del primo sull'input del
+secondo, secondo lo schema mostrato in fig.~\ref{fig:ipc_pipe_use}, in cui la
+direzione del flusso dei dati è data dalle frecce continue.
+
Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
-\textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
+\textit{CGI} può essere eseguito più volte in contemporanea, e si avrebbe una
evidente \itindex{race~condition} \textit{race condition} in caso di accesso
-simultaneo a detto file.\footnote{il problema potrebbe essere superato
- determinando in anticipo un nome appropriato per il file temporaneo, che
- verrebbe utilizzato dai vari sotto-processi, e cancellato alla fine della
- loro esecuzione; ma a questo punto le cose non sarebbero più tanto
- semplici.} L'uso di una pipe invece permette di risolvere il problema in
-maniera semplice ed elegante, oltre ad essere molto più efficiente, dato che
-non si deve scrivere su disco.
+simultaneo a detto file da istanze diverse. Il problema potrebbe essere
+superato utilizzando un sempre diverso per il file temporaneo, che verrebbe
+creato all'avvio di ogni istanza, utilizzato dai sottoprocessi, e cancellato
+alla fine della sua esecuzione; ma a questo punto le cose non sarebbero più
+tanto semplici. L'uso di una \textit{pipe} invece permette 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
sez.~\ref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
funzioni infatti che è possibile dirottare gli stream standard dei processi
-(che abbiamo visto in sez.~\ref{sec:file_std_descr} e
-sez.~\ref{sec:file_std_stream}) sulla pipe. In
+(che abbiamo visto in tab.~\ref{tab:file_std_files} e
+sez.~\ref{sec:file_stream}) sulla \textit{pipe}. In
fig.~\ref{fig:ipc_barcodepage_code} abbiamo riportato il corpo del programma,
il cui codice completo è disponibile nel file \file{BarCodePage.c} che si
trova nella directory dei sorgenti.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/BarCodePage.c}
\end{figure}
La prima operazione del programma (\texttt{\small 4--12}) è quella di creare
-le due pipe che serviranno per la comunicazione fra i due comandi utilizzati
-per produrre il codice a barre; si ha cura di controllare la riuscita della
-chiamata, inviando in caso di errore un messaggio invece dell'immagine
-richiesta.\footnote{la funzione \func{WriteMess} non è riportata in
- fig.~\ref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
- formattare l'uscita alla maniera dei CGI, aggiungendo l'opportuno
- \textit{mime type}, e formattando il messaggio in HTML, in modo che
- quest'ultimo possa essere visualizzato correttamente da un browser.}
-
-Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
-primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
-\cmd{barcode}. Quest'ultimo legge dallo standard input una stringa di
-caratteri, la converte nell'immagine PostScript del codice a barre ad essa
-corrispondente, e poi scrive il risultato direttamente sullo standard output.
+le due \textit{pipe} che serviranno per la comunicazione fra i due comandi
+utilizzati per produrre il codice a barre; si ha cura di controllare la
+riuscita della chiamata, inviando in caso di errore un messaggio invece
+dell'immagine richiesta. La funzione \func{WriteMess} non è riportata in
+fig.~\ref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
+formattare l'uscita alla maniera dei CGI, aggiungendo l'opportuno
+\textit{mime-type}, e formattando il messaggio in HTML, in modo che
+quest'ultimo possa essere visualizzato correttamente da un browser.
+
+Una volta create le \textit{pipe}, il programma può creare (\texttt{\small
+ 13-17}) il primo processo figlio, che si incaricherà (\texttt{\small
+ 19--25}) di eseguire \cmd{barcode}. Quest'ultimo legge dallo standard input
+una stringa di caratteri, la converte nell'immagine PostScript del codice a
+barre ad essa corrispondente, e poi scrive il risultato direttamente sullo
+standard output.
Per poter utilizzare queste caratteristiche prima di eseguire \cmd{barcode} si
-chiude (\texttt{\small 20}) il capo aperto in scrittura della prima pipe, e se
-ne collega (\texttt{\small 21}) il capo in lettura allo standard input, usando
-\func{dup2}. Si ricordi che invocando \func{dup2} il secondo file, qualora
-risulti aperto, viene, come nel caso corrente, chiuso prima di effettuare la
-duplicazione. Allo stesso modo, dato che \cmd{barcode} scrive l'immagine
-PostScript del codice a barre sullo standard output, per poter effettuare una
-ulteriore redirezione il capo in lettura della seconda pipe viene chiuso
-(\texttt{\small 22}) mentre il capo in scrittura viene collegato allo standard
-output (\texttt{\small 23}).
+chiude (\texttt{\small 20}) il capo aperto in scrittura della prima
+\textit{pipe}, e se ne collega (\texttt{\small 21}) il capo in lettura allo
+\textit{standard input} usando \func{dup2}. Si ricordi che invocando
+\func{dup2} il secondo file, qualora risulti aperto, viene, come nel caso
+corrente, chiuso prima di effettuare la duplicazione. Allo stesso modo, dato
+che \cmd{barcode} scrive l'immagine PostScript del codice a barre sullo
+standard output, per poter effettuare una ulteriore redirezione il capo in
+lettura della seconda \textit{pipe} viene chiuso (\texttt{\small 22}) mentre
+il capo in scrittura viene collegato allo standard output (\texttt{\small
+ 23}).
In questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} (cui si
passa in \var{size} la dimensione della pagina per l'immagine) quest'ultimo
-leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
-padre, e scriverà l'immagine PostScript del codice a barre sulla seconda.
+leggerà dalla prima \textit{pipe} la stringa da codificare che gli sarà
+inviata dal padre, e scriverà l'immagine PostScript del codice a barre sulla
+seconda.
Al contempo una volta lanciato il primo figlio, il processo padre prima chiude
-(\texttt{\small 26}) il capo inutilizzato della prima pipe (quello in input) e
-poi scrive (\texttt{\small 27}) la stringa da convertire sul capo in output,
-così che \cmd{barcode} possa riceverla dallo standard input. A questo punto
-l'uso della prima pipe da parte del padre è finito ed essa può essere
-definitivamente chiusa (\texttt{\small 28}), si attende poi (\texttt{\small
- 29}) che l'esecuzione di \cmd{barcode} sia completata.
+(\texttt{\small 26}) il capo inutilizzato della prima \textit{pipe} (quello in
+ingresso) e poi scrive (\texttt{\small 27}) la stringa da convertire sul capo
+in uscita, così che \cmd{barcode} possa riceverla dallo \textit{standard
+ input}. A questo punto l'uso della prima \textit{pipe} da parte del padre è
+finito ed essa può essere definitivamente chiusa (\texttt{\small 28}), si
+attende poi (\texttt{\small 29}) che l'esecuzione di \cmd{barcode} sia
+completata.
Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
-PostScript del codice a barre sul capo in scrittura della seconda pipe; a
-questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
-programma \cmd{gs}. Per questo si crea (\texttt{\small 30--34}) un secondo
-processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
-leggendo l'immagine PostScript creata da \cmd{barcode} dallo standard input,
-per convertirla in JPEG.
+PostScript del codice a barre sul capo in scrittura della seconda
+\textit{pipe}; a questo punto si può eseguire la seconda conversione, da PS a
+JPEG, usando il programma \cmd{gs}. Per questo si crea (\texttt{\small
+ 30--34}) un secondo processo figlio, che poi (\texttt{\small 35--42})
+eseguirà questo programma leggendo l'immagine PostScript creata da
+\cmd{barcode} dallo \textit{standard input}, per convertirla in JPEG.
Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
-scrittura della seconda pipe, e se ne collega (\texttt{\small 38}) il capo in
-lettura allo standard input. Per poter formattare l'output del programma in
-maniera utilizzabile da un browser, si provvede anche \texttt{\small 40}) alla
-scrittura dell'apposita stringa di identificazione del mime-type in testa allo
-standard output. A questo punto si può invocare \texttt{\small 41}) \cmd{gs},
-provvedendo gli appositi switch che consentono di leggere il file da
-convertire dallo standard input e di inviare la conversione sullo standard
-output.
+scrittura della seconda \textit{pipe}, e se ne collega (\texttt{\small 38}) il
+capo in lettura allo \textit{standard input}. Per poter formattare l'output
+del programma in maniera utilizzabile da un browser, si provvede anche
+\texttt{\small 40}) alla scrittura dell'apposita stringa di identificazione
+del \textit{mime-type} in testa allo \textit{standard output}. A questo punto
+si può invocare \texttt{\small 41}) \cmd{gs}, provvedendo le opportune opzioni
+del comando che consentono di leggere il file da convertire dallo
+\textit{standard input} e di inviare la conversione sullo \textit{standard
+ output}.
Per completare le operazioni il processo padre chiude (\texttt{\small 44}) il
-capo in scrittura della seconda pipe, e attende la conclusione del figlio
-(\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
-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.
+capo in scrittura della seconda \textit{pipe}, e attende la conclusione del
+figlio (\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 \textit{pipe} è necessaria, infatti, se non venisse chiusa, \cmd{gs},
+che legge il suo \textit{standard input} da detta \textit{pipe}, resterebbe
+bloccato in attesa di ulteriori dati in ingresso (l'unico modo che un
+programma ha per sapere che i dati in ingresso sono terminati è rilevare che
+lo \textit{standard input} è stato chiuso), e la \func{wait} non ritornerebbe.
\subsection{Le funzioni \func{popen} e \func{pclose}}
\label{sec:ipc_popen}
-Come si è visto la modalità più comune di utilizzo di una pipe è quella di
-utilizzarla per fare da tramite fra output ed input di due programmi invocati
-in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
-che permettono di sintetizzare queste operazioni. La prima di esse si chiama
-\funcd{popen} ed il suo prototipo è:
-\begin{prototype}{stdio.h}
-{FILE *popen(const char *command, const char *type)}
-
-Esegue il programma \param{command}, di cui, a seconda di \param{type},
-restituisce, lo standard input o lo standard output nella pipe collegata allo
-stream restituito come valore di ritorno.
-
-\bodydesc{La funzione restituisce l'indirizzo dello stream associato alla pipe
- in caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
- potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
- e \func{fork} o \errcode{EINVAL} se \param{type} non è valido.}
-\end{prototype}
+Come si è visto la modalità più comune di utilizzo di una \textit{pipe} è
+quella di utilizzarla per fare da tramite fra output ed input di due programmi
+invocati in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due
+funzioni che permettono di sintetizzare queste operazioni. La prima di esse si
+chiama \funcd{popen} ed il suo prototipo è:
+
+
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{FILE *popen(const char *command, const char *type)}
+\fdesc{Esegue un programma dirottando l'uscita su una \textit{pipe}.}
+}
-La funzione crea una pipe, esegue una \func{fork}, ed invoca il programma
-\param{command} attraverso la shell (in sostanza esegue \file{/bin/sh} con il
-flag \code{-c}); l'argomento \param{type} deve essere una delle due stringhe
-\verb|"w"| o \verb|"r"|, per indicare se la pipe sarà collegata allo standard
-input o allo standard output del comando invocato.
-
-La funzione restituisce il puntatore allo stream associato alla pipe creata,
-che sarà aperto in sola lettura (e quindi associato allo standard output del
-programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
-quindi associato allo standard input) in caso di \code{"w"}.
-
-Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
-stream visti in cap.~\ref{cha:files_std_interface}, anche se è collegato ad
-una pipe e non ad un file, e viene sempre aperto in modalità
-\textit{fully-buffered} (vedi sez.~\ref{sec:file_buffering}); l'unica
+{La funzione ritorna l'indirizzo dello stream associato alla \textit{pipe} in
+ caso di successo e \val{NULL} per un errore, nel qual caso \var{errno} potrà
+ assumere i valori relativi alle sottostanti invocazioni di \func{pipe} e
+ \func{fork} o \errcode{EINVAL} se \param{type} non è valido.}
+\end{funcproto}
+
+La funzione crea una \textit{pipe}, esegue una \func{fork} creando un nuovo
+processe nel quale invoca il programma \param{command} attraverso la shell (in
+sostanza esegue \file{/bin/sh} con il flag \code{-c}).
+L'argomento \param{type} deve essere una delle due stringhe \verb|"w"| o
+\verb|"r"|, per richiedere che la \textit{pipe} restituita come valore di
+ritorno sia collegata allo \textit{standard input} o allo \textit{standard
+ output} del comando invocato.
+
+La funzione restituisce il puntatore ad uno stream associato alla
+\textit{pipe} creata, che sarà aperto in sola lettura (e quindi associato allo
+\textit{standard output} del programma indicato) in caso si sia indicato
+\code{r}, o in sola scrittura (e quindi associato allo \textit{standard
+ input}) in caso di \code{w}. A partire dalla versione 2.9 delle \acr{glibc}
+(questa è una estensione specifica di Linux) all'argomento \param{type} può
+essere aggiunta la lettera ``\texttt{e}'' per impostare automaticamente il
+flag di \textit{close-on-exec} \itindex{close-on-exec} sul file descriptor
+sottostante (si ricordi quanto spiegato in sez.~\ref{sec:file_open_close}).
+
+Lo \textit{stream} restituito da \func{popen} è identico a tutti gli effetti
+ai \textit{file stream} visti in sez.~\ref{sec:files_std_interface}, anche se
+è collegato ad una \textit{pipe} e non ad un file, e viene sempre aperto in
+modalità \textit{fully-buffered} (vedi sez.~\ref{sec:file_buffering}); l'unica
differenza con gli usuali stream è che dovrà essere chiuso dalla seconda delle
due nuove funzioni, \funcd{pclose}, il cui prototipo è:
-\begin{prototype}{stdio.h}
-{int pclose(FILE *stream)}
-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
- errore; nel quel caso il valore di \var{errno} deriva dalle sottostanti
- chiamate.}
-\end{prototype}
-\noindent che oltre alla chiusura dello stream si incarica anche di attendere
-(tramite \func{wait4}) la conclusione del processo creato dalla precedente
-\func{popen}.
+\begin{funcproto}{
+\fhead{stdio.h}
+\fdecl{int pclose(FILE *stream)}
+\fdesc{Chiude una \textit{pipe} creata con \func{popen}.}
+}
+
+{La funzione ritorna lo stato del processo creato da \func{popen} in caso di
+ successo e $-1$ per un errore, nel qual caso \var{errno} assumerà i valori
+ derivanti dalle sottostanti funzioni \func{fclose} e \func{wait4}.}
+\end{funcproto}
+
+La funzione chiude il file \param{stream} associato ad una \textit{pipe}
+creato da una precedente \func{popen}, ed oltre alla chiusura dello stream si
+incarica anche di attendere (tramite \func{wait4}) la conclusione del processo
+creato dalla precedente \func{popen}. Se lo stato di uscita non può essere
+letto la funzione restituirà per \var{errno} un errore di \errval{ECHILD}.
Per illustrare l'uso di queste due funzioni riprendiamo il problema
precedente: il programma mostrato in fig.~\ref{fig:ipc_barcodepage_code} per
-quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
-inoltre nella pratica sconta un problema di \cmd{gs} che non è in
-grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
-riconoscere correttamente l'Encapsulated PostScript, per cui deve essere usato
-il PostScript e tutte le volte viene generata una pagina intera, invece che
-una immagine delle dimensioni corrispondenti al codice a barre.
+quanto funzionante, è volutamente codificato in maniera piuttosto complessa,
+inoltre doveva scontare un problema di \cmd{gs} che non era in grado di
+riconoscere correttamente l'Encapsulated PostScript,\footnote{si fa
+ riferimento alla versione di GNU Ghostscript 6.53 (2002-02-13), usata quando
+ l'esempio venne scritto per la prima volta.} per cui si era utilizzato il
+PostScript semplice, generando una pagina intera invece che una immagine delle
+dimensioni corrispondenti al codice a barre.
Se si vuole generare una immagine di dimensioni appropriate si deve usare un
approccio diverso. Una possibilità sarebbe quella di ricorrere ad ulteriore
programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
-generato da \cmd{barcode} utilizzando lo switch \cmd{-E}). Utilizzando un PDF
+generato da \cmd{barcode} utilizzando l'opzione \cmd{-E}). Utilizzando un PDF
al posto di un EPS \cmd{gs} esegue la conversione rispettando le dimensioni
originarie del codice a barre e produce un JPEG di dimensioni corrette.
-Questo approccio però non funziona, per via di una delle caratteristiche
-principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
-necessario, per la struttura del formato, potersi spostare (con \func{lseek})
-all'interno del file da convertire; se si esegue la conversione con \cmd{gs}
-su un file regolare non ci sono problemi, una pipe però è rigidamente
-sequenziale, e l'uso di \func{lseek} su di essa fallisce sempre con un errore
-di \errcode{ESPIPE}, rendendo impossibile la conversione. Questo ci dice che
-in generale la concatenazione di vari programmi funzionerà soltanto quando
-tutti prevedono una lettura sequenziale del loro input.
+Questo approccio però non può funzionare per via di una delle caratteristiche
+principali delle \textit{pipe}. Per poter effettuare la conversione di un PDF
+infatti è necessario, per la struttura del formato, potersi spostare (con
+\func{lseek}) all'interno del file da convertire. Se si esegue la conversione
+con \cmd{gs} su un file regolare non ci sono problemi, una \textit{pipe} però
+è rigidamente sequenziale, e l'uso di \func{lseek} su di essa fallisce sempre
+con un errore di \errcode{ESPIPE}, rendendo impossibile la conversione.
+Questo ci dice che in generale la concatenazione di vari programmi funzionerà
+soltanto quando tutti prevedono una lettura sequenziale del loro input.
Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
prima la conversione (sempre con \cmd{gs}) del PS in un altro formato
intermedio, il PPM,\footnote{il \textit{Portable PixMap file format} è un
formato usato spesso come formato intermedio per effettuare conversioni, è
infatti molto facile da manipolare, dato che usa caratteri ASCII per
- memorizzare le immagini, anche se per questo è estremamente inefficiente.}
-dal quale poi si può ottenere un'immagine di dimensioni corrette attraverso
-vari programmi di manipolazione (\cmd{pnmcrop}, \cmd{pnmmargin}) che può
-essere infine trasformata in PNG (con \cmd{pnm2png}).
+ memorizzare le immagini, anche se per questo è estremamente inefficiente
+ come formato di archiviazione.} dal quale poi si può ottenere un'immagine
+di dimensioni corrette attraverso vari programmi di manipolazione
+(\cmd{pnmcrop}, \cmd{pnmmargin}) che può essere infine trasformata in PNG (con
+\cmd{pnm2png}).
In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
-inviando l'output di ciascuno all'input del successivo, per poi ottenere il
-risultato finale sullo standard output: un caso classico di utilizzazione
-delle pipe, in cui l'uso di \func{popen} e \func{pclose} permette di
-semplificare notevolmente la stesura del codice.
-
-Nel nostro caso, dato che ciascun processo deve scrivere il suo output sullo
-standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
-scrittura. Il codice del nuovo programma è riportato in
+inviando l'uscita di ciascuno all'ingresso del successivo, per poi ottenere il
+risultato finale sullo \textit{standard output}: un caso classico di
+utilizzazione delle \textit{pipe}, in cui l'uso di \func{popen} e \func{pclose}
+permette di semplificare notevolmente la stesura del codice.
+
+Nel nostro caso, dato che ciascun processo deve scrivere la sua uscita sullo
+\textit{standard input} del successivo, occorrerà usare \func{popen} aprendo
+la \textit{pipe} in scrittura. Il codice del nuovo programma è riportato in
fig.~\ref{fig:ipc_barcode_code}. Come si può notare l'ordine di invocazione
dei programmi è l'inverso di quello in cui ci si aspetta che vengano
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 precedente, benché quest'ultimo venga invocato
-dopo.
+lettura su una \textit{pipe} è bloccante, per cui un processo, anche se
+lanciato per primo, se non ottiene i dati che gli servono si bloccherà in
+attesa sullo \textit{standard input} finché non otterrà il risultato
+dell'elaborazione del processo che li deve creare, che pur essendo logicamente
+precedente, viene lanciato dopo di lui.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/BarCode.c}
\label{fig:ipc_barcode_code}
\end{figure}
-Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il mime-type
-sullo standard output; a questo punto il processo padre non necessita più di
-eseguire ulteriori operazioni sullo standard output e può tranquillamente
-provvedere alla redirezione.
+Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il
+\textit{mime-type} sullo \textit{standard output}; a questo punto il processo
+padre non necessita più di eseguire ulteriori operazioni sullo
+\textit{standard output} e può tranquillamente provvedere alla redirezione.
Dato che i vari programmi devono essere lanciati in successione, si è
approntato un ciclo (\texttt{\small 15--19}) che esegue le operazioni in
-sequenza: prima crea una pipe (\texttt{\small 17}) per la scrittura eseguendo
-il programma con \func{popen}, in modo che essa sia collegata allo standard
-input, e poi redirige (\texttt{\small 18}) lo standard output su detta pipe.
+sequenza: prima crea una \textit{pipe} (\texttt{\small 17}) per la scrittura
+eseguendo il programma con \func{popen}, in modo che essa sia collegata allo
+\textit{standard input}, e poi redirige (\texttt{\small 18}) lo
+\textit{standard output} su detta \textit{pipe}.
In questo modo il primo processo ad essere invocato (che è l'ultimo della
-catena) scriverà ancora sullo standard output del processo padre, ma i
-successivi, a causa di questa redirezione, scriveranno sulla pipe associata
-allo standard input del processo invocato nel ciclo precedente.
+catena) scriverà ancora sullo \textit{standard output} del processo padre, ma
+i successivi, a causa di questa redirezione, scriveranno sulla \textit{pipe}
+associata allo \textit{standard input} del processo invocato nel ciclo
+precedente.
Alla fine tutto quello che resta da fare è lanciare (\texttt{\small 21}) il
primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
-(\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
-al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
-ciclo che chiuda, nell'ordine inverso rispetto a quello in cui le si sono
-create, tutte le pipe create con \func{pclose}.
+(\texttt{\small 23}) la stringa del codice a barre sulla \textit{pipe}, che è
+collegata al suo \textit{standard input}, infine si può eseguire
+(\texttt{\small 24--27}) un ciclo che chiuda con \func{pclose}, nell'ordine
+inverso rispetto a quello in cui le si sono create, tutte le \textit{pipe}
+create in precedenza.
\subsection{Le \textit{pipe} con nome, o \textit{fifo}}
Come accennato in sez.~\ref{sec:ipc_pipes} il problema delle \textit{pipe} è
che esse possono essere utilizzate solo da processi con un progenitore comune
-o nella relazione padre/figlio; per superare questo problema lo standard
-POSIX.1 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
-caratteristiche delle pipe, ma che invece di essere strutture interne del
-kernel, visibili solo attraverso un file descriptor, sono accessibili
-attraverso un \itindex{inode} inode che risiede sul filesystem, così che i
-processi le possono usare senza dovere per forza essere in una relazione di
-\textsl{parentela}.
-
-Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
-attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
-\itindex{inode} l'inode allocato sul filesystem serve infatti solo a fornire un
-punto di riferimento per i processi, che permetta loro di accedere alla stessa
-fifo; il comportamento delle funzioni di lettura e scrittura è identico a
-quello illustrato per le pipe in sez.~\ref{sec:ipc_pipes}.
-
-Abbiamo già visto in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
-\func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
-processo non avrà che da aprire il relativo file speciale o in lettura o
-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 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
-eseguita quando l'altro capo non è aperto.
-
-Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
-nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
-l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
-l'errore di \errcode{ENXIO} fintanto che non verrà aperto il capo in lettura.
-
-In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
- standard POSIX lascia indefinito il comportamento in questo caso.}
-operazione che avrà 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 situazioni di
-stallo.\footnote{se si cerca di leggere da una fifo che non contiene dati si
- avrà un \itindex{deadlock} deadlock immediato, dato che il processo si
- blocca e non potrà quindi mai eseguire le funzioni di scrittura.}
+o nella relazione padre/figlio. Per superare questo problema lo standard
+POSIX.1 ha introdotto le \textit{fifo}, che hanno le stesse caratteristiche
+delle \textit{pipe}, ma che invece di essere visibili solo attraverso un file
+descriptor creato all'interno di un processo da una \textit{system call}
+apposita, costituiscono un oggetto che risiede sul filesystem (si rammenti
+quanto detto in sez.~\ref{sec:file_file_types}) che può essere aperto come un
+qualunque file, così che i processi le possono usare senza dovere per forza
+essere in una relazione di \textsl{parentela}.
+
+Utilizzando una \textit{fifo} tutti i dati passeranno, come per le
+\textit{pipe}, attraverso un buffer nel kernel, senza transitare dal
+filesystem. Il fatto che siano associate ad un \itindex{inode}
+\textit{inode} presente sul filesystem serve infatti solo a fornire un punto
+di accesso per i processi, che permetta a questi ultimi di accedere alla
+stessa \textit{fifo} senza avere nessuna relazione, con una semplice
+\func{open}. Il comportamento delle funzioni di lettura e scrittura è identico
+a quello illustrato per le \textit{pipe} in sez.~\ref{sec:ipc_pipes}.
+
+Abbiamo già trattato in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
+\func{mkfifo} che permettono di creare una \textit{fifo}. Per utilizzarne una
+un processo non avrà che da aprire il relativo \index{file!speciali} file
+speciale o in lettura o scrittura; nel primo caso il processo sarà collegato
+al capo di uscita della \textit{fifo}, e dovrà leggere, nel secondo al capo di
+ingresso, e dovrà scrivere.
+
+Il kernel alloca un singolo buffer per ciascuna \textit{fifo} che sia stata
+aperta, e questa potrà 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 \textit{fifo} la funzione \func{open} di norma
+si blocca se viene eseguita quando l'altro capo non è aperto.
+
+Le \textit{fifo} però possono essere anche aperte in modalità
+\textsl{non-bloccante}, nel qual caso l'apertura del capo in lettura avrà
+successo solo quando anche l'altro capo è aperto, mentre l'apertura del capo
+in scrittura restituirà l'errore di \errcode{ENXIO} fintanto che non verrà
+aperto il capo in lettura.
+
+In Linux è possibile aprire le \textit{fifo} anche in lettura/scrittura (lo
+standard POSIX lascia indefinito il comportamento in questo caso) operazione
+che avrà sempre successo immediato qualunque sia la modalità di apertura,
+bloccante e non bloccante. Questo può essere utilizzato per aprire comunque
+una \textit{fifo} in scrittura anche se non ci sono ancora processi il
+lettura. Infine è possibile anche usare la \textit{fifo} all'interno di un
+solo processo, nel qual caso però occorre stare molto attenti alla possibili
+situazioni di stallo: se si cerca di leggere da una \textit{fifo} che non
+contiene dati si avrà infatti un \itindex{deadlock} \textit{deadlock}
+immediato, dato che il processo si blocca e quindi non potrà 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 da 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 \const{PIPE\_BUF} (si ricordi quanto detto in
-sez.~\ref{sec:ipc_pipes}).
+piuttosto frequente l'utilizzo di una \textit{fifo} come canale di
+comunicazione nelle situazioni un processo deve ricevere informazioni da
+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 \const{PIPE\_BUF} (si
+ricordi quanto detto in sez.~\ref{sec:ipc_pipes}).
A parte il caso precedente, che resta probabilmente il più comune, Stevens
-riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
-\begin{itemize}
+riporta in \cite{APUE} altre due casistiche principali per l'uso delle
+\textit{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 client ed server (il modello
- \textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}).
-\end{itemize}
+ 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
+ sez.~\ref{sec:net_cliserv}).
+\end{itemize*}
-Nel primo caso quello che si fa è creare tante fifo, da usare come standard
-input, quanti sono i processi a cui i vogliono inviare i dati, questi ultimi
-saranno stati posti in esecuzione ridirigendo lo standard input dalle fifo, si
-potrà poi eseguire il processo che fornisce l'output replicando quest'ultimo,
-con il comando \cmd{tee}, sulle varie fifo.
+Nel primo caso quello che si fa è creare tante \textit{fifo} da usare come
+\textit{standard input} quanti sono i processi a cui i vogliono inviare i
+dati; questi ultimi saranno stati posti in esecuzione ridirigendo lo
+\textit{standard input} dalle \textit{fifo}, si potrà poi eseguire il processo
+che fornisce l'output replicando quest'ultimo, con il comando \cmd{tee}, sulle
+varie \textit{fifo}.
Il secondo caso è relativamente semplice qualora si debba comunicare con un
-processo alla volta (nel qual caso basta usare due fifo, 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
-``\textsl{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.
+processo alla volta, nel qual caso basta usare due \textit{fifo}, una per
+leggere ed una per scrivere. Le cose diventano invece molto più complesse
+quando si vuole effettuare una comunicazione fra un server ed un numero
+imprecisato di client. Se il primo infatti può ricevere le richieste
+attraverso una \textit{fifo} ``\textsl{nota}'', per le risposte non si può
+fare altrettanto, dato che, per la struttura sequenziale delle \textit{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 in fig.~\ref{fig:ipc_fifo_server_arch} in cui i client inviano le
-richieste al server su una fifo nota mentre le risposte vengono reinviate dal
-server a ciascuno di essi su una fifo temporanea creata per l'occasione.
+illustrata in fig.~\ref{fig:ipc_fifo_server_arch} in cui i client
+inviano le richieste al server su una \textit{fifo} nota mentre le
+risposte vengono reinviate dal server a ciascuno di essi su una
+\textit{fifo} temporanea creata per l'occasione.
\begin{figure}[!htb]
\centering
\includegraphics[height=9cm]{img/fifoserver}
- \caption{Schema dell'utilizzo delle fifo nella realizzazione di una
- architettura di comunicazione client/server.}
+ \caption{Schema dell'utilizzo delle \textit{fifo} nella realizzazione di una
+ architettura di comunicazione client/server.}
\label{fig:ipc_fifo_server_arch}
\end{figure}
-Come esempio di uso questa architettura e dell'uso delle fifo, abbiamo scritto
-un server di \textit{fortunes}, che restituisce, alle richieste di un client,
-un detto a caso estratto da un insieme di frasi; sia il numero delle frasi
-dell'insieme, che i file da cui esse vengono lette all'avvio, sono importabili
-da riga di comando. Il corpo principale del server è riportato in
-fig.~\ref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
-gestione delle opzioni a riga di comando, che effettua il settaggio delle
-variabili \var{fortunefilename}, che indica il file da cui leggere le frasi,
-ed \var{n}, che indica il numero di frasi tenute in memoria, ad un valore
-diverso da quelli preimpostati. Il codice completo è nel file
-\file{FortuneServer.c}.
+Come esempio di uso questa architettura e dell'uso delle \textit{fifo},
+abbiamo scritto un server di \textit{fortunes}, che restituisce, alle
+richieste di un client, un detto a caso estratto da un insieme di frasi. Sia
+il numero delle frasi dell'insieme, che i file da cui esse vengono lette
+all'avvio, sono impostabili da riga di comando. Il corpo principale del
+server è riportato in fig.~\ref{fig:ipc_fifo_server}, dove si è
+tralasciata la parte che tratta la gestione delle opzioni a riga di comando,
+che effettua l'impostazione delle variabili \var{fortunefilename}, che indica
+il file da cui leggere le frasi, ed \var{n}, che indica il numero di frasi
+tenute in memoria, ad un valore diverso da quelli preimpostati. Il codice
+completo è nel file \file{FortuneServer.c}.
\begin{figure}[!htbp]
\footnotesize \centering
\end{minipage}
\normalsize
\caption{Sezione principale del codice del server di \textit{fortunes}
- basato sulle fifo.}
+ basato sulle \textit{fifo}.}
\label{fig:ipc_fifo_server}
\end{figure}
funzione (non riportata) che ne stampa le modalità d'uso. Dopo di che
installa (\texttt{\small 13--15}) la funzione che gestisce i segnali di
interruzione (anche questa non è riportata in fig.~\ref{fig:ipc_fifo_server})
-che si limita a rimuovere dal filesystem la fifo usata dal server per
+che si limita a rimuovere dal filesystem la \textit{fifo} usata dal server per
comunicare.
Terminata l'inizializzazione (\texttt{\small 16}) si effettua la chiamata alla
attinente allo scopo dell'esempio.
Il passo successivo (\texttt{\small 17--22}) è quello di creare con
-\func{mkfifo} la fifo nota sulla quale il server ascolterà le richieste,
-qualora si riscontri un errore il server uscirà (escludendo ovviamente il caso
-in cui la funzione \func{mkfifo} fallisce per la precedente esistenza della
-fifo).
-
-Una volta che si è certi che la fifo di ascolto esiste la procedura di
-inizializzazione è completata. A questo punto si può chiamare (\texttt{\small
- 23}) la funzione \func{daemon} per far proseguire l'esecuzione del programma
-in background come demone. Si può quindi procedere (\texttt{\small 24--33})
-alla apertura della fifo: si noti che questo viene fatto due volte, prima in
-lettura e poi in scrittura, per evitare di dover gestire all'interno del ciclo
-principale il caso in cui il server è in ascolto ma non ci sono client che
-effettuano richieste. Si ricordi infatti che quando una fifo è aperta solo
-dal capo in lettura, l'esecuzione di \func{read} ritorna con zero byte (si ha
-cioè una condizione di end-of-file).
+\func{mkfifo} la \textit{fifo} nota sulla quale il server ascolterà le
+richieste, qualora si riscontri un errore il server uscirà (escludendo
+ovviamente il caso in cui la funzione \func{mkfifo} fallisce per la precedente
+esistenza della \textit{fifo}).
+
+Una volta che si è certi che la \textit{fifo} di ascolto esiste la procedura
+di inizializzazione è completata. A questo punto si può chiamare
+(\texttt{\small 23}) la funzione \func{daemon} per far proseguire l'esecuzione
+del programma in background come demone. Si può quindi procedere
+(\texttt{\small 24--33}) alla apertura della \textit{fifo}: si noti che questo
+viene fatto due volte, prima in lettura e poi in scrittura, per evitare di
+dover gestire all'interno del ciclo principale il caso in cui il server è in
+ascolto ma non ci sono client che effettuano richieste. Si ricordi infatti
+che quando una \textit{fifo} è aperta solo dal capo in lettura, l'esecuzione di
+\func{read} ritorna con zero byte (si ha cioè una condizione di end-of-file).
Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque
-client non apre a sua volta la fifo nota in scrittura per effettuare la sua
+client non apre a sua volta la \textit{fifo} nota in scrittura per effettuare la sua
richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta
-ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo.
-A questo punto il server resta (se non ci sono altri client che stanno
-effettuando richieste) con la fifo chiusa sul lato in lettura, ed in questo
-stato la funzione \func{read} non si bloccherà in attesa di input, ma
-ritornerà in continuazione, restituendo un end-of-file.\footnote{si è usata
- questa tecnica per compatibilità, Linux infatti supporta l'apertura delle
- fifo in lettura/scrittura, per cui si sarebbe potuto effettuare una singola
- apertura con \const{O\_RDWR}, la doppia apertura comunque ha il vantaggio
- che non si può scrivere per errore sul capo aperto in sola lettura.}
+ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la
+\textit{fifo}. A questo punto il server resta (se non ci sono altri client
+che stanno effettuando richieste) con la \textit{fifo} chiusa sul lato in
+lettura, ed in questo stato la funzione \func{read} non si bloccherà in attesa
+di dati in ingresso, ma ritornerà in continuazione, restituendo una condizione
+di \textit{end-of-file}.
+
+Si è usata questa tecnica per compatibilità, Linux infatti supporta l'apertura
+delle \textit{fifo} in lettura/scrittura, per cui si sarebbe potuto effettuare
+una singola apertura con \const{O\_RDWR}; la doppia apertura comunque ha il
+vantaggio che non si può scrivere per errore sul capo aperto in sola lettura.
Per questo motivo, dopo aver eseguito l'apertura in lettura (\texttt{\small
24--28}),\footnote{di solito si effettua l'apertura del capo in lettura di
- una fifo in modalità non bloccante, per evitare il rischio di uno stallo: se
- infatti nessuno apre la fifo in scrittura il processo non ritornerà mai
- dalla \func{open}. Nel nostro caso questo rischio non esiste, mentre è
- necessario potersi bloccare in lettura in attesa di una richiesta.} si
-esegue una seconda apertura in scrittura (\texttt{\small 29--32}), scartando
-il relativo file descriptor, che non sarà mai usato, in questo modo però la
-fifo resta comunque aperta anche in scrittura, cosicché le successive chiamate
-a \func{read} possono bloccarsi.
+ una \textit{fifo} in modalità non bloccante, per evitare il rischio di uno
+ stallo: se infatti nessuno apre la \textit{fifo} in scrittura il processo
+ non ritornerà mai dalla \func{open}. Nel nostro caso questo rischio non
+ esiste, mentre è necessario potersi bloccare in lettura in attesa di una
+ richiesta.} si esegue una seconda apertura in scrittura (\texttt{\small
+ 29--32}), scartando il relativo file descriptor, che non sarà mai usato, in
+questo modo però la \textit{fifo} resta comunque aperta anche in scrittura,
+cosicché le successive chiamate a \func{read} possono bloccarsi.
A questo punto si può entrare nel ciclo principale del programma che fornisce
le risposte ai client (\texttt{\small 34--50}); questo viene eseguito
indefinitamente (l'uscita del server viene effettuata inviando un segnale, in
-modo da passare attraverso la funzione di chiusura che cancella la fifo).
+modo da passare attraverso la funzione di chiusura che cancella la
+\textit{fifo}).
Il server è progettato per accettare come richieste dai client delle stringhe
-che contengono il nome della fifo sulla quale deve essere inviata la risposta.
-Per cui prima (\texttt{\small 35--39}) si esegue la lettura dalla stringa di
-richiesta dalla fifo nota (che a questo punto si bloccherà tutte le volte che
-non ci sono richieste). Dopo di che, una volta terminata la stringa
-(\texttt{\small 40}) e selezionato (\texttt{\small 41}) un numero casuale per
-ricavare la frase da inviare, si procederà (\texttt{\small 42--46})
-all'apertura della fifo per la risposta, che poi \texttt{\small 47--48}) vi
-sarà scritta. Infine (\texttt{\small 49}) si chiude la fifo di risposta che
-non serve più.
+che contengono il nome della \textit{fifo} sulla quale deve essere inviata la
+risposta. Per cui prima (\texttt{\small 35--39}) si esegue la lettura dalla
+stringa di richiesta dalla \textit{fifo} nota (che a questo punto si bloccherà
+tutte le volte che non ci sono richieste). Dopo di che, una volta terminata la
+stringa (\texttt{\small 40}) e selezionato (\texttt{\small 41}) un numero
+casuale per ricavare la frase da inviare, si procederà (\texttt{\small
+ 42--46}) all'apertura della \textit{fifo} per la risposta, che poi
+\texttt{\small 47--48}) vi sarà scritta. Infine (\texttt{\small 49}) si chiude
+la \textit{fifo} di risposta che non serve più.
Il codice del client è invece riportato in fig.~\ref{fig:ipc_fifo_client},
anche in questo caso si è omessa la gestione delle opzioni e la funzione che
\end{minipage}
\normalsize
\caption{Sezione principale del codice del client di \textit{fortunes}
- basato sulle fifo.}
+ basato sulle \textit{fifo}.}
\label{fig:ipc_fifo_client}
\end{figure}
-La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà
-essere utilizzata per ricevere la risposta dal server. Si usa il \ids{PID}
-del processo per essere sicuri di avere un nome univoco; dopo di che
+La prima istruzione (\texttt{\small 12}) compone il nome della \textit{fifo}
+che dovrà essere utilizzata per ricevere la risposta dal server. Si usa il
+\ids{PID} del processo per essere sicuri di avere un nome univoco; dopo di che
(\texttt{\small 13-18}) si procede alla creazione del relativo file, uscendo
in caso di errore (a meno che il file non sia già presente sul filesystem).
A questo punto il client può effettuare l'interrogazione del server, per
-questo prima si apre la fifo nota (\texttt{\small 19--23}), e poi ci si scrive
-(\texttt{\small 24}) la stringa composta in precedenza, che contiene il nome
-della fifo da utilizzare per la risposta. Infine si richiude la fifo del
-server che a questo punto non serve più (\texttt{\small 25}).
+questo prima si apre la \textit{fifo} nota (\texttt{\small 19--23}), e poi ci
+si scrive (\texttt{\small 24}) la stringa composta in precedenza, che contiene
+il nome della \textit{fifo} da utilizzare per la risposta. Infine si richiude
+la \textit{fifo} del server che a questo punto non serve più (\texttt{\small
+ 25}).
Inoltrata la richiesta si può passare alla lettura della risposta; anzitutto
-si apre (\texttt{\small 26--30}) la fifo appena creata, da cui si deve
-riceverla, dopo di che si effettua una lettura (\texttt{\small 31})
+si apre (\texttt{\small 26--30}) la \textit{fifo} appena creata, da cui si
+deve riceverla, dopo di che si effettua una lettura (\texttt{\small 31})
nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate
dal server siano sempre di dimensioni inferiori a \const{PIPE\_BUF},
tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
(\texttt{\small 32}) a video la risposta, si chiude (\texttt{\small 33}) la
-fifo e si cancella (\texttt{\small 34}) il relativo file.
-Si noti come la fifo per la risposta sia stata aperta solo dopo aver inviato
+\textit{fifo} e si cancella (\texttt{\small 34}) il relativo file. Si noti
+come la \textit{fifo} per la risposta sia stata aperta solo dopo aver inviato
la richiesta, se non si fosse fatto così si avrebbe avuto uno stallo, in
quanto senza la richiesta, il server non avrebbe potuto aprirne il capo in
scrittura e l'apertura si sarebbe bloccata indefinitamente.
vengono creati sia i programmi che la libreria), il comando da dare sarà
\code{export LD\_LIBRARY\_PATH=./}; a questo punto potremo lanciare il server,
facendogli leggere una decina di frasi, con:
-\begin{Verbatim}
-[piccardi@gont sources]$ ./fortuned -n10
-\end{Verbatim}
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./fortuned -n10}
+\end{Console}
%$
Avendo usato \func{daemon} per eseguire il server in background il comando
ritornerà immediatamente, ma potremo verificare con \cmd{ps} che in effetti il
programma resta un esecuzione in background, e senza avere associato un
terminale di controllo (si ricordi quanto detto in sez.~\ref{sec:sess_daemon}):
-\begin{Verbatim}
-[piccardi@gont sources]$ ps aux
+\begin{Console}
+[piccardi@gont sources]$ \textbf{ps aux}
...
piccardi 27489 0.0 0.0 1204 356 ? S 01:06 0:00 ./fortuned -n10
piccardi 27492 3.0 0.1 2492 764 pts/2 R 01:08 0:00 ps aux
-\end{Verbatim}
+\end{Console}
%$
-e si potrà verificare anche che in \file{/tmp} è stata creata la fifo di
-ascolto \file{fortune.fifo}. A questo punto potremo interrogare il server con
-il programma client; otterremo così:
-\begin{Verbatim}
-[piccardi@gont sources]$ ./fortune
+e si potrà verificare anche che in \file{/tmp} è stata creata la \textit{fifo}
+di ascolto \file{fortune.fifo}. A questo punto potremo interrogare il server
+con il programma client; otterremo così:
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./fortune}
Linux ext2fs has been stable for a long time, now it's time to break it
-- Linuxkongreß '95 in Berlin
-[piccardi@gont sources]$ ./fortune
+[piccardi@gont sources]$ \textbf{./fortune}
Let's call it an accidental feature.
--Larry Wall
-[piccardi@gont sources]$ ./fortune
+[piccardi@gont sources]$ \textbf{./fortune}
......... Escape the 'Gates' of Hell
`:::' ....... ......
::: * `::. ::'
[piccardi@gont sources]$ ./fortune
Linux ext2fs has been stable for a long time, now it's time to break it
-- Linuxkongreß '95 in Berlin
-\end{Verbatim}
+\end{Console}
%$
e ripetendo varie volte il comando otterremo, in ordine casuale, le dieci
frasi tenute in memoria dal server.
-Infine per chiudere il server basterà inviare un segnale di terminazione con
-\code{killall fortuned} e potremo verificare che il gestore del segnale ha
-anche correttamente cancellato la fifo di ascolto da \file{/tmp}.
+Infine per chiudere il server basterà inviargli un segnale di terminazione (ad
+esempio con \cmd{killall fortuned}) e potremo verificare che il gestore del
+segnale ha anche correttamente cancellato la \textit{fifo} di ascolto da
+\file{/tmp}.
Benché il nostro sistema client-server funzioni, la sua struttura è piuttosto
complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
che esamina questa architettura in \cite{APUE}, 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, di come sia necessario
- intercettare \signal{SIGPIPE} dato che un client può terminare dopo aver
- fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel
- nostro esempio non è stata fatta).}; 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 socket (che
-tratteremo in dettaglio a partire da cap.~\ref{cha:socket_intro}) o ricorrendo
-a meccanismi di comunicazione diversi, come quelli che esamineremo in seguito.
+ far restare le \textit{fifo} temporanee sul filesystem, di come sia
+ necessario intercettare \signal{SIGPIPE} dato che un client può terminare
+ dopo aver fatto una richiesta, ma prima che la risposta sia inviata (cosa
+ che nel nostro esempio non è stata fatta).}; in generale infatti
+l'interfaccia delle \textit{fifo} non è adatta a risolvere questo tipo di
+problemi, che possono essere affrontati in maniera più semplice ed efficace o
+usando i socket (che tratteremo in dettaglio a partire da
+cap.~\ref{cha:socket_intro}) o ricorrendo a meccanismi di comunicazione
+diversi, come quelli che esamineremo in seguito.
\subsection{La funzione \func{socketpair}}
\label{sec:ipc_socketpair}
-Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il
-problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
-\textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo l'argomento
-dei socket in cap.~\ref{cha:socket_intro},\footnote{si tratta comunque di
- oggetti di comunicazione che, come le pipe, sono utilizzati attraverso dei
- file descriptor.} nell'ambito dell'interfaccia generale che essi forniscono
-per la programmazione di rete; e vedremo anche
-(in~sez.~\ref{sec:sock_sa_local}) come si possono definire dei file speciali
-(di tipo socket, analoghi a quello associati alle fifo) cui si accede però
-attraverso quella medesima interfaccia; vale però la pena esaminare qui una
-modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
- stata introdotta in BSD4.4, ma è supportata in genere da qualunque sistema
- che fornisca l'interfaccia dei socket.} che li rende sostanzialmente
-identici ad una pipe bidirezionale.
-
-La funzione \funcd{socketpair} infatti consente di creare una coppia di file
-descriptor connessi fra di loro (tramite un socket, appunto), senza dover
-ricorrere ad un file speciale sul filesystem, i descrittori sono del tutto
-analoghi a quelli che si avrebbero con una chiamata a \func{pipe}, con la sola
-differenza è che in questo caso il flusso dei dati può essere effettuato in
-entrambe le direzioni. Il prototipo della funzione è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/socket.h}
-
- \funcdecl{int socketpair(int domain, int type, int protocol, int sv[2])}
-
- Crea una coppia di socket connessi fra loro.
-
- \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+Un meccanismo di comunicazione molto simile alle \textit{pipe}, ma che non
+presenta il problema della unidirezionalità del flusso dei dati, è quello dei
+cosiddetti \textsl{socket locali} (o \textit{Unix domain socket}). Tratteremo
+in generale i socket in cap.~\ref{cha:socket_intro}, nell'ambito
+dell'interfaccia che essi forniscono per la programmazione di rete, e vedremo
+anche (in~sez.~\ref{sec:sock_sa_local}) come si possono utilizzare i
+\index{file!speciali} file speciali di tipo socket, analoghi a quelli
+associati alle \textit{fifo} (si rammenti sez.~\ref{sec:file_file_types}) cui
+si accede però attraverso quella medesima interfaccia; vale però la pena
+esaminare qui una modalità di uso dei socket locali che li rende
+sostanzialmente identici ad una \textit{pipe} bidirezionale.
+
+La funzione di sistema \funcd{socketpair}, introdotta da BSD ma supportata in
+genere da qualunque sistema che fornisca l'interfaccia dei socket ed inclusa
+in POSIX.1-2001, consente infatti di creare una coppia di file descriptor
+connessi fra loro (tramite un socket, appunto) senza dover ricorrere ad un
+\index{file!speciali} file speciale sul filesystem. I descrittori sono del
+tutto analoghi a quelli che si avrebbero con una chiamata a \func{pipe}, con
+la sola differenza è che in questo caso il flusso dei dati può essere
+effettuato in entrambe le direzioni. Il prototipo della funzione è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/socket.h}
+\fdecl{int socketpair(int domain, int type, int protocol, int sv[2])}
+\fdesc{Crea una coppia di socket connessi fra loro.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EAFNOSUPPORT}] i socket locali non sono supportati.
- \item[\errcode{EPROTONOSUPPORT}] il protocollo specificato non è supportato.
\item[\errcode{EOPNOTSUPP}] il protocollo specificato non supporta la
creazione di coppie di socket.
+ \item[\errcode{EPROTONOSUPPORT}] il protocollo specificato non è supportato.
\end{errlist}
- ed inoltre \errval{EMFILE}, \errval{EFAULT}.
-}
-\end{functions}
+ ed inoltre \errval{EFAULT}, \errval{EMFILE} e \errval{ENFILE} nel loro
+ significato generico.}
+\end{funcproto}
La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di
loro: quello che si scrive su uno di essi sarà ripresentato in input
sez.~\ref{sec:sock_creation}) che è quella che fornisce il substrato per
connettere i due descrittori, ma in questo caso i soli valori validi che
possono essere specificati sono rispettivamente \const{AF\_UNIX},
-\const{SOCK\_STREAM} e \val{0}.
+\const{SOCK\_STREAM} e \val{0}.
+
+A partire dal kernel 2.6.27 la funzione supporta anche l'uso dei flag
+\const{SOCK\_NONBLOCK} e \const{SOCK\_CLOEXEC} (trattati in
+sez.~\ref{sec:sock_type}) nell'indicazione del tipo di socket, con effetto
+identico agli analoghi \const{O\_CLOEXEC} e \const{O\_NONBLOCK} di una
+\func{open} (vedi tab.~\ref{tab:open_operation_flag}).
L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe}
può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei socket
\section{L'intercomunicazione fra processi di System V}
\label{sec:ipc_sysv}
-Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
-limite fondamentale che il meccanismo di comunicazione che forniscono è
-rigidamente sequenziale: una situazione in cui un processo scrive qualcosa che
-molti altri devono poter leggere non può essere implementata con una pipe.
+Benché le \textit{pipe} e le \textit{fifo} siano ancora ampiamente usate, esse
+scontano il limite fondamentale che il meccanismo di comunicazione che
+forniscono è rigidamente sequenziale: una situazione in cui un processo scrive
+qualcosa che molti altri devono poter leggere non può essere implementata con
+una \textit{pipe}.
Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
oggetti per la comunicazione fra processi ed una nuova interfaccia di
-programmazione, che fossero in grado di garantire una maggiore flessibilità.
-In questa sezione esamineremo come Linux supporta quello che viene chiamato il
-\textsl{Sistema di comunicazione fra processi} di System V, cui da qui in
-avanti faremo riferimento come \textit{SysV IPC} (dove IPC è la sigla di
-\textit{Inter-Process Comunication}).
+programmazione, poi inclusa anche in POSIX.1-2001, che fossero in grado di
+garantire una maggiore flessibilità. In questa sezione esamineremo come Linux
+supporta quello che viene chiamato il \textsl{Sistema di comunicazione fra
+ processi} di System V, cui da qui in avanti faremo riferimento come
+\textit{SysV-IPC} (dove IPC è la sigla di \textit{Inter-Process
+ Comunication}).
\subsection{Considerazioni generali}
\label{sec:ipc_sysv_generic}
-La principale caratteristica del \textit{SysV IPC} è quella di essere basato
+La principale caratteristica del \textit{SysV-IPC} è quella di essere basato
su oggetti permanenti che risiedono nel kernel. Questi, a differenza di quanto
avviene per i file descriptor, non mantengono un contatore dei riferimenti, e
-non vengono cancellati dal sistema una volta che non sono più in uso.
-
-Questo comporta due problemi: il primo è che, al contrario di quanto avviene
-per pipe e fifo, la memoria allocata per questi oggetti non viene rilasciata
-automaticamente quando non c'è più nessuno che li utilizzi, ed essi devono
-essere cancellati esplicitamente, se non si vuole che restino attivi fino al
-riavvio del sistema. Il secondo problema è che, dato che non c'è, come per i
-file, un contatore del numero di riferimenti che ne indichi l'essere in uso,
-essi possono essere cancellati anche se ci sono dei processi che li stanno
-utilizzando, con tutte le conseguenze (negative) del caso.
-
-Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV
- IPC} vengono creati direttamente dal kernel, e sono accessibili solo
-specificando il relativo \textsl{identificatore}. Questo è un numero
+non vengono cancellati dal sistema una volta che non sono più in uso. Questo
+comporta due problemi: il primo è che, al contrario di quanto avviene per
+\textit{pipe} e \textit{fifo}, la memoria allocata per questi oggetti non
+viene rilasciata automaticamente quando non c'è più nessuno che li utilizzi ed
+essi devono essere cancellati esplicitamente, se non si vuole che restino
+attivi fino al riavvio del sistema. Il secondo problema è, dato che non c'è
+come per i file un contatore del numero di riferimenti che ne indichi l'essere
+in uso, che essi possono essere cancellati anche se ci sono dei processi che
+li stanno utilizzando, con tutte le conseguenze (ovviamente assai sgradevoli)
+del caso.
+
+Un'ulteriore caratteristica negativa è che gli oggetti usati nel
+\textit{SysV-IPC} vengono creati direttamente dal kernel, e sono accessibili
+solo specificando il relativo \textsl{identificatore}. Questo è un numero
progressivo (un po' come il \ids{PID} dei processi) che il kernel assegna a
ciascuno di essi quanto vengono creati (sul procedimento di assegnazione
-torneremo in sez.~\ref{sec:ipc_sysv_id_use}). L'identificatore viene restituito
-dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha
-eseguite. Dato che l'identificatore viene assegnato dinamicamente dal kernel
-non è possibile prevedere quale sarà, né utilizzare un qualche valore statico,
-si pone perciò il problema di come processi diversi possono accedere allo
-stesso oggetto.
+torneremo in sez.~\ref{sec:ipc_sysv_id_use}). L'identificatore viene
+restituito dalle funzioni che creano l'oggetto, ed è quindi locale al processo
+che le ha eseguite. Dato che l'identificatore viene assegnato dinamicamente
+dal kernel non è possibile prevedere quale sarà, né utilizzare un qualche
+valore statico, si pone perciò il problema di come processi diversi possono
+accedere allo stesso oggetto.
Per risolvere il problema nella struttura \struct{ipc\_perm} che il kernel
associa a ciascun oggetto, viene mantenuto anche un campo apposito che
tramite la quale è possibile ricavare l'identificatore.\footnote{in sostanza
si sposta il problema dell'accesso dalla classificazione in base
all'identificatore alla classificazione in base alla chiave, una delle tante
- complicazioni inutili presenti nel \textit{SysV IPC}.} Oltre la chiave, la
+ complicazioni inutili presenti nel \textit{SysV-IPC}.} Oltre la chiave, la
struttura, la cui definizione è riportata in fig.~\ref{fig:ipc_ipc_perm},
mantiene varie proprietà ed informazioni associate all'oggetto.
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.80\textwidth}
\includestruct{listati/ipc_perm.h}
\end{minipage}
\normalsize
chiavi in maniera univoca l'interfaccia mette a disposizione una funzione
apposita, \funcd{ftok}, che permette di ottenere una chiave specificando il
nome di un file ed un numero di versione; il suo prototipo è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/ipc.h}
-
- \funcdecl{key\_t ftok(const char *pathname, int proj\_id)}
-
- Restituisce una chiave per identificare un oggetto del \textit{SysV IPC}.
-
- \bodydesc{La funzione restituisce la chiave in caso di successo e -1
- altrimenti, nel qual caso \var{errno} sarà uno dei possibili codici di
- errore di \func{stat}.}
-\end{functions}
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/ipc.h}
+\fdecl{key\_t ftok(const char *pathname, int proj\_id)}
+\fdesc{Restituisce una chiave per identificare un oggetto del \textit{SysV
+ IPC}.}}
+
+{La funzione ritorna la chiave in caso di successo e $-1$ per un errore, nel
+ qual caso \var{errno} assumerà uno dei possibili codici di errore di
+ \func{stat}.}
+\end{funcproto}
La funzione determina un valore della chiave sulla base di \param{pathname},
che deve specificare il \textit{pathname} di un file effettivamente esistente
e di un numero di progetto \param{proj\_id)}, che di norma viene specificato
come carattere, dato che ne vengono utilizzati solo gli 8 bit meno
-significativi.\footnote{nelle libc4 e libc5, come avviene in SunOS,
- l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, la \acr{glibc}
- usa il prototipo specificato da XPG4, ma vengono lo stesso utilizzati gli 8
- bit meno significativi.}
+significativi. Nelle \acr{libc4} e \acr{libc5}, come avviene in SunOS,
+l'argomento \param{proj\_id} è dichiarato tipo \ctyp{char}, la \acr{glibc} usa
+il prototipo specificato da XPG4, ma vengono lo stesso utilizzati gli 8 bit
+meno significativi.
Il problema è che anche così non c'è la sicurezza che il valore della chiave
sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
Questo è, insieme al fatto che gli oggetti sono permanenti e non mantengono un
contatore di riferimenti per la cancellazione automatica, il principale
-problema del \textit{SysV IPC}. Non esiste infatti una modalità chiara per
+problema del \textit{SysV-IPC}. Non esiste infatti una modalità chiara per
identificare un oggetto, come sarebbe stato se lo si fosse associato ad in
-file, e tutta l'interfaccia è inutilmente complessa. Per questo ne è stata
-effettuata una revisione completa nello standard POSIX.1b, che tratteremo in
-sez.~\ref{sec:ipc_posix}.
+file, e tutta l'interfaccia è inutilmente complessa. Per questo se ne
+sconsiglia assolutamente l'uso nei nuovi programmi, considerato che è ormai
+disponibile una revisione completa dei meccamismi di IPC fatta secondo quanto
+indicato dallo standard POSIX.1b, che presenta una realizzazione più sicura ed
+una interfaccia più semplice, che tratteremo in sez.~\ref{sec:ipc_posix}.
\subsection{Il controllo di accesso}
\label{sec:ipc_sysv_access_control}
-Oltre alle chiavi, abbiamo visto che ad ogni oggetto sono associate in
-\struct{ipc\_perm} ulteriori informazioni, come gli identificatori del creatore
-(nei campi \var{cuid} e \var{cgid}) e del proprietario (nei campi \var{uid} e
-\var{gid}) dello stesso, e un insieme di permessi (nel campo \var{mode}). In
-questo modo è possibile definire un controllo di accesso sugli oggetti di IPC,
-simile a quello che si ha per i file (vedi sez.~\ref{sec:file_perm_overview}).
+Oltre alle chiavi, abbiamo visto in fig.~\ref{fig:ipc_ipc_perm} che ad ogni
+oggetto sono associate in \struct{ipc\_perm} ulteriori informazioni, come gli
+identificatori del creatore (nei campi \var{cuid} e \var{cgid}) e del
+proprietario (nei campi \var{uid} e \var{gid}) dello stesso, e un insieme di
+permessi (nel campo \var{mode}). In questo modo è possibile definire un
+controllo di accesso sugli oggetti di IPC, simile a quello che si ha per i
+file (vedi sez.~\ref{sec:file_perm_overview}).
Benché questo controllo di accesso sia molto simile a quello dei file, restano
delle importanti differenze. La prima è che il permesso di esecuzione non
permessi di lettura e scrittura (nel caso dei semafori poi quest'ultimo è più
propriamente un permesso di modifica). I valori di \var{mode} sono gli stessi
ed hanno lo stesso significato di quelli riportati in
-tab.~\ref{tab:file_mode_flags}\footnote{se però si vogliono usare le costanti
- simboliche ivi definite occorrerà includere il file \headfile{sys/stat.h},
- alcuni sistemi definiscono le costanti \const{MSG\_R} (\texttt{0400}) e
- \const{MSG\_W} (\texttt{0200}) per indicare i permessi base di lettura e
- scrittura per il proprietario, da utilizzare, con gli opportuni shift, pure
- per il gruppo e gli altri, in Linux, visto la loro scarsa utilità, queste
- costanti non sono definite.} e come per i file definiscono gli accessi per
-il proprietario, il suo gruppo e tutti gli altri.
+tab.~\ref{tab:file_mode_flags} e come per i file definiscono gli accessi per
+il proprietario, il suo gruppo e tutti gli altri.
+
+Se però si vogliono usare le costanti simboliche di
+tab.~\ref{tab:file_mode_flags} occorrerà includere anche il file
+\headfile{sys/stat.h}; alcuni sistemi definiscono le costanti \const{MSG\_R}
+(il valore ottale \texttt{0400}) e \const{MSG\_W} (il valore ottale
+\texttt{0200}) per indicare i permessi base di lettura e scrittura per il
+proprietario, da utilizzare, con gli opportuni shift, pure per il gruppo e gli
+altri. In Linux, visto la loro scarsa utilità, queste costanti non sono
+definite.
Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di
\struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono impostati
direttamente (in lettura o scrittura) all'oggetto. In tal caso lo schema dei
controlli è simile a quello dei file, ed avviene secondo questa sequenza:
\begin{itemize*}
-\item se il processo ha i privilegi di amministratore l'accesso è sempre
- consentito.
+\item se il processo ha i privilegi di amministratore (più precisamente la
+ capacità \itindex{capability} \const{CAP\_IPC\_OWNER}) l'accesso è sempre
+ consentito.
\item se l'\ids{UID} effettivo del processo corrisponde o al valore del campo
\var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
in \var{mode} è appropriato\footnote{per appropriato si intende che è
assumere tutti i valori possibili, rendendo molto più lungo il periodo in cui
un identificatore può venire riutilizzato.
-Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino
- al kernel 2.2.x questi valori, definiti dalle costanti \const{MSGMNI},
- \const{SEMMNI} e \const{SHMMNI}, potevano essere cambiati (come tutti gli
- altri limiti relativi al \textit{SysV IPC}) solo con una ricompilazione del
- kernel, andando a modificarne la definizione nei relativi header file. A
- partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
- scrivendo sui file \sysctlrelfile{kernel}{shmmni},
- \sysctlrelfile{kernel}{msgmni} e \sysctlrelfile{kernel}{sem}
- di \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.} e per ciascuno di
-essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
-incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
-l'oggetto viene creato usando uno spazio che era già stato utilizzato in
-precedenza per restituire l'identificatore al numero di oggetti presenti viene
-sommato il valore di \var{seq} moltiplicato per il numero massimo di oggetti
-di quel tipo,\footnote{questo vale fino ai kernel della serie 2.2.x, dalla
- serie 2.4.x viene usato lo stesso fattore per tutti gli oggetti, esso è dato
- dalla costante \const{IPCMNI}, definita in \file{include/linux/ipc.h}, che
- indica il limite massimo per il numero di tutti oggetti di IPC, ed il cui
- valore è 32768.} si evita così il riutilizzo degli stessi numeri, e si fa
-sì che l'identificatore assuma tutti i valori possibili.
+Il sistema dispone sempre di un numero fisso di oggetti di IPC, fino al kernel
+2.2.x questi erano definiti dalle costanti \const{MSGMNI}, \const{SEMMNI} e
+\const{SHMMNI}, e potevano essere cambiati (come tutti gli altri limiti
+relativi al \textit{SysV-IPC}) solo con una ricompilazione del kernel. A
+partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
+scrivendo sui file \sysctlrelfile{kernel}{shmmni},
+\sysctlrelfile{kernel}{msgmni} e \sysctlrelfile{kernel}{sem} di
+\file{/proc/sys/kernel} o con l'uso di \func{sysctl}.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/IPCTestId.c}
\label{fig:ipc_sysv_idtest}
\end{figure}
+Per ciascun tipo di oggetto di IPC viene mantenuto in \var{seq} un numero di
+sequenza progressivo che viene incrementato di uno ogni volta che l'oggetto
+viene cancellato. Quando l'oggetto viene creato usando uno spazio che era già
+stato utilizzato in precedenza, per restituire il nuovo identificatore al
+numero di oggetti presenti viene sommato il valore corrente del campo
+\var{seq}, moltiplicato per il numero massimo di oggetti di quel tipo.
+
+Questo in realtà è quanto avveniva fino ai kernel della serie 2.2, dalla serie
+2.4 viene usato lo stesso fattore di moltiplicazione per qualunque tipo di
+oggetto, utilizzando il valore dalla costante \const{IPCMNI} (definita in
+\file{include/linux/ipc.h}), che indica il limite massimo complessivo per il
+numero di tutti gli oggetti presenti nel \textit{SysV-IPC}, ed il cui default
+è 32768. Si evita così il riutilizzo degli stessi numeri, e si fa sì che
+l'identificatore assuma tutti i valori possibili.
+
In fig.~\ref{fig:ipc_sysv_idtest} è riportato il codice di un semplice
-programma di test che si limita a creare un oggetto (specificato a riga di
-comando), stamparne il numero di identificatore e cancellarlo per un numero
-specificato di volte. Al solito non si è riportato il codice della gestione
-delle opzioni a riga di comando, che permette di specificare quante volte
-effettuare il ciclo \var{n}, e su quale tipo di oggetto eseguirlo.
-
-La figura non riporta il codice di selezione delle opzioni, che permette di
-inizializzare i valori delle variabili \var{type} al tipo di oggetto voluto, e
-\var{n} al numero di volte che si vuole effettuare il ciclo di creazione,
-stampa, cancellazione. I valori di default sono per l'uso delle code di
-messaggi e un ciclo di 5 volte. Se si lancia il comando si otterrà qualcosa
-del tipo:
-\begin{Verbatim}
-piccardi@gont sources]$ ./ipctestid
+programma di test che si limita a creare un oggetto di ICP (specificato con
+una opzione a riga di comando), stamparne il numero di identificatore, e
+cancellarlo, il tutto un numero di volte specificato tramite una seconda
+opzione. La figura non riporta il codice di selezione delle opzioni, che
+permette di inizializzare i valori delle variabili \var{type} al tipo di
+oggetto voluto, e \var{n} al numero di volte che si vuole effettuare il ciclo
+di creazione, stampa, cancellazione.
+
+I valori di default sono per l'uso delle code di messaggi e per 5 ripetizioni
+del ciclo. Per questo motivo se non si utilizzano opzioni verrà eseguito per
+cinque volte il ciclo (\texttt{\small 7-11}), in cui si crea una coda di
+messaggi (\texttt{\small 8}), se ne stampa l'identificativo (\texttt{\small
+ 9}) e la si rimuove (\texttt{\small 10}). Non stiamo ad approfondire adesso
+il significato delle funzioni utilizzate, che verranno esaminate nelle
+prossime sezioni.
+
+Quello che ci interessa infatti è verificare l'allocazione degli
+identificativi associati agli oggetti; lanciando il comando si otterrà
+pertanto qualcosa del tipo:
+\begin{Console}
+piccardi@gont sources]$ \textbf{./ipctestid}
Identifier Value 0
Identifier Value 32768
Identifier Value 65536
Identifier Value 98304
-Identifier Value 131072
-\end{Verbatim}
+Identifier Value 131072
+\end{Console}
%$
-il che ci mostra che abbiamo un kernel della serie 2.4.x nel quale non avevamo
-ancora usato nessuna coda di messaggi. Se ripetiamo il comando otterremo
-ancora:
-\begin{Verbatim}
-[piccardi@gont sources]$ ./ipctestid
-Identifier Value 163840
+il che ci mostra che stiamo lavorando con un kernel posteriore alla serie 2.2
+nel quale non avevamo ancora usato nessuna coda di messaggi (il valore nullo
+del primo identificativo indica che il campo \var{seq} era zero). Ripetendo il
+comando, e quindi eseguendolo in un processo diverso, in cui non può esistere
+nessuna traccia di quanto avvenuto in precedenza, otterremo come nuovo
+risultato:
+\begin{Console}
+[piccardi@gont sources]$ \textbf{./ipctestid}
+Identifier Value 163840
Identifier Value 196608
Identifier Value 229376
Identifier Value 262144
Identifier Value 294912
-\end{Verbatim}
+\end{Console}
%$
-che ci mostra come il valore di \var{seq} sia in effetti una quantità
-mantenuta staticamente all'interno del sistema.
+in cui la sequenza numerica prosegue, cosa che ci mostra come il valore di
+\var{seq} continui ad essere incrementato e costituisca in effetti una
+quantità mantenuta all'interno del sistema ed indipendente dai processi.
\subsection{Code di messaggi}
\label{sec:ipc_sysv_mq}
-Il primo oggetto introdotto dal \textit{SysV IPC} è quello delle code di
-messaggi. Le code di messaggi sono oggetti analoghi alle pipe o alle fifo,
-anche se la loro struttura è diversa, ed il loro scopo principale è appunto
-quello di permettere a processi diversi di scambiarsi dei dati.
+Il primo oggetto introdotto dal \textit{SysV-IPC} è quello delle code di
+messaggi. Le code di messaggi sono oggetti analoghi alle \textit{pipe} o alle
+\textit{fifo} ed il loro scopo principale è quello di fornire a processi
+diversi un meccanismo con cui scambiarsi dei dati in forma di messaggio. Dato
+che le \textit{pipe} e le \textit{fifo} costituiscono una ottima alternativa,
+ed in genere sono molto più semplici da usare, le code di messaggi sono il
+meno utilizzato degli oggetti introdotti dal \textit{SysV-IPC}.
+
+La funzione di sistema che permette di ottenere l'identificativo di una coda
+di messaggi esistente per potervi accedere, oppure di creare una nuova coda
+qualora quella indicata non esista ancora, è \funcd{msgget}, e il suo
+prototipo è:
-La funzione che permette di richiedere al sistema l'identificatore di una coda
-di messaggi esistente (o di crearne una se questa non esiste) è
-\funcd{msgget}; il suo prototipo è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/ipc.h}
- \headdecl{sys/msg.h}
-
- \funcdecl{int msgget(key\_t key, int flag)}
-
- Restituisce l'identificatore di una coda di messaggi.
-
- \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
- in caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/ipc.h}
+\fhead{sys/msg.h}
+\fdecl{int msgget(key\_t key, int flag)}
+\fdesc{Ottiene o crea una coda di messaggi.}
+}
+
+{La funzione ritorna l'identificatore (un intero positivo) in caso di successo
+ e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EACCES}] il processo chiamante non ha i privilegi per accedere
- alla coda richiesta.
+ \item[\errcode{EACCES}] il processo chiamante non ha i privilegi per
+ accedere alla coda richiesta.
\item[\errcode{EEXIST}] si è richiesta la creazione di una coda che già
- esiste, ma erano specificati sia \const{IPC\_CREAT} che \const{IPC\_EXCL}.
- \item[\errcode{EIDRM}] la coda richiesta è marcata per essere cancellata.
+ esiste, ma erano specificati sia \const{IPC\_CREAT} che \const{IPC\_EXCL}.
+ \item[\errcode{EIDRM}] la coda richiesta è marcata per essere cancellata
+ (solo fino al kernel 2.3.20).
\item[\errcode{ENOENT}] si è cercato di ottenere l'identificatore di una coda
di messaggi specificando una chiave che non esiste e \const{IPC\_CREAT}
non era specificato.
\item[\errcode{ENOSPC}] si è cercato di creare una coda di messaggi quando è
stato superato il limite massimo di code (\const{MSGMNI}).
- \end{errlist}
- ed inoltre \errval{ENOMEM}.
-}
-\end{functions}
+ \end{errlist}
+ ed inoltre \errval{ENOMEM} nel suo significato generico.}
+\end{funcproto}
Le funzione (come le analoghe che si usano per gli altri oggetti) serve sia a
ottenere l'identificatore di una coda di messaggi esistente, che a crearne una
nuova. L'argomento \param{key} specifica la chiave che è associata
all'oggetto, eccetto il caso in cui si specifichi il valore
\const{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
-associata alcuna chiave, il processo (ed i suoi eventuali figli) potranno
-farvi riferimento solo attraverso l'identificatore.
+associata alcuna chiave (per questo viene detta \textsl{privata}), ed il
+processo e i suoi eventuali figli potranno farvi riferimento solo attraverso
+l'identificatore.
-Se invece si specifica un valore diverso da \const{IPC\_PRIVATE}\footnote{in
- Linux questo significa un valore diverso da zero.} l'effetto della funzione
-dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
+Se invece si specifica un valore diverso da \const{IPC\_PRIVATE} (in Linux
+questo significa un valore diverso da zero) l'effetto della funzione dipende
+dal valore di \param{flag}, se questo è nullo la funzione si limita ad
effettuare una ricerca sugli oggetti esistenti, restituendo l'identificatore
se trova una corrispondenza, o fallendo con un errore di \errcode{ENOENT} se
non esiste o di \errcode{EACCES} se si sono specificati dei permessi non
\errcode{EEXIST} altrimenti.
Si tenga conto che l'uso di \const{IPC\_PRIVATE} non impedisce ad altri
-processi di accedere alla coda (se hanno privilegi sufficienti) una volta che
-questi possano indovinare o ricavare (ad esempio per tentativi)
+processi di accedere alla coda, se hanno privilegi sufficienti, una volta che
+questi possano indovinare o ricavare, ad esempio per tentativi,
l'identificatore ad essa associato. Per come sono implementati gli oggetti di
-IPC infatti non esiste una maniera che garantisca l'accesso esclusivo ad una
-coda di messaggi. Usare \const{IPC\_PRIVATE} o const{IPC\_CREAT} e
-\const{IPC\_EXCL} per \param{flag} comporta solo la creazione di una nuova
-coda.
+IPC infatti non esiste alcun modo in cui si possa garantire l'accesso
+esclusivo ad una coda di messaggi. Usare \const{IPC\_PRIVATE} o
+\const{IPC\_CREAT} e \const{IPC\_EXCL} per \param{flag} comporta solo la
+creazione di una nuova coda.
\begin{table}[htb]
\footnotesize
\centering
\begin{tabular}[c]{|c|r|l|l|}
\hline
- \textbf{Costante} & \textbf{Valore} & \textbf{File in \texttt{proc}}
+ \textbf{Costante} & \textbf{Valore} & \textbf{File in \file{/proc}}
& \textbf{Significato} \\
\hline
\hline
\label{tab:ipc_msg_limits}
\end{table}
-Le code di messaggi sono caratterizzate da tre limiti fondamentali, definiti
-negli header e corrispondenti alle prime tre costanti riportate in
-tab.~\ref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
-modificare questi limiti attraverso l'uso di \func{sysctl} o scrivendo nei
-file \sysctlrelfile{kernel}{msgmax},
-\sysctlrelfile{kernel}{msgmnb} e
-\sysctlrelfile{kernel}{msgmni} di \file{/proc/sys/kernel/}.
-
-\begin{figure}[!htb]
- \centering \includegraphics[width=13cm]{img/mqstruct}
- \caption{Schema della struttura di una coda messaggi.}
- \label{fig:ipc_mq_schema}
-\end{figure}
-
+Le code di messaggi sono caratterizzate da tre limiti fondamentali, un tempo
+definiti staticamente e corrispondenti alle prime tre costanti riportate in
+tab.~\ref{tab:ipc_msg_limits}. Come accennato però con tutte le versioni più
+recenti del kernel con Linux è possibile modificare questi limiti attraverso
+l'uso di \func{sysctl} o scrivendo nei file \sysctlrelfile{kernel}{msgmax},
+\sysctlrelfile{kernel}{msgmnb} e \sysctlrelfile{kernel}{msgmni} di
+\file{/proc/sys/kernel/}.
Una coda di messaggi è costituita da una \itindex{linked~list} \textit{linked
- list};\footnote{una \itindex{linked~list} \textit{linked list} è una tipica
+ list}.\footnote{una \itindex{linked~list} \textit{linked list} è una tipica
struttura di dati, organizzati in una lista in cui ciascun elemento contiene
un puntatore al successivo. In questo modo la struttura è veloce
nell'estrazione ed immissione dei dati dalle estremità dalla lista (basta
aggiungere un elemento in testa o in coda ed aggiornare un puntatore), e
relativamente veloce da attraversare in ordine sequenziale (seguendo i
puntatori), è invece relativamente lenta nell'accesso casuale e nella
- ricerca.} i nuovi messaggi vengono inseriti in coda alla lista e vengono
-letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato lo schema con
-cui queste strutture vengono mantenute dal kernel.\footnote{lo schema
- illustrato in fig.~\ref{fig:ipc_mq_schema} è in realtà una semplificazione
- di quello usato effettivamente fino ai kernel della serie 2.2.x, nei kernel
- della serie 2.4.x la gestione delle code di messaggi è stata modificata ed è
- effettuata in maniera diversa; abbiamo mantenuto lo schema precedente in
- quanto illustra comunque in maniera più che adeguata i principi di
- funzionamento delle code di messaggi.}
+ ricerca.} I nuovi messaggi vengono inseriti in coda alla lista e vengono
+letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato uno schema
+semplificato con cui queste strutture vengono mantenute dal
+kernel.\footnote{lo schema illustrato è in realtà una semplificazione di
+ quello usato fino ai kernel della serie 2.2, a partire della serie 2.4 la
+ gestione delle code di messaggi è effettuata in maniera diversa, ma abbiamo
+ mantenuto lo schema precedente dato che illustra in maniera più che adeguata
+ i principi di funzionamento delle code di messaggi.}
+
+\begin{figure}[!htb]
+ \centering \includegraphics[width=13cm]{img/mqstruct}
+ \caption{Schema della struttura di una coda messaggi.}
+ \label{fig:ipc_mq_schema}
+\end{figure}
+
+
+A ciascuna coda è associata una struttura \struct{msqid\_ds} la cui
+definizione è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura il
+kernel mantiene le principali informazioni riguardo lo stato corrente della
+coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2, essa
+ viene usata nei kernel della serie 2.4 solo per compatibilità in quanto è
+ quella restituita dalle funzioni dell'interfaccia; si noti come ci sia una
+ differenza con i campi mostrati nello schema di fig.~\ref{fig:ipc_mq_schema}
+ che sono presi dalla definizione di \file{include/linux/msg.h}, e fanno
+ riferimento alla definizione della omonima struttura usata nel kernel.} In
+fig.~\ref{fig:ipc_msqid_ds} sono elencati i campi significativi definiti in
+\headfile{sys/msg.h}, a cui si sono aggiunti gli ultimi tre campi che sono
+previsti dalla implementazione originale di System V, ma non dallo standard
+Unix98.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:ipc_msqid_ds}
\end{figure}
-A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
-definizione, è riportata in fig.~\ref{fig:ipc_msqid_ds}. In questa struttura
-il kernel mantiene le principali informazioni riguardo lo stato corrente della
-coda.\footnote{come accennato questo vale fino ai kernel della serie 2.2.x,
- essa viene usata nei kernel della serie 2.4.x solo per compatibilità in
- quanto è quella restituita dalle funzioni dell'interfaccia. Si noti come ci
- sia una differenza con i campi mostrati nello schema di
- fig.~\ref{fig:ipc_mq_schema} che sono presi dalla definizione di
- \file{include/linux/msg.h}, e fanno riferimento alla definizione della
- omonima struttura usata nel kernel.} In fig.~\ref{fig:ipc_msqid_ds} sono
-elencati i campi significativi definiti in \headfile{sys/msg.h}, a cui si sono
-aggiunti gli ultimi tre campi che sono previsti dalla implementazione
-originale di System V, ma non dallo standard Unix98.
-
Quando si crea una nuova coda con \func{msgget} questa struttura viene
inizializzata, in particolare il campo \var{msg\_perm} viene inizializzato
come illustrato in sez.~\ref{sec:ipc_sysv_access_control}, per quanto riguarda
\end{itemize*}
Una volta creata una coda di messaggi le operazioni di controllo vengono
-effettuate con la funzione \funcd{msgctl}, che (come le analoghe \func{semctl}
-e \func{shmctl}) fa le veci di quello che \func{ioctl} è per i file; il suo
-prototipo è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/ipc.h}
- \headdecl{sys/msg.h}
-
- \funcdecl{int msgctl(int msqid, int cmd, struct msqid\_ds *buf)}
-
- Esegue l'operazione specificata da \param{cmd} sulla coda \param{msqid}.
-
- \bodydesc{La funzione restituisce 0 in caso di successo o $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+effettuate con la funzione di sistema \funcd{msgctl}, che, come le analoghe
+\func{semctl} e \func{shmctl}, fa le veci di quello che \func{ioctl} è per i
+file; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/ipc.h}
+\fhead{sys/msg.h}
+\fdecl{int msgctl(int msqid, int cmd, struct msqid\_ds *buf)}
+\fdesc{Esegue una operazione su una coda.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma processo
chiamante non ha i privilegi di lettura sulla coda.
\var{msg\_qbytes} oltre il limite \const{MSGMNB} senza essere
amministratore.
\end{errlist}
- ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
-}
-\end{functions}
+ ed inoltre \errval{EFAULT} ed \errval{EINVAL} nel loro significato
+ generico.}
+\end{funcproto}
+
La funzione permette di accedere ai valori della struttura \struct{msqid\_ds},
mantenuta all'indirizzo \param{buf}, per la coda specificata
\end{itemize*}
Le code di messaggi presentano il solito problema di tutti gli oggetti del
-SysV IPC; essendo questi permanenti restano nel sistema occupando risorse
-anche quando un processo è terminato, al contrario delle pipe per le quali
-tutte le risorse occupate vengono rilasciate quanto l'ultimo processo che le
-utilizzava termina. Questo comporta che in caso di errori si può saturare il
-sistema, e che devono comunque essere esplicitamente previste delle funzioni
-di rimozione in caso di interruzioni o uscite dal programma (come vedremo in
-fig.~\ref{fig:ipc_mq_fortune_server}).
+SysV-IPC; essendo questi permanenti restano nel sistema occupando risorse
+anche quando un processo è terminato, al contrario delle \textit{pipe} per le
+quali tutte le risorse occupate vengono rilasciate quanto l'ultimo processo
+che le utilizzava termina. Questo comporta che in caso di errori si può
+saturare il sistema, e che devono comunque essere esplicitamente previste
+delle funzioni di rimozione in caso di interruzioni o uscite dal programma
+(come vedremo in fig.~\ref{fig:ipc_mq_fortune_server}).
L'altro problema è non facendo uso di file descriptor le tecniche di
\textit{I/O multiplexing} descritte in sez.~\ref{sec:file_multiplexing} non
ciascuna di esse.
Come esempio dell'uso delle code di messaggi possiamo riscrivere il nostro
-server di \textit{fortunes} usando queste al posto delle fifo. In questo caso
-useremo una sola coda di messaggi, usando il tipo di messaggio per comunicare
-in maniera indipendente con client diversi.
+server di \textit{fortunes} usando queste al posto delle \textit{fifo}. In
+questo caso useremo una sola coda di messaggi, usando il tipo di messaggio per
+comunicare in maniera indipendente con client diversi.
\begin{figure}[!htbp]
\footnotesize \centering
uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi
per permettere una comunicazione indipendente fra il server ed i vari client,
usando il \ids{PID} di questi ultimi come identificativo. Questo è possibile
-in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
-non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla
-base del loro tipo.
+in quanto, al contrario di una \textit{fifo}, la lettura di una coda di
+messaggi può non essere sequenziale, proprio grazie alla classificazione dei
+messaggi sulla base del loro tipo.
Il programma, oltre alle solite variabili per il nome del file da cui leggere
le \textit{fortunes} e per il vettore di stringhe che contiene le frasi,
server, viene prima controllato (\texttt{\small 22}) il numero di frasi
richieste abbia senso (cioè sia maggiore di zero), le quali poi
(\texttt{\small 23}) vengono lette nel vettore in memoria con la stessa
-funzione \code{FortuneParse} usata anche per il server basato sulle fifo.
+funzione \code{FortuneParse} usata anche per il server basato sulle
+\textit{fifo}.
Una volta inizializzato il vettore di stringhe coi messaggi presi dal file
delle \textit{fortune} si procede (\texttt{\small 25}) con la generazione di
mqfortuned} verificando che effettivamente la coda di messaggi viene rimossa.
Benché funzionante questa architettura risente dello stesso inconveniente
-visto anche nel caso del precedente server basato sulle fifo; se il client
-viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura
-della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
-il problema delle fifo che restavano nel filesystem). In questo caso però il
-problemi sono maggiori, sia perché è molto più facile esaurire la memoria
-dedicata ad una coda di messaggi che gli \itindex{inode} inode di un filesystem,
-sia perché, con il riutilizzo dei \ids{PID} da parte dei processi, un client
-eseguito in un momento successivo potrebbe ricevere un messaggio non
-indirizzato a lui.
+visto anche nel caso del precedente server basato sulle \textit{fifo}; se il
+client viene interrotto dopo l'invio del messaggio di richiesta e prima della
+lettura della risposta, quest'ultima resta nella coda (così come per le
+\textit{fifo} si aveva il problema delle \textit{fifo} che restavano nel
+filesystem). In questo caso però il problemi sono maggiori, sia perché è molto
+più facile esaurire la memoria dedicata ad una coda di messaggi che gli
+\itindex{inode} inode di un filesystem, sia perché, con il riutilizzo dei
+\ids{PID} da parte dei processi, un client eseguito in un momento successivo
+potrebbe ricevere un messaggio non indirizzato a lui.
\label{sec:ipc_sysv_sem}
I semafori non sono meccanismi di intercomunicazione diretta come quelli
-(pipe, fifo e code di messaggi) visti finora, e non consentono di scambiare
-dati fra processi, ma servono piuttosto come meccanismi di sincronizzazione o
-di protezione per le \index{sezione~critica} \textsl{sezioni critiche} del
-codice (si ricordi quanto detto in sez.~\ref{sec:proc_race_cond}).
+(\textit{pipe}, \textit{fifo} e code di messaggi) visti finora, e non
+consentono di scambiare dati fra processi, ma servono piuttosto come
+meccanismi di sincronizzazione o di protezione per le \index{sezione~critica}
+\textsl{sezioni critiche} del codice (si ricordi quanto detto in
+sez.~\ref{sec:proc_race_cond}).
Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a
seconda del suo valore, di consentire o meno la prosecuzione dell'esecuzione
utilizzando il valore del contatore come indicatore del ``numero di risorse''
ancora disponibili.
-Il sistema di comunicazione inter-processo di \textit{SysV IPC} prevede anche i
+Il sistema di comunicazione inter-processo di \textit{SysV-IPC} prevede anche i
semafori, ma gli oggetti utilizzati non sono semafori singoli, ma gruppi di
semafori detti \textsl{insiemi} (o \textit{semaphore set}); la funzione che
permette di creare o ottenere l'identificatore di un insieme di semafori è
Purtroppo questa implementazione complica inutilmente lo schema elementare che
abbiamo descritto, dato che non è possibile definire un singolo semaforo, ma
se ne deve creare per forza un insieme. Ma questa in definitiva è solo una
-complicazione inutile, il problema è che i semafori del \textit{SysV IPC}
+complicazione inutile, il problema è che i semafori del \textit{SysV-IPC}
soffrono di altri due, ben più gravi, difetti.
Il primo difetto è che non esiste una funzione che permetta di creare ed
perde così ogni possibilità di eseguire l'operazione atomicamente.
Il secondo difetto deriva dalla caratteristica generale degli oggetti del
-\textit{SysV IPC} di essere risorse globali di sistema, che non vengono
+\textit{SysV-IPC} di essere risorse globali di sistema, che non vengono
cancellate quando nessuno le usa più; ci si così a trova a dover affrontare
esplicitamente il caso in cui un processo termina per un qualche errore,
lasciando un semaforo occupato, che resterà tale fino al successivo riavvio
Ciascun semaforo dell'insieme è realizzato come una struttura di tipo
\struct{sem} che ne contiene i dati essenziali, la sua definizione\footnote{si
è riportata la definizione originaria del kernel 1.0, che contiene la prima
- realizzazione del \textit{SysV IPC} in Linux. In realtà questa struttura
+ realizzazione del \textit{SysV-IPC} in Linux. In realtà questa struttura
ormai è ridotta ai soli due primi membri, e gli altri vengono calcolati
dinamicamente. La si è utilizzata a scopo di esempio, perché indica tutti i
valori associati ad un semaforo, restituiti dalle funzioni di controllo, e
}
\end{functions}
+
+%TODO manca semtimedop, trattare qui, referenziata in
+%sez.~\ref{sec:sig_gen_beha}.
+
La funzione permette di eseguire operazioni multiple sui singoli semafori di
un insieme. La funzione richiede come primo argomento l'identificatore
\param{semid} dell'insieme su cui si vuole operare. Il numero di operazioni da
semafori possono restare occupati, abbiamo visto come \func{semop} permetta di
attivare un meccanismo di ripristino attraverso l'uso del flag
\const{SEM\_UNDO}. Il meccanismo è implementato tramite una apposita struttura
-\struct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
+\kstruct{sem\_undo}, associata ad ogni processo per ciascun semaforo che esso
ha modificato; all'uscita i semafori modificati vengono ripristinati, e le
strutture disallocate. Per mantenere coerente il comportamento queste
strutture non vengono ereditate attraverso una \func{fork} (altrimenti si
in maniera semplificata nello schema di fig.~\ref{fig:ipc_sem_schema}. Si è
presa come riferimento l'architettura usata fino al kernel 2.2.x che è più
semplice (ed illustrata in dettaglio in \cite{tlk}); nel kernel 2.4.x la
-struttura del \textit{SysV IPC} è stata modificata, ma le definizioni relative
+struttura del \textit{SysV-IPC} è stata modificata, ma le definizioni relative
a queste strutture restano per compatibilità.\footnote{in particolare con le
vecchie versioni delle librerie del C, come le libc5.}
\struct{semid\_ds} ed il relativo vettore di strutture \struct{sem}. Quando si
richiede una operazione viene anzitutto verificato che tutte le operazioni
possono avere successo; se una di esse comporta il blocco del processo il
-kernel crea una struttura \struct{sem\_queue} che viene aggiunta in fondo alla
+kernel crea una struttura \kstruct{sem\_queue} che viene aggiunta in fondo alla
coda di attesa associata a ciascun insieme di semafori\footnote{che viene
referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last}
di \struct{semid\_ds}.}.
immediatamente, dopo di che il kernel esegue una scansione della coda di
attesa (a partire da \var{sem\_pending}) per verificare se qualcuna delle
operazioni sospese in precedenza può essere eseguita, nel qual caso la
-struttura \struct{sem\_queue} viene rimossa e lo stato del processo associato
+struttura \kstruct{sem\_queue} viene rimossa e lo stato del processo associato
all'operazione (\var{sleeper}) viene riportato a \textit{running}; il tutto
viene ripetuto fin quando non ci sono più operazioni eseguibili o si è
svuotata la coda. Per gestire il meccanismo del ripristino tutte le volte che
per un'operazione si è specificato il flag \const{SEM\_UNDO} viene mantenuta
-per ciascun insieme di semafori una apposita struttura \struct{sem\_undo} che
+per ciascun insieme di semafori una apposita struttura \kstruct{sem\_undo} che
contiene (nel vettore puntato dal campo \var{semadj}) un valore di
aggiustamento per ogni semaforo cui viene sommato l'opposto del valore usato
per l'operazione.
+%TODO verificare queste strutture \kstruct{sem\_queue} e \kstruct{sem\_undo}
+
Queste strutture sono mantenute in due liste,\footnote{rispettivamente
attraverso i due campi \var{id\_next} e \var{proc\_next}.} una associata
all'insieme di cui fa parte il semaforo, che viene usata per invalidare le
strutture se questo viene cancellato o per azzerarle se si è eseguita una
operazione con \func{semctl}; l'altra associata al processo che ha eseguito
l'operazione;\footnote{attraverso il campo \var{semundo} di
- \struct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
+ \kstruct{task\_struct}, come mostrato in \ref{fig:ipc_sem_schema}.} quando un
processo termina, la lista ad esso associata viene scandita e le operazioni
applicate al semaforo. Siccome un processo può accumulare delle richieste di
ripristino per semafori differenti chiamate attraverso diverse chiamate a
\subsection{Memoria condivisa}
\label{sec:ipc_sysv_shm}
-Il terzo oggetto introdotto dal \textit{SysV IPC} è quello dei segmenti di
+Il terzo oggetto introdotto dal \textit{SysV-IPC} è quello dei segmenti di
memoria condivisa. La funzione che permette di ottenerne uno è \funcd{shmget},
ed il suo prototipo è:
\begin{functions}
\param{size} specifica invece la dimensione, in byte, del segmento, che viene
comunque arrotondata al multiplo superiore di \const{PAGE\_SIZE}.
+% TODO aggiungere l'uso di SHM_HUGETLB introdotto con il kernel 2.6.0
+
La memoria condivisa è la forma più veloce di comunicazione fra due processi,
in quanto permette agli stessi di vedere nel loro spazio di indirizzi una
stessa sezione di memoria. Pertanto non è necessaria nessuna operazione di
fra processi più veloce, essa non è sempre il più appropriato, dato che, come
abbiamo visto, si avrà comunque la necessità di una sincronizzazione degli
accessi. Per questo motivo, quando la comunicazione fra processi è
-sequenziale, altri meccanismi come le pipe, le fifo o i socket, che non
-necessitano di sincronizzazione esplicita, sono da preferire. Essa diventa
-l'unico meccanismo possibile quando la comunicazione non è
-sequenziale\footnote{come accennato in sez.~\ref{sec:ipc_sysv_mq} per la
+sequenziale, altri meccanismi come le \textit{pipe}, le \textit{fifo} o i
+socket, che non necessitano di sincronizzazione esplicita, sono da
+preferire. Essa diventa l'unico meccanismo possibile quando la comunicazione
+non è sequenziale\footnote{come accennato in sez.~\ref{sec:ipc_sysv_mq} per la
comunicazione non sequenziale si possono usare le code di messaggi,
attraverso l'uso del campo \var{mtype}, ma solo se quest'ultima può essere
effettuata in forma di messaggio.} o quando non può avvenire secondo una
leggendo), poi (\texttt{\small 44}) si cancellano i valori precedentemente
immagazzinati nella memoria condivisa con \func{memset}, e si esegue
(\texttt{\small 45}) un nuovo calcolo degli stessi utilizzando la funzione
-\func{DirScan}; infine (\texttt{\small 46}) si sblocca il mutex con
+\myfunc{dir\_scan}; infine (\texttt{\small 46}) si sblocca il mutex con
\func{MutexUnlock}, e si attende (\texttt{\small 47}) per il periodo di tempo
specificato a riga di comando con l'opzione \code{-p} con una \func{sleep}.
Si noti come per il calcolo dei valori da mantenere nella memoria condivisa si
-sia usata ancora una volta la funzione \func{DirScan}, già utilizzata (e
+sia usata ancora una volta la funzione \myfunc{dir\_scan}, già utilizzata (e
descritta in dettaglio) in sez.~\ref{sec:file_dir_read}, che ci permette di
effettuare la scansione delle voci della directory, chiamando per ciascuna di
esse la funzione \func{ComputeValues}, che esegue tutti i calcoli necessari.
contatori nella memoria condivisa, cui accede grazie alla
\index{variabili!globali} variabile globale \var{shmptr}.
-Dato che la funzione è chiamata da \func{DirScan}, si è all'interno del ciclo
-principale del programma, con un mutex acquisito, perciò non è necessario
-effettuare nessun controllo e si può accedere direttamente alla memoria
-condivisa usando \var{shmptr} per riempire i campi della struttura
+Dato che la funzione è chiamata da \myfunc{dir\_scan}, si è all'interno del
+ciclo principale del programma, con un mutex acquisito, perciò non è
+necessario effettuare nessun controllo e si può accedere direttamente alla
+memoria condivisa usando \var{shmptr} per riempire i campi della struttura
\struct{DirProp}; così prima (\texttt{\small 6--7}) si sommano le dimensioni
dei file ed il loro numero, poi, utilizzando le macro di
tab.~\ref{tab:file_type_macro}, si contano (\texttt{\small 8--14}) quanti ce
\label{sec:ipc_alternatives}
Come abbiamo detto in sez.~\ref{sec:ipc_sysv_generic}, e ripreso nella
-descrizione dei singoli oggetti che ne fan parte, il \textit{SysV IPC}
+descrizione dei singoli oggetti che ne fan parte, il \textit{SysV-IPC}
presenta numerosi problemi; in \cite{APUE}\footnote{in particolare nel
capitolo 14.} Stevens ne effettua una accurata analisi (alcuni dei concetti
sono già stati accennati in precedenza) ed elenca alcune possibili tecniche
\label{sec:ipc_mq_alternative}
Le code di messaggi sono probabilmente il meno usato degli oggetti del
-\textit{SysV IPC}; esse infatti nacquero principalmente come meccanismo di
-comunicazione bidirezionale quando ancora le pipe erano unidirezionali; con la
-disponibilità di \func{socketpair} (vedi sez.~\ref{sec:ipc_socketpair}) o
-utilizzando una coppia di pipe, si può ottenere questo risultato senza
-incorrere nelle complicazioni introdotte dal \textit{SysV IPC}.
+\textit{SysV-IPC}; esse infatti nacquero principalmente come meccanismo di
+comunicazione bidirezionale quando ancora le \textit{pipe} erano
+unidirezionali; con la disponibilità di \func{socketpair} (vedi
+sez.~\ref{sec:ipc_socketpair}) o utilizzando una coppia di \textit{pipe}, si
+può ottenere questo risultato senza incorrere nelle complicazioni introdotte
+dal \textit{SysV-IPC}.
In realtà, grazie alla presenza del campo \var{mtype}, le code di messaggi
hanno delle caratteristiche ulteriori, consentendo una classificazione dei
messaggi ed un accesso non rigidamente sequenziale; due caratteristiche che
-sono impossibili da ottenere con le pipe e i socket di \func{socketpair}. A
-queste esigenze però si può comunque ovviare in maniera diversa con un uso
-combinato della memoria condivisa e dei meccanismi di sincronizzazione, per
-cui alla fine l'uso delle code di messaggi classiche è relativamente poco
-diffuso.
+sono impossibili da ottenere con le \textit{pipe} e i socket di
+\func{socketpair}. A queste esigenze però si può comunque ovviare in maniera
+diversa con un uso combinato della memoria condivisa e dei meccanismi di
+sincronizzazione, per cui alla fine l'uso delle code di messaggi classiche è
+relativamente poco diffuso.
% TODO: trattare qui, se non ssis trova posto migliore, copy_from_process e
% copy_to_process, introdotte con il kernel 3.2. Vedi
\index{file!di lock|(}
-Come illustrato in sez.~\ref{sec:ipc_sysv_sem} i semafori del \textit{SysV IPC}
+Come illustrato in sez.~\ref{sec:ipc_sysv_sem} i semafori del \textit{SysV-IPC}
presentano una interfaccia inutilmente complessa e con alcuni difetti
strutturali, per questo quando si ha una semplice esigenza di sincronizzazione
per la quale basterebbe un semaforo binario (quello che abbiamo definito come
dei \textsl{file di lock} (per i quali esiste anche una opportuna directory,
\file{/var/lock}, nel filesystem standard). Per questo si usa la
caratteristica della funzione \func{open} (illustrata in
-sez.~\ref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo
+sez.~\ref{sec:file_open_close}) che prevede\footnote{questo è quanto dettato dallo
standard POSIX.1, ciò non toglie che in alcune implementazioni questa
tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si
è comunque soggetti alla possibilità di una \itindex{race~condition}
\end{figure}
Uno dei limiti di questa tecnica è che, come abbiamo già accennato in
-sez.~\ref{sec:file_open}, questo comportamento di \func{open} può non
+sez.~\ref{sec:file_open_close}, questo comportamento di \func{open} può non
funzionare (la funzione viene eseguita, ma non è garantita l'atomicità
dell'operazione) se il filesystem su cui si va ad operare è su NFS; in tal
caso si può adottare una tecnica alternativa che prevede l'uso della
\subsection{Il \textit{memory mapping} anonimo}
\label{sec:ipc_mmap_anonymous}
-\itindbeg{memory~mapping}
-Abbiamo già visto che quando i processi sono \textsl{correlati}\footnote{se
- cioè hanno almeno un progenitore comune.} l'uso delle pipe può costituire
-una valida alternativa alle code di messaggi; nella stessa situazione si può
-evitare l'uso di una memoria condivisa facendo ricorso al cosiddetto
-\textit{memory mapping} anonimo.
+\itindbeg{memory~mapping} Abbiamo già visto che quando i processi sono
+\textsl{correlati}\footnote{se cioè hanno almeno un progenitore comune.} l'uso
+delle \textit{pipe} può costituire una valida alternativa alle code di
+messaggi; nella stessa situazione si può evitare l'uso di una memoria
+condivisa facendo ricorso al cosiddetto \textit{memory mapping} anonimo.
In sez.~\ref{sec:file_memory_map} abbiamo visto come sia possibile mappare il
contenuto di un file nella memoria di un processo, e che, quando viene usato
sez.~\ref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
\itindend{memory~mapping}
-% TODO fare esempio di mmap anonima
+% TODO: fare esempio di mmap anonima
+
+% TODO: con il kernel 3.2 è stata introdotta un nuovo meccanismo di
+% intercomunicazione veloce chiamato Cross Memory Attach, da capire se e come
+% trattarlo qui, vedi http://lwn.net/Articles/405346/
+% https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fcf634098c00dd9cd247447368495f0b79be12d1
\section{L'intercomunicazione fra processi di POSIX}
\label{sec:ipc_posix}
-Per superare i numerosi problemi del \textit{SysV IPC}, evidenziati per i suoi
+Per superare i numerosi problemi del \textit{SysV-IPC}, evidenziati per i suoi
aspetti generali in coda a sez.~\ref{sec:ipc_sysv_generic} e per i singoli
oggetti nei paragrafi successivi, lo standard POSIX.1b ha introdotto dei nuovi
meccanismi di comunicazione, che vanno sotto il nome di POSIX IPC, definendo
kernel 2.6.6.
La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
-degli identificatori e delle chiavi visti nel SysV IPC, per passare ai
+degli identificatori e delle chiavi visti nel \textit{SysV-IPC}, per passare ai
\itindex{POSIX~IPC~names} \textit{POSIX IPC names}, che sono sostanzialmente
equivalenti ai nomi dei file. Tutte le funzioni che creano un oggetto di IPC
POSIX prendono come primo argomento una stringa che indica uno di questi nomi;
semantica (quella illustrata in sez.~\ref{sec:file_access_control}), e non
quella particolare (si ricordi quanto visto in
sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del
-SysV IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo
+SysV-IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo
proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata
secondo la semantica SysV: corrispondono cioè a \ids{UID} e \ids{GID} effettivi
del processo che esegue la creazione.
Le code di messaggi POSIX sono supportate da Linux a partire dalla versione
2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e
Krzysztof Benedyczak, e le relative informazioni si possono trovare su
- \url{http://www.geocities.com/wronski12/posix_ipc/index.html}.} In
-generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
+ \url{http://www.geocities.com/wronski12/posix_ipc/index.html}.} In generale,
+come le corrispettive del \textit{SysV-IPC}, le code di messaggi sono poco
usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e
che in casi più complessi la comunicazione può essere gestita direttamente con
mutex (o semafori) e memoria condivisa con tutta la flessibilità che occorre.
La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
possono essere specificati per \param{oflag}, che deve essere specificato come
maschera binaria; i valori possibili per i vari bit sono quelli visti in
-tab.~\ref{tab:file_open_flags} dei quali però \func{mq\_open} riconosce solo i
+sez.~\ref{sec:file_open_close} dei quali però \func{mq\_open} riconosce solo i
seguenti:
\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
\item[\const{O\_RDONLY}] Apre la coda solo per la ricezione di messaggi. Il
coda resterà accessibile a tutti i processi che hanno un descrittore aperto su
di essa. Allo stesso modo una coda ed i suoi contenuti resteranno disponibili
all'interno del sistema anche quando quest'ultima non è aperta da nessun
-processo (questa è una delle differenze più rilevanti nei confronti di pipe e
-fifo). La sola differenza fra code di messaggi POSIX e file normali è che,
-essendo il filesystem delle code di messaggi virtuale e basato su oggetti
-interni al kernel, il suo contenuto viene perduto con il riavvio del sistema.
+processo (questa è una delle differenze più rilevanti nei confronti di
+\textit{pipe} e \textit{fifo}). La sola differenza fra code di messaggi POSIX
+e file normali è che, essendo il filesystem delle code di messaggi virtuale e
+basato su oggetti interni al kernel, il suo contenuto viene perduto con il
+riavvio del sistema.
Come accennato ad ogni coda di messaggi è associata una struttura
\struct{mq\_attr}, che può essere letta e modificata attraverso le due
il messaggio, entrambe le funzioni, al contrario di quanto avveniva nelle code
di messaggi di SysV, ritornano un errore di \errcode{EMSGSIZE} senza estrarre
il messaggio. È pertanto opportuno eseguire sempre una chiamata a
-\func{mq\_getaddr} prima di eseguire una ricezione, in modo da ottenere la
+\func{mq\_getattr} prima di eseguire una ricezione, in modo da ottenere la
dimensione massima dei messaggi sulla coda, per poter essere in grado di
allocare dei buffer sufficientemente ampi per la lettura.
\const{SIGEV\_SIGNAL}).} Il metodo consigliato è quello di usare
\const{SIGEV\_SIGNAL} usando il campo \var{sigev\_signo} per indicare il quale
segnale deve essere inviato al processo. Inoltre il campo \var{sigev\_value} è
-un puntatore ad una struttura \struct{sigval\_t} (definita in
+un puntatore ad una struttura \struct{sigval} (definita in
fig.~\ref{fig:sig_sigval}) che permette di restituire al gestore del segnale
un valore numerico o un indirizzo,\footnote{per il suo uso si riveda la
trattazione fatta in sez.~\ref{sec:sig_real_time} a proposito dei segnali
possono essere specificati per \param{oflag}, che deve essere specificato come
maschera binaria comprendente almeno uno dei due valori \const{O\_RDONLY} e
\const{O\_RDWR}; i valori possibili per i vari bit sono quelli visti in
-tab.~\ref{tab:file_open_flags} dei quali però \func{shm\_open} riconosce solo
+sez.~\ref{sec:file_open_close} dei quali però \func{shm\_open} riconosce solo
i seguenti:
\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
\item[\const{O\_RDONLY}] Apre il file descriptor associato al segmento di
segmento di memoria condiviso con le stesse modalità di
\func{open}\footnote{in realtà, come accennato, \func{shm\_open} è un semplice
wrapper per \func{open}, usare direttamente quest'ultima avrebbe lo stesso
- effetto.} viste in sez.~\ref{sec:file_open}; in particolare viene impostato
+ effetto.} viste in sez.~\ref{sec:file_open_close}; in particolare viene impostato
il flag \const{FD\_CLOEXEC}. Chiamate effettuate da diversi processi usando
lo stesso nome, restituiranno file descriptor associati allo stesso segmento
(così come, nel caso di file di dati, essi sono associati allo stesso
La terza funzione (\texttt{\small 40--45}) è \func{RemoveShm}, e serve a
cancellare un segmento di memoria condivisa. Dato che al contrario di quanto
-avveniva con i segmenti del SysV IPC gli oggetti allocati nel kernel vengono
-rilasciati automaticamente quando nessuna li usa più, tutto quello che c'è da
-fare (\texttt{\small 44}) in questo caso è chiamare \func{shm\_unlink},
+avveniva con i segmenti del \textit{SysV-IPC} gli oggetti allocati nel kernel
+vengono rilasciati automaticamente quando nessuna li usa più, tutto quello che
+c'è da fare (\texttt{\small 44}) in questo caso è chiamare \func{shm\_unlink},
restituendo al chiamante il valore di ritorno.
estensioni \textit{real-time} della \acr{glibc}.\footnote{quelle che si
accedono collegandosi alla libreria \texttt{librt}.} Esisteva inoltre una
libreria che realizzava (parzialmente) l'interfaccia POSIX usando le funzioni
-dei semafori di SysV IPC (mantenendo così tutti i problemi sottolineati in
-sez.~\ref{sec:ipc_sysv_sem}).
+dei semafori di \textit{SysV-IPC} (mantenendo così tutti i problemi
+sottolineati in sez.~\ref{sec:ipc_sysv_sem}).
A partire dal kernel 2.5.7 è stato introdotto un meccanismo di
sincronizzazione completamente nuovo, basato sui cosiddetti
L'argomento \param{oflag} è quello che controlla le modalità con cui opera la
funzione, ed è passato come maschera binaria; i bit corrispondono a quelli
utilizzati per l'analogo argomento di \func{open}, anche se dei possibili
-valori visti in sez.~\ref{sec:file_open} sono utilizzati soltanto
+valori visti in sez.~\ref{sec:file_open_close} sono utilizzati soltanto
\const{O\_CREAT} e \const{O\_EXCL}.
Se si usa \const{O\_CREAT} si richiede la creazione del semaforo qualora
questo non esista, ed in tal caso occorre utilizzare la seconda forma della
funzione, in cui si devono specificare sia un valore iniziale con l'argomento
\param{value},\footnote{e si noti come così diventa possibile, differenza di
- quanto avviene per i semafori del \textit{SysV IPC}, effettuare in maniera
+ quanto avviene per i semafori del \textit{SysV-IPC}, effettuare in maniera
atomica creazione ed inizializzazione di un semaforo usando una unica
funzione.} che una maschera dei permessi con l'argomento
\param{mode};\footnote{anche questo argomento prende gli stessi valori
La seconda variante di \func{sem\_wait} è una estensione specifica che può
essere utilizzata soltanto se viene definita la macro \macro{\_XOPEN\_SOURCE}
ad un valore di 600 prima di includere \headfile{semaphore.h}, la funzione è
-\func{sem\_timedwait}, ed il suo prototipo è:
+\funcd{sem\_timedwait}, ed il suo prototipo è:
\begin{functions}
\headdecl{semaphore.h}
quanto avviene per i file, in caso di una chiamata ad \func{execve} tutti i
semafori vengono chiusi automaticamente.
-Come per i semafori del \textit{SysV IPC} anche quelli POSIX hanno una
+Come per i semafori del \textit{SysV-IPC} anche quelli POSIX hanno una
persistenza di sistema; questo significa che una volta che si è creato un
semaforo con \func{sem\_open} questo continuerà ad esistere fintanto che il
kernel resta attivo (vale a dire fino ad un successivo riavvio) a meno che non
il semaforo viene effettivamente cancellato dal sistema soltanto quando tutti
i processi che lo avevano aperto lo chiudono. Si segue cioè la stessa
semantica usata con \func{unlink} per i file, trattata in dettaglio in
-sez.~\ref{sec:file_link}.
+sez.~\ref{sec:link_symlink_rename}.
Una delle caratteristiche peculiari dei semafori POSIX è che questi possono
anche essere utilizzati anche in forma anonima, senza necessità di fare
luogo ad un errore, non essendo stati creati il semaforo ed il segmento di
memoria condivisa.} che inizierà a stampare una volta al secondo il
contenuto del messaggio ed i suoi dati, con qualcosa del tipo:
-\begin{Verbatim}
-piccardi@hain:~/gapil/sources$ ./message_getter messaggio
+\begin{Console}
+piccardi@hain:~/gapil/sources$ \textbf{./message_getter messaggio}
sem=1, Fri Dec 31 14:12:41 2010
message: messaggio
sem=1, Fri Dec 31 14:12:42 2010
message: messaggio
...
-\end{Verbatim}
+\end{Console}
%$
proseguendo indefinitamente fintanto che non si prema \texttt{C-c} per farlo
uscire. Si noti come il valore del semaforo risulti sempre pari ad 1 (in
A questo punto si potrà lanciare \file{message\_setter} per cambiare il
messaggio, nel nostro caso per rendere evidente il funzionamento del blocco
richiederemo anche una attesa di 3 secondi, ed otterremo qualcosa del tipo:
-\begin{Verbatim}
-piccardi@hain:~/gapil/sources$ ./message_setter -t 3 ciao
+\begin{Console}
+piccardi@hain:~/gapil/sources$ \textbf{./message_setter -t 3 ciao}
Sleeping for 3 seconds
-\end{Verbatim}
+\end{Console}
%$
dove il programma si fermerà per 3 secondi prima di rilasciare il semaforo e
terminare.
L'effetto di questo programma si potrà però apprezzare meglio nell'uscita di
\file{message\_getter}, che verrà interrotta per questo stesso tempo, prima di
ricominciare con il nuovo testo:
-\begin{Verbatim}
+\begin{Console}
...
sem=1, Fri Dec 31 14:16:27 2010
message: messaggio
sem=1, Fri Dec 31 14:16:33 2010
message: ciao
...
-\end{Verbatim}
+\end{Console}
%$
E si noterà come nel momento in cui si è lanciato \file{message\_setter} le
% LocalWords: FortuneServer FortuneParse FortuneClient pid libgapil LD librt
% LocalWords: PATH linker pathname ps tmp killall fortuned crash socket domain
% LocalWords: socketpair BSD sys protocol sv EAFNOSUPPORT EPROTONOSUPPORT AF
-% LocalWords: EOPNOTSUPP SOCK SysV IPC Process Comunication ipc perm key exec
+% LocalWords: EOPNOTSUPP SOCK Process Comunication ipc perm key exec
% LocalWords: header ftok proj stat libc SunOS glibc XPG dell'inode number uid
% LocalWords: cuid cgid gid tab MSG shift group umask seq MSGMNI SEMMNI SHMMNI
% LocalWords: shmmni msgmni sem sysctl IPCMNI IPCTestId msgget EACCES EEXIST
% LocalWords: dtime lpid cpid nattac shmall shmmax SHMLBA SHMSEG EOVERFLOW brk
% LocalWords: memory shmat shmdt void shmaddr shmflg SVID RND RDONLY rounded
% LocalWords: SIGSEGV nattch exit SharedMem ShmCreate memset fill ShmFind home
-% LocalWords: ShmRemove DirMonitor DirProp chdir GaPiL shmptr DirScan ipcs NFS
+% LocalWords: ShmRemove DirMonitor DirProp chdir GaPiL shmptr ipcs NFS
% LocalWords: ComputeValues ReadMonitor touch SIGTERM dirmonitor unlink fcntl
% LocalWords: LockFile UnlockFile CreateMutex FindMutex LockMutex SETLKW GETLK
% LocalWords: UnlockMutex RemoveMutex ReadMutex UNLCK WRLCK RDLCK mapping MAP
projects / gapil.git / blobdiff