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
+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
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
+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 parametro di input.
+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?parametro
+ 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
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
-evidente \textit{race condition}\index{\textit{race~condition}} in caso di
-accesso simultaneo a detto file.\footnote{il problema potrebbe essere superato
+evidente \textit{race condition}\itindex{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 le cose non sarebbero più tanto semplici.}
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
+risultato dell'elaborazione del precedente, benché quest'ultimo venga invocato
dopo.
\begin{figure}[!htb]
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 deadlock\index{\textit{deadlock}} immediato, dato che il processo si
- blocca e non potrà quindi mai eseguire le funzioni di scrittura.}
+ avrà un deadlock\itindex{deadlock} immediato, dato che il processo si blocca
+ e non potrà quindi mai eseguire le funzioni di scrittura.}
Per la loro caratteristica di essere accessibili attraverso il filesystem, è
piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
occorrerà definire la speciale variabile di ambiente \code{LD\_LIBRARY\_PATH}
in modo che il linker dinamico possa accedervi.
-In generale questa variabile indica il
-\index{\textit{pathname}}\textit{pathname} della directory contenente la
-libreria. Nell'ipotesi (che daremo sempre per verificata) che si facciano le
-prove direttamente nella directory dei sorgenti (dove di norma 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:
+In generale questa variabile indica il \itindex{pathname}\textit{pathname}
+della directory contenente la libreria. Nell'ipotesi (che daremo sempre per
+verificata) che si facciano le prove direttamente nella directory dei sorgenti
+(dove di norma 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}
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
-sull'altro e viceversa. I parametri \param{domain}, \param{type} e
-\param{protocol} derivano dall'interfaccia dei socket\index{socket} (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}.
+sull'altro e viceversa. Gli argomenti \param{domain}, \param{type} e
+\param{protocol} derivano dall'interfaccia dei socket\index{socket} (vedi
+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}.
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
Usando la stessa chiave due processi diversi possono ricavare l'identificatore
associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
-sono \textsl{parenti} la soluzione è relativamente semplice, in tal caso
+sono \textsl{imparentati} la soluzione è relativamente semplice, in tal caso
infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
-disponibile in tutti i figli, e potrà essere passato come parametro attraverso
+disponibile in tutti i figli, e potrà essere passato come argomento attraverso
una \func{exec}.
-Però quando i processi non sono \textsl{parenti} (come capita tutte le volte
-che si ha a che fare con un sistema client-server) tutto questo non è
+Però quando i processi non sono \textsl{imparentati} (come capita tutte le
+volte che si ha a che fare con un sistema client-server) tutto questo non è
possibile; si potrebbe comunque salvare l'identificatore su un file noto, ma
questo ovviamente comporta lo svantaggio di doverselo andare a rileggere. Una
alternativa più efficace è quella che i programmi usino un valore comune per
\end{functions}
La funzione determina un valore della chiave sulla base di \param{pathname},
-che deve specificare il \index{\textit{pathname}}\textit{pathname} di un file
+che deve specificare il \itindex{pathname}\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
il proprietario, il suo gruppo e tutti gli altri.
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 settati
-rispettivamente al valore dell'user-ID e del group-ID effettivo del processo che
-ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
+\struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono impostati
+rispettivamente al valore dell'user-ID e del group-ID effettivo del processo
+che ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
Il controllo di accesso è effettuato a due livelli. Il primo livello è nelle
\item se l'user-ID 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 è
- settato il permesso di scrittura per le operazioni di scrittura e quello
+ impostato il permesso di scrittura per le operazioni di scrittura e quello
di lettura per le operazioni di lettura.} l'accesso è consentito.
\item se il group-ID effettivo del processo corrisponde o al
valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
\end{figure}
-Una coda di messaggi è costituita da una \textit{linked list};\footnote{una
- \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.}
+Una coda di messaggi è costituita da una \itindex{linked~list}\textit{linked
+ list};\footnote{una \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.}
\begin{figure}[!htb]
\footnotesize \centering
funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di
una di queste strutture alla volta; ad esempio non si può scrivere un server
che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica
-di \textit{polling}\index{\textit{polling}} che esegua un ciclo di attesa su
+di \textit{polling}\itindex{polling} che esegua un ciclo di attesa su
ciascuna di esse.
Come esempio dell'uso delle code di messaggi possiamo riscrivere il nostro
}
\end{functions}
-La funzione può avere tre o quattro parametri, a seconda dell'operazione
+La funzione può avere tre o quattro argomenti, a seconda dell'operazione
specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
\param{semid} o sul singolo semaforo di un insieme, specificato da
\param{semnum}.
fig.~\ref{fig:ipc_semun}.
Come già accennato sia il comportamento della funzione che il numero di
-parametri con cui deve essere invocata, dipendono dal valore dell'argomento
+argomenti con cui deve essere invocata dipendono dal valore dell'argomento
\param{cmd}, che specifica l'azione da intraprendere; i valori validi (che
cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i
seguenti:
Nella struttura viene memorizzato il riferimento alle operazioni richieste
(nel campo \var{sops}, che è un puntatore ad una struttura \struct{sembuf}) e
al processo corrente (nel campo \var{sleeper}) poi quest'ultimo viene messo
-stato di attesa e viene invocato lo scheduler\index{\textit{scheduler}} per
-passare all'esecuzione di un altro processo.
+stato di attesa e viene invocato lo scheduler\itindex{scheduler} per passare
+all'esecuzione di un altro processo.
Se invece tutte le operazioni possono avere successo queste vengono eseguite
immediatamente, dopo di che il kernel esegue una scansione della coda di
\const{IPC\_RMID} senza i permessi necessari.
\item[\errcode{EOVERFLOW}] Si è tentato il comando \const{IPC\_STAT} ma il
valore del group-ID o dell'user-ID è troppo grande per essere
- memorizzato nella struttura puntata dal \param{buf}.
+ memorizzato nella struttura puntata da \param{buf}.
\item[\errcode{EFAULT}] L'indirizzo specificato con \param{buf} non è
valido.
\end{errlist}
il creatore del segmento, oppure l'amministratore. Compiuta l'operazione
aggiorna anche il valore del campo \var{shm\_ctime}.
\item[\const{SHM\_LOCK}] Abilita il \textit{memory
- locking}\index{\textit{memory~locking}}\footnote{impedisce cioè che la
- memoria usata per il segmento venga salvata su disco dal meccanismo della
- memoria virtuale\index{memoria~virtuale}; si ricordi quanto trattato in
+ locking}\itindex{memory~locking}\footnote{impedisce cioè che la memoria
+ usata per il segmento venga salvata su disco dal meccanismo della memoria
+ virtuale\index{memoria~virtuale}; si ricordi quanto trattato in
sez.~\ref{sec:proc_mem_lock}.} sul segmento di memoria condivisa. Solo
l'amministratore può utilizzare questo comando.
\item[\const{SHM\_UNLOCK}] Disabilita il \textit{memory
- locking}\index{\textit{memory~locking}} sul segmento di memoria condivisa.
- Solo l'amministratore può utilizzare questo comando.
+ locking}\itindex{memory~locking} sul segmento di memoria condivisa. Solo
+ l'amministratore può utilizzare questo comando.
\end{basedescript}
i primi tre comandi sono gli stessi già visti anche per le code di messaggi e
gli insiemi di semafori, gli ultimi due sono delle estensioni specifiche
fig.~\ref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si
ricordi quanto illustrato al proposito in sez.~\ref{sec:proc_mem_layout}). In
particolare l'indirizzo finale del segmento dati (quello impostato da
-\func{brk}, vedi sez.~\ref{sec:proc_mem_sbrk}) non viene influenzato. Si tenga
-presente infine che la funzione ha successo anche se il segmento è stato
-marcato per la cancellazione.
+\func{brk}, vedi sez.~\ref{sec:proc_mem_sbrk_alloca}) non viene influenzato.
+Si tenga presente infine che la funzione ha successo anche se il segmento è
+stato marcato per la cancellazione.
\begin{figure}[htb]
\centering
\bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di
errore, la funzione fallisce solo quando non c'è un segmento agganciato
- all'indirizzo \func{shmaddr}, con \var{errno} che assume il valore
+ all'indirizzo \param{shmaddr}, con \var{errno} che assume il valore
\errval{EINVAL}.}
\end{functions}
riga di comando (che si limitano alla eventuale stampa di un messaggio di
aiuto a video ed all'impostazione della durata dell'intervallo con cui viene
ripetuto il calcolo delle proprietà della directory) controlla (\texttt{\small
- 20--23}) che sia stato specificato il parametro necessario contenente il
-nome della directory da tenere sotto controllo, senza il quale esce
-immediatamente con un messaggio di errore.
+ 20--23}) che sia stato specificato l'argoemnto necessario contenente il nome
+della directory da tenere sotto controllo, senza il quale esce immediatamente
+con un messaggio di errore.
-Poi, per verificare che il parametro specifichi effettivamente una directory,
+Poi, per verificare che l'argomento specifichi effettivamente una directory,
si esegue (\texttt{\small 24--26}) su di esso una \func{chdir}, uscendo
immediatamente in caso di errore. Questa funzione serve anche per impostare
la directory di lavoro del programma nella directory da tenere sotto
sez.~\ref{sec:file_open}) 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 race
- condition\index{\textit{race~condition}}.} che essa ritorni un errore quando
+ è comunque soggetti alla possibilità di una \textit{race
+ condition}\itindex{race~condition}.} che essa ritorni un errore quando
usata con i flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la
creazione di un \textsl{file di lock} può essere eseguita atomicamente, il
processo che crea il file con successo si può considerare come titolare del
Un esempio dell'uso di questa funzione è mostrato dalle funzioni
\func{LockFile} ed \func{UnlockFile} riportate in fig.~\ref{fig:ipc_file_lock}
-(sono contenute in \file{LockFile.c}, un'altro dei sorgenti allegati alla
+(sono contenute in \file{LockFile.c}, un altro dei sorgenti allegati alla
guida) che permettono rispettivamente di creare e rimuovere un \textsl{file di
lock}. Come si può notare entrambe le funzioni sono elementari; la prima
(\texttt{\small 4--10}) si limita ad aprire il file di lock (\texttt{\small
esistente; se il link esiste già e la funzione fallisce, significa che la
risorsa è bloccata e potrà essere sbloccata solo con un \func{unlink},
altrimenti il link è creato ed il lock acquisito; il controllo e l'eventuale
-acquisizione sono atomici; la soluzione funziona anche su NFS, ma ha un'altro
+acquisizione sono atomici; la soluzione funziona anche su NFS, ma ha un altro
difetto è che è quello di poterla usare solo se si opera all'interno di uno
stesso filesystem.
sincronizzazione: anzitutto in caso di terminazione imprevista del processo,
si lascia allocata la risorsa (il \textsl{file di lock}) e questa deve essere
sempre cancellata esplicitamente. Inoltre il controllo della disponibilità
-può essere eseguito solo con una tecnica di
-\textit{polling}\index{\textit{polling}}, ed è quindi molto inefficiente.
+può essere eseguito solo con una tecnica di \textit{polling}\itindex{polling},
+ed è quindi molto inefficiente.
La tecnica dei file di lock ha comunque una sua utilità, e può essere usata
con successo quando l'esigenza è solo quella di segnalare l'occupazione di una
usare il lock come un \textit{mutex}: per bloccare la risorsa basterà
acquisire il lock, per sbloccarla basterà rilasciare il lock. Una richiesta
fatta con un write lock metterà automaticamente il processo in stato di
-attesa, senza necessità di ricorrere al
-\textit{polling}\index{\textit{polling}} per determinare la disponibilità
-della risorsa, e al rilascio della stessa da parte del processo che la
-occupava si otterrà il nuovo lock atomicamente.
+attesa, senza necessità di ricorrere al \textit{polling}\itindex{polling} per
+determinare la disponibilità della risorsa, e al rilascio della stessa da
+parte del processo che la occupava si otterrà il nuovo lock atomicamente.
Questo approccio presenta il notevole vantaggio che alla terminazione di un
processo tutti i lock acquisiti vengono rilasciati automaticamente (alla
\func{fcntl}, restituendo il valore di ritorno di quest'ultima. Se il file è
libero il lock viene acquisito e la funzione ritorna immediatamente;
altrimenti \func{fcntl} si bloccherà (si noti che la si è chiamata con
-\func{F\_SETLKW}) fino al rilascio del lock.
+\const{F\_SETLKW}) fino al rilascio del lock.
La quarta funzione (\texttt{\small 24--34}) è \func{UnlockMutex} e serve a
rilasciare il mutex. La funzione è analoga alla precedente, solo che in questo
\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ò
nel \textit{memory mapping} anonimo.} Vedremo come utilizzare questa tecnica
più avanti, quando realizzeremo una nuova versione del monitor visto in
sez.~\ref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
-
+\itindend{memory~mapping}
\section{Il sistema di comunicazione fra processi di POSIX}
La caratteristica fondamentale dell'interfaccia POSIX è l'abbandono dell'uso
degli identificatori e delle chiavi visti nel SysV IPC, per passare ai
-\textit{Posix IPC names}\index{\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; lo standard è molto generico riguardo l'implementazione, ed i
-nomi stessi possono avere o meno una corrispondenza sul filesystem; tutto
-quello che è richiesto è che:
+\textit{POSIX IPC names}\itindex{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;
+lo standard è molto generico riguardo l'implementazione, ed i nomi stessi
+possono avere o meno una corrispondenza sul filesystem; tutto quello che è
+richiesto è che:
\begin{itemize}
\item i nomi devono essere conformi alle regole che caratterizzano i
- \index{\textit{pathname}}\textit{pathname}, in particolare non essere più
- lunghi di \const{PATH\_MAX} byte e terminati da un carattere nullo.
+ \itindex{pathname}\textit{pathname}, in particolare non essere più lunghi di
+ \const{PATH\_MAX} byte e terminati da un carattere nullo.
\item se il nome inizia per una \texttt{/} chiamate differenti allo stesso
nome fanno riferimento allo stesso oggetto, altrimenti l'interpretazione del
nome dipende dall'implementazione.
(rispettivamente \file{/dev/shm} e \file{/dev/mqueue}, per i dettagli si
faccia riferimento a sez.~\ref{sec:ipc_posix_shm} e
sez.~\ref{sec:ipc_posix_mq}) ed i nomi specificati nelle relative funzioni
-sono considerati come un \index{\textit{pathname}!assoluto}\textit{pathname}
+sono considerati come un \itindsub{pathname}{assoluto}\textit{pathname}
assoluto (comprendente eventuali sottodirectory) rispetto a queste radici.
Il vantaggio degli oggetti di IPC POSIX è comunque che essi vengono inseriti
Le code di messaggi non sono ancora supportate nel kernel ufficiale, esiste
però una implementazione sperimentale di Michal Wronski e Krzysztof
Benedyczak,\footnote{i patch al kernel e la relativa libreria possono essere
- trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc}
- {http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}, questi sono stati
- inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}. In
+trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc}
+{\textsf{http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}}, questi sono
+stati inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}. In
generale, come le corrispettive del SysV IPC, le code di messaggi sono poco
usate, dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono
più comodi, e che in casi più complessi la comunicazione può essere gestita
di successo e -1 in caso di errore; nel quel caso \var{errno} assumerà i
valori:
\begin{errlist}
- \item[\errcode{EACCESS}] Il processo non ha i privilegi per accedere al
+ \item[\errcode{EACCES}] Il processo non ha i privilegi per accedere al
alla memoria secondo quanto specificato da \param{oflag}.
\item[\errcode{EEXIST}] Si è specificato \const{O\_CREAT} e
\const{O\_EXCL} ma la coda già esiste.
invece la selezione in base al valore del campo \var{mtype}. Qualora non
interessi usare la priorità dei messaggi si
+% TODO vericare questa interruzione di paragrafo
+% TODO inserire i dati di /proc/sys/fs/mqueue
+
Qualora la coda sia vuota entrambe le funzioni si bloccano, a meno che non si
sia selezionata la modalità non bloccante; in tal caso entrambe ritornano
immediatamente con l'errore \errcode{EAGAIN}. Anche in questo caso la sola
POSIX. L'interfaccia corrente è stata stabilizzata a partire dal kernel
2.5.40.
+% TODO vedere se ci sono novità e trattare la cosa.
effetto.} viste in sez.~\ref{sec:file_open}; 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 inode).
-In questo modo è possibile effettuare una chiamata ad \func{mmap} sul file
-descriptor restituito da \func{shm\_open} ed i processi vedranno lo stesso
-segmento di memoria condivisa.
+(così come, nel caso di file di dati, essi sono associati allo stesso
+\index{inode}inode). In questo modo è possibile effettuare una chiamata ad
+\func{mmap} sul file descriptor restituito da \func{shm\_open} ed i processi
+vedranno lo stesso segmento di memoria condivisa.
Quando il nome non esiste il segmento può essere creato specificando
\const{O\_CREAT}; in tal caso il segmento avrà (così come i nuovi file)