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
dell'insieme delle frasi non nulla, dato che l'inizializzazione del vettore
\var{fortune} avviene solo quando questa dimensione viene specificata, la
presenza di un valore nullo provoca l'uscita dal programma attraverso la
-routine (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 comunicare.
+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
+comunicare.
Terminata l'inizializzazione (\texttt{\small 16}) si effettua la chiamata alla
funzione \code{FortuneParse} che legge dal file specificato in
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 routine di chiusura che cancella la fifo).
+modo da passare attraverso la funzione di chiusura che cancella la 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.
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 \textsl{sezioni critiche}\index{sezioni~critiche} del
+di protezione per le \textsl{sezioni critiche} \index{sezione~critica} del
codice (si ricordi quanto detto in sez.~\ref{sec:proc_race_cond}).
Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a
\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}
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.
\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
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}\itindex{Posix~IPC~names}, che sono sostanzialmente
+\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;
+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:
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.
e senza ulteriori \file{/}, Linux supporta comunque nomi generici, che
verranno intepretati prendendo come radice \file{/dev/shm}.\footnote{occorre
pertanto evitare di specificare qualcosa del tipo \file{/dev/shm/nome}
- all'interno di \param{name}, perché questo comporta, da parte delle routine
+ all'interno di \param{name}, perché questo comporta, da parte delle funzioni
di libereria, il tentativo di accedere a \file{/dev/shm/dev/shm/nome}.}
La funzione è del tutto analoga ad \func{open} ed analoghi sono i valori che
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)