capi della pipe, associati a ciascun file descriptor, con le frecce che
indicano la direzione del flusso dei dati.
+% TODO: la dimensione è cambiata a 64k (vedi man 7 pipe) e può essere
+% modificata con F_SETPIPE_SZ dal 2.6.35 (vedi fcntl)
+
\begin{figure}[!htb]
\centering
\includegraphics[height=5cm]{img/pipe}
\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}
+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 pipe possa diventare un meccanismo di intercomunicazione. Un
processo figlio infatti condivide gli stessi file descriptor del padre,
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
-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.
+(che abbiamo visto in tab.~\ref{tab:file_std_files} e
+sez.~\ref{sec:file_stream}) sulla 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]
\footnotesize \centering
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à
+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 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 è:
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
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
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
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
projects / gapil.git / blobdiff