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 ad un buffer nel kernel, la cui dimensione è
-specificata dal parametro di sistema \const{PIPE\_BUF}, (vedi
+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
è 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
+\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.
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
+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
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 \file{shmmni}, \file{msgmni} e \file{sem} di
- \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.} e per ciascuno di
+ scrivendo sui file \procrelfile{/proc/sys/kernel}{shmmni},
+ \procrelfile{/proc/sys/kernel}{msgmni} e \procrelfile{/proc/sys/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
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 \file{msgmax}, \file{msgmnb} e \file{msgmni} di \file{/proc/sys/kernel/}.
+file \procrelfile{/proc/sys/kernel}{msgmax},
+\procrelfile{/proc/sys/kernel}{msgmnb} e
+\procrelfile{/proc/sys/kernel}{msgmni} di \file{/proc/sys/kernel/}.
\begin{figure}[htb]
serie di limiti, i cui valori sono associati ad altrettante costanti, che si
sono riportate in tab.~\ref{tab:ipc_sem_limits}. Alcuni di questi limiti sono
al solito accessibili e modificabili attraverso \func{sysctl} o scrivendo
-direttamente nel file \file{/proc/sys/kernel/sem}.
+direttamente nel file \procfile{/proc/sys/kernel/sem}.
La funzione che permette di effettuare le varie operazioni di controllo sui
semafori (fra le quali, come accennato, è impropriamente compresa anche la
& \textbf{Significato} \\
\hline
\hline
- \const{SHMALL}& 0x200000&\file{shmall}& Numero massimo di pagine che
- possono essere usate per i segmenti di
- memoria condivisa.\\
- \const{SHMMAX}&0x2000000&\file{shmmax}& Dimensione massima di un segmento
- di memoria condivisa.\\
- \const{SHMMNI}& 4096&\file{msgmni}& Numero massimo di segmenti di
- memoria condivisa presenti nel
- kernel.\\
+ \const{SHMALL}& 0x200000&\procrelfile{/proc/sys/kernel}{shmall}
+ & Numero massimo di pagine che
+ possono essere usate per i segmenti di
+ memoria condivisa.\\
+ \const{SHMMAX}&0x2000000&\procrelfile{/proc/sys/kernel}{shmmax}
+ & Dimensione massima di un segmento di memoria
+ condivisa.\\
+ \const{SHMMNI}& 4096&\procrelfile{/proc/sys/kernel}{msgmni}
+ & Numero massimo di segmenti di memoria condivisa
+ presenti nel kernel.\\
\const{SHMMIN}& 1& --- & Dimensione minima di un segmento di
memoria condivisa.\\
\const{SHMLBA}&\const{PAGE\_SIZE}&--- & Limite inferiore per le dimensioni
\begin{errlist}
\item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma i permessi non
consentono l'accesso in lettura al segmento.
- \item[\errcode{EINVAL}] O \param{shmid} non è un identificatore valido o
+ \item[\errcode{EINVAL}] o \param{shmid} non è un identificatore valido o
\param{cmd} non è un comando valido.
\item[\errcode{EIDRM}] l'argomento \param{shmid} fa riferimento ad un
segmento che è stato cancellato.
\label{fig:ipc_shmem_layout}
\end{figure}
-L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{Lo standard
+L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{lo standard
SVID prevede che l'argomento \param{shmaddr} sia di tipo \ctyp{char *}, così
- come il valore di ritorno della funzione. In Linux è stato così con le
+ come il valore di ritorno della funzione; in Linux è stato così con le
\acr{libc4} e le \acr{libc5}, con il passaggio alle \acr{glibc} il tipo di
\param{shmaddr} è divenuto un \ctyp{const void *} e quello del valore di
ritorno un \ctyp{void *}.} deve essere associato il segmento, se il valore
2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e
Krzysztof Benedyczak, e le relative informazioni si possono trovare su
\href{http://www.geocities.com/wronski12/posix_ipc/index.html}
- {\texttt{http://www.geocities.com/wronski12/posix\_ipc/index.html}}.} In
+ {\textsf{http://www.geocities.com/wronski12/posix\_ipc/index.html}}.} In
generale, come le corrispettive del 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
La libreria inoltre richiede la presenza dell'apposito filesystem di tipo
\texttt{mqueue} montato su \file{/dev/mqueue}; questo può essere fatto
-aggiungendo ad \file{/etc/fstab} una riga come:
+aggiungendo ad \conffile{/etc/fstab} una riga come:
\begin{verbatim}
mqueue /dev/mqueue mqueue defaults 0 0
\end{verbatim}
\begin{verbatim}
tmpfs /dev/shm tmpfs defaults 0 0
\end{verbatim}
-ad \file{/etc/fstab}. In realtà si può montare un filesystem \texttt{tmpfs}
+ad \conffile{/etc/fstab}. In realtà si può montare un filesystem \texttt{tmpfs}
dove si vuole, per usarlo come RAM disk, con un comando del tipo:
\begin{verbatim}
mount -t tmpfs -o size=128M,nr_inodes=10k,mode=700 tmpfs /mytmpfs
projects / gapil.git / blobdiff