\macro{ENFILE} e \macro{EFAULT}.}
\end{prototype}
-La funzione restituisce la coppia di file descriptor nell'array
+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
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
+ all'interno di una pagina HTML.} per Apache, che genera una immagine JPEG
di un codice a barre, specificato come parametro di input.
Un programma che deve essere eseguito come \textit{CGI} deve rispondere a
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 eseguela conversione con \cmd{gs} su
+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 \macro{ESPIPE}, rendendo impossibile la conversione. Questo ci dice che in
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
-deadlock.\footnote{se si cerca di leggere da una fifo che non contiene dati si
+situazioni di stallo.\footnote{se si cerca di leggere da una fifo che non contiene dati si
avrà un deadlock immediato, dato che il processo si blocca e non potrà
quindi mai eseguire le funzioni di scrittura.}
Per risolvere questo problema, si può usare un'architettura come quella
illustrata in \figref{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'occazione.
+server a ciascuno di essi su una fifo temporanea creata per l'occasione.
\begin{figure}[htb]
\centering
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, ma lasciando la fifo comunque aperta anche in scrittura,
-cosicchè le successive possano bloccarsi.
+cosicché le successive possano bloccarsi.
A questo punto si può entrare nel ciclo principale del programma che fornisce
le risposte ai client (\texttt{\small 34--50}), che viene eseguito
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 invaire, si procederà (\texttt{\small 42--46})
+ricavare la frase da inviare, si procederà (\texttt{\small 42--46})
all'apertura della fifo per la risposta, che \texttt{\small 47--48}) poi vi
sarà scritta. Infine (\texttt{\small 49}) si chiude la fifo di risposta che
non serve più.
(\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, pe questo
-prima si apre la fifo nota (\texttt{\small 19--23}), e poi ci si scrive
+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}).
Gli oggetti usati nel System V IPC vengono creati direttamente dal kernel, e
sono accessibili solo specificando il relativo \textsl{identificatore}. Questo
è un numero progressivo (un po' come il \acr{pid} dei processi) che il kernel
-assegna a ciascuno di essi quanto vengono creati (sul prodedimento di
+assegna a ciascuno di essi quanto vengono creati (sul procedimento di
assegnazione torneremo in \secref{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
come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
sono \textsl{parenti} 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'idenficatore così ottenuto sarà
+nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà
disponibile in tutti i figli, e potrà essere passato come parametro 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 è
-possibile; si potebbe comunque salvare l'identificatore su un file noto, ma
+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
la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
con i 16 bit meno significativi dell'inode del file \param{pathname} (che
vengono ottenuti attraverso \func{stat}, da cui derivano i possibili errori),
-e gli 8 bit meno significativi del numero del device su cui è il file. Diventa
-perciò relativamente facile ottenere delle collisioni, specie se i file sono
-su dispositivi con lo stesso \textit{minor number}, come \file{/dev/hda1} e
-\file{/dev/sda1}.
+e gli 8 bit meno significativi del numero del dispositivo su cui è il file.
+Diventa perciò relativamente facile ottenere delle collisioni, specie se i
+file sono su dispositivi con lo stesso \textit{minor number}, come
+\file{/dev/hda1} e \file{/dev/sda1}.
In genere quello che si fa è utilizzare un file comune usato dai programmi che
devono comunicare (ad esempio un haeder comune, o uno dei programmi che devono
-usare l'oggetto in questione), utilizzando il numero di progetto per ottere le
-chiavi che interessano. In ogni caso occorre sempre controllare, prima di
+usare l'oggetto in questione), utilizzando il numero di progetto per ottenere
+le chiavi che interessano. In ogni caso occorre sempre controllare, prima di
creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
bene in fase di creazione, le cose possono complicarsi per i programmi che
devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
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 amministatore l'accesso è sempre
+\item se il processo ha i privilegi di amministratore l'accesso è sempre
consentito.
\item se l'userid effettivo del processo corrisponde o al valore del campo
\var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
Quando il sistema si avvia, alla creazione di ogni nuovo oggetto di IPC viene
assegnato un numero progressivo, pari al numero di oggetti di quel tipo
-esistenti. Se il comportamente fosse sempre questo sarebbe identico a quello
+esistenti. Se il comportamento fosse sempre questo sarebbe identico a quello
usato nell'assegnazione dei file descriptor nei processi, ed i valori degli
identificatori tenderebbero ad essere riutilizzati spesso e restare di piccole
-dimensioni (inferiori al numero massimo di oggetti diponibili).
+dimensioni (inferiori al numero massimo di oggetti disponibili).
Questo va benissimo nel caso dei file descriptor, che sono locali ad un
processo, ma qui il comportamento varrebbe per tutto il sistema, e per
in caso di errore, nel qual caso \var{errno} viene settato ad uno dei
valori:
\begin{errlist}
- \item[\macro{EACCES}] Il processo chiamante non ha i provilegi per accedere
+ \item[\macro{EACCES}] Il processo chiamante non ha i privilegi per accedere
alla coda richiesta.
\item[\macro{EEXIST}] Si è richiesta la creazione di una coda che già
esiste, ma erano specificati sia \macro{IPC\_CREAT} che \macro{IPC\_EXCL}.
successo solo se l'oggetto non esiste già, fallendo con un errore di
\macro{EEXIST} altrimenti.
-Una coda di messaggi è costituita da una \textit{linked list}\footnote{una
+Si tenga conto che l'uso di \macro{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)
+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 \macro{IPC\_PRIVATE} o macro{IPC\_CREAT} e
+\macro{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{Significato} \\
+ \hline
+ \hline
+ \macro{MSGMNI}& 16& \file{msgmni} & Numero massimo di code di
+ messaggi. \\
+ \macro{MSGMAX}& 8192& \file{msgmax} & Dimensione massima di un singolo
+ messaggio.\\
+ \macro{MSGMNB}&16384& \file{msgmnb} & Dimensione massima del contenuto di
+ una coda.\\
+ \hline
+ \end{tabular}
+ \caption{Valori delle costanti associate ai limiti delle code di messaggi.}
+ \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
+\tabref{tab:ipc_msg_limits}, come accennato però in Linux è possibile
+modificare questi limiti attraverso l'uso di \func{syscntl} o scrivendo nei
+file \file{msgmax}, \file{msgmnb} e \file{msgmni} di \file{/proc/sys/kernel/}.
+
+
+\begin{figure}[htb]
+ \centering \includegraphics[width=15cm]{img/mqstruct}
+ \caption{Schema della struttura di una coda messaggi.}
+ \label{fig:ipc_mq_schema}
+\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.} in cui nuovi messaggi vengono
-inseriti in coda per poi essere letti dalla cima, con una struttura del tipo
-di quella illustrata in
+ nell'accesso casuale e nella ricerca.} i nuovi messaggi vengono inseriti in
+coda alla lista e vengono letti dalla cima, in \figref{fig:ipc_mq_schema} si è
+riportato lo schema con cui queste strutture vengono mantenute dal
+kernel.\footnote{lo schema illustrato in figura è in realtà una semplificazione
+ di quanto usato fino ai kernel della serie 2.2.x, nei kernel della serie
+ 2.4.x la gestione è effettuata in maniera diversa; ma esso illustra comunque
+ in maniera adeguata i principi di funzionamento delle code di messaggi.}
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}
+struct msqid_ds {
+ struct ipc_perm msg_perm; /* structure for operation permission */
+ time_t msg_stime; /* time of last msgsnd command */
+ time_t msg_rtime; /* time of last msgrcv command */
+ time_t msg_ctime; /* time of last change */
+ msgqnum_t msg_qnum; /* number of messages currently on queue */
+ msglen_t msg_qbytes; /* max number of bytes allowed on queue */
+ pid_t msg_lspid; /* pid of last msgsnd() */
+ pid_t msg_lrpid; /* pid of last msgrcv() */
+ struct msg *msg_first; /* first message on queue, unused */
+ struct msg *msg_last; /* last message in queue, unused */
+ unsigned long int msg_cbytes; /* current number of bytes on queue */
+};
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \var{msgid\_ds}, associata a ciascuna coda di
+ messaggi.}
+ \label{fig:ipc_msgid_sd}
+\end{figure}
-Si tenga conto che l'uso di \macro{IPC\_PRIVATE} non impedisce ad altri
-processi di accedere alla coda (se hanno privilegi sufficienti) una volta che
-questi possano indovinare o ricavare l'identificatore ad essa associato. Per
-la loro implementazione non esiste cioè una maniera che garantisca l'accesso
-esclusivo ad una coda di messaggi. Usare \macro{IPC\_PRIVATE} o
-macro{IPC\_CREAT} e \macro{IPC\_EXCL} per \param{flag} comporta solo la
-creazione di una nuova coda.
+A ciascuna coda è associata una struttura \var{msgid\_ds}, la cui definizione
+è riportata in \secref{fig:ipc_msgid_sd}, il significato dei vari campi è
+riportato nella figura. In questa struttura il kernel\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. In \figref{fig:ipc_msgid_sd} sono elencati i
+ campi significativi definiti in \file{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.} mantiene le principali informazioni
+riguardo lo stato corrente della coda. 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
+\secref{sec:ipc_sysv_access_control}, per quanto riguarda gli altri campi
+invece:
+\begin{itemize}
+\item il campo \var{msg\_qnum}, che esprime il numero di messaggi presenti
+ sulla coda, viene inizializzato a 0.
+\item i campi \var{msg\_lspid} e \var{msg\_lrpid}, che esprimono
+ rispettivamente il \acr{pid} dell'ultimo processo che ha inviato o ricevuto
+ un messaggio sulla coda, sono inizializzati a 0.
+\item i campi \var{msg\_stime} e \var{msg\_rtime}, che esprimono
+ rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo
+ messaggio sulla coda, sono inizializzati a 0.
+\item il campo \var{msg\_ctime} viene inizializzato al tempo corrente.
+\item il campo \var{msg\_qbytes} viene inizializzato al valore preimpostato
+ del sistema (\macro{MSGMNB}).
+\item i campi \var{msg\_first} e \var{msg\_last} che esprimono l'indirizzo del
+ primo e ultimo messaggio sono inizializzati a \macro{NULL} e
+ \var{msg\_cbytes}, che esprime la dimensione in byte dei messaggi presenti è
+ inizializzato a zero. Questi campi sono ad uso interno dell'implementazione
+ e non devono essere utilizzati da programmi in user space).
+\end{itemize}
-Le code di messaggi sono caratterizzate da tre limiti
+Una volta creata una coda di messaggi le operazioni di controllo vengono
+effettuate con la funzione \func{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} viene settato a:
+ \begin{errlist}
+ \item[\macro{EACCES}] Si è richiesto \macro{IPC\_STAT} ma processo chiamante
+ non ha i privilegi di lettura sulla coda.
+ \item[\macro{EIDRM}] La coda richiesta è marcata per essere cancellata.
+ \item[\macro{EPERM}] Si è richiesto \macro{IPC\_SET} o \macro{IPC\_RMID} ma
+ il processo non ha i privilegi, o si è richiesto di aumentare il valore di
+ \var{msg\_qbytes} oltre il limite \macro{MSGMNB} senza essere
+ amministratore.
+ \end{errlist}
+ ed inoltre \macro{EFAULT} ed \macro{EINVAL}.
+}
+\end{functions}
-Una volta creata una coda di messaggi se ne può controllare
+La funzione permette di accedere ai valori della struttura \var{msqid\_ds},
+mantenuta all'indirizzo \param{buf}, per la coda specificata
+dall'identificatore \param{msqid}. Il comportamento della funzione dipende dal
+valore dell'argomento \param{cmd}, che specifica il tipo di azione da
+eseguire; i valori possibili sono:
+\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
+\item[\macro{IPC\_STAT}] Legge le informazioni riguardo la coda nella
+ struttura indicata da \param{buf}. Occorre avere il permesso di lettura
+ sulla coda.
+\item[\macro{IPC\_RMID}] Rimuove la coda, cancellando tutti i dati, con
+ effetto immediato. Tutti i processi che cercheranno di accedere alla coda
+ riceveranno un errore di \macro{EIDRM}, e tutti processi in attesa su
+ funzioni di di lettura o di scrittura sulla coda saranno svegliati ricevendo
+ il medesimo errore. Questo comando può essere eseguito solo da un processo
+ con userid effettivo corrispondente al creatore a o al proprietario della
+ coda, o all'amministratore.
+\item[\macro{IPC\_SET}] Permette di modificare i permessi ed il proprietario
+ della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in
+ essa contenuti (\var{msg\_qbytes}). I valori devono essere passati in una
+ struttura \var{msqid\_ds} puntata da \param{buf}. Per modificare i valori
+ di \var{msg\_perm.mode}, \var{msg\_perm.uid} e \var{msg\_perm.gid} occorre
+ essere il proprietario o il creatore della coda, oppure l'amministratore; lo
+ stesso vale per \var{msg\_qbytes}, ma l'amministratore ha la facoltà di
+ incrementarne il valore a limiti superiori a \macro{MSGMNB}.
+\end{basedescript}
+
+
+Una volta che si abbia a disposizione l'identificatore, per inviare un
+messaggio su una coda si utilizza la funzione \func{msgsnd}; il suo prototipo
+è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/ipc.h}
+ \headdecl{sys/msg.h}
+
+ \funcdecl{int msgsnd(int msqid, struct msgbuf *msgp, size\_t msgsz, int
+ msgflg)}
+
+ Invia un messaggio sulla coda \param{msqid}.
+
+ \bodydesc{La funzione restituisce 0, e -1 in caso di errore, nel qual caso
+ \var{errno} viene settata a:
+ \begin{errlist}
+ \item[\macro{EACCES}] Non si hanno i privilegi di accesso sulla coda.
+ \item[\macro{EIDRM}] La coda è stata cancellata.
+ \item[\macro{EAGAIN}] Il messaggio non può essere inviato perché si è
+ superato il limite \var{msg\_qbytes} sul numero massimo di byte presenti
+ sulla coda, e si è richiesto \macro{IPC\_NOWAIT} in \param{flag}.
+ \item[\macro{EINTR}] La funzione è stata interrotta da un segnale.
+ \item[\macro{EINVAL}] Si è specificato un \param{msgid} invalido, o un
+ valore non positivo per \param{mtype}, o un valore di \param{msgsz}
+ maggiore di \macro{MSGMAX}.
+ \end{errlist}
+ ed inoltre \macro{EFAULT} ed \macro{ENOMEM}.
+}
+\end{functions}
+
+La funzione inserisce il messaggio sulla coda specificata da \param{msqid}; il
+messaggio ha lunghezza specificata da \param{msgsz} ed è passato attraverso
+l'argomento \param{msgp}. Quest'ultimo deve venire passato sempre in una
+forma che corrisponda alla struttura \var{msgbuf} riportata in
+\figref{fig:ipc_msbug}. La dimensione massima per il testo di un messaggio
+non può comunque superare il limite \macro{MSGMAX}.
+
+La struttura di \figref{fig:ipc_msbug} comunque è solo un modello, tanto che
+la definizione contenuta in \file{sys/msg.h} usa esplicitamente per il secondo
+campo il valore \code{mtext[1]}, che non è di nessuna utilità ai fini pratici.
+La sola cosa che conta è che abbia come primo membro un campo \var{mtype},
+come nell'esempio; esso infatti serve ad identificare il tipo di messaggio e
+deve essere sempre specificato come intero positivo. Il campo \var{mtext}
+invece può essere di qualsiasi tipo e dimensione, e deve contenere il testo
+del messaggio.
+
+In generale pertanto per inviare un messaggio con \func{msgsnd} si usa
+ridefinire una struttura simile a quella di \figref{fig:ipc_msbug}, adattando
+alle proprie esigenze il campo \var{mtype}, (o ridefinendo come si vuole il
+corpo del messaggio, anche con più campi o con strutture più complesse) avendo
+però la cura di mantenere nel primo campo un valore di tipo \ctyp{long} che ne
+indica il tipo.
+
+Si tenga presente che la lunghezza che deve essere indicata in questo
+argomento è solo quella del messaggio, non quella di tutta la struttura, se
+cioè \var{message} è una propria struttura che si passa alla funzione,
+\param{msgsz} dovrà essere uguale a \code{sizeof(message)-sizeof(long)}, (se
+consideriamo il caso dell'esempio in \figref{fig:ipc_msbug}, \param{msgsz}
+dovrà essere pari a \macro{LENGHT}).
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}
+ struct msgbuf {
+ long mtype; /* message type, must be > 0 */
+ char mtext[LENGTH]; /* message data */
+ };
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{Schema della struttura \var{msgbug}, da utilizzare come argomento
+ per inviare/ricevere messaggi.}
+ \label{fig:ipc_msbug}
+\end{figure}
+
+Per capire meglio il funzionamento della funzione riprendiamo in
+considerazione la struttura della coda illustrata in
+\secref{fig:ipc_mq_schema}. Alla chiamata di \func{msgsnd} il nuovo messaggio
+sarà aggiunto in fondo alla lista inserendo una nuova struttura \var{msg}, il
+puntatore \var{msg\_last} di \var{msqid\_ds} verrà aggiornato, come pure il
+puntatore al messaggio successivo per quello che era il precedente ultimo
+messaggio; il valore di \var{mtype} verrà mantenuto in \var{msg\_type} ed il
+valore di \param{msgsz} in \var{msg\_ts}; il testo del messaggio sarà copiato
+all'indirizzo specificato da \var{msg\_spot}.
+
+Il valore dell'argomento \param{flag} permette di specificare il comportamento
+della funzione. Di norma, quando si specifica un valore nullo, la funzione
+ritorna immediatamente a meno che si sia ecceduto il valore di
+\var{msg\_qbytes}, o il limite di sistema sul numero di messaggi, nel qual
+caso si blocca mandando il processo in stato di \textit{sleep}. Se si
+specifica per \param{flag} il valore \macro{IPC\_NOWAIT} la funzione opera in
+modalità non bloccante, ed in questi casi ritorna immediatamente con un errore
+di \macro{EAGAIN}.
+
+Se non si specifica \macro{IPC\_NOWAIT} la funzione resterà bloccata fintanto
+che non si liberano risorse sufficienti per poter inserire nella coda il
+messaggio, nel qual caso ritornerà normalmente. La funzione può ritornare, con
+una condizione di errore anche in due altri casi: quando la coda viene rimossa
+(nel qual caso si ha un errore di \macro{EIDRM}) o quando la funzione viene
+interrotta da un segnale (nel qual caso si ha un errore di \macro{EINTR}).
+
+Una volta completato con successo l'invio del messaggio sulla coda, la
+funzione aggiorna i dati mantenuti in \var{msqid\_ds}, in particolare vengono
+modificati:
+\begin{itemize}
+\item Il valore di \var{msg\_lspid}, che viene impostato al \acr{pid} del
+ processo chiamante.
+\item Il valore di \var{msg\_qnum}, che viene incrementato di uno.
+\item Il valore \var{msg\_stime}, che viene impostato al tempo corrente.
+\end{itemize}
+
+
+La funzione che permette di estrarre da una coda un messaggio (che sarà
+rimosso dalla stessa) è \func{msgrcv}; il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/ipc.h}
+ \headdecl{sys/msg.h}
+
+ \funcdecl{ssize\_t msgrcv(int msqid, struct msgbuf *msgp, size\_t msgsz,
+ long msgtyp, int msgflg)}
+
+ Legge un messaggio dalla coda \param{msqid}.
+
+ \bodydesc{La funzione restituisce il numero di byte letti in caso di
+ successo, e -1 in caso di errore, nel qual caso \var{errno} viene settata
+ a:
+ \begin{errlist}
+ \item[\macro{EACCES}] Non si hanno i privilegi di accesso sulla coda.
+ \item[\macro{EIDRM}] La coda è stata cancellata.
+ \item[\macro{E2BIG}] Il testo del messaggio è più lungo di \param{msgsz} e
+ non si è specificato \macro{MSG\_NOERROR} in \param{msgflg}.
+ \item[\macro{EINTR}] La funzione è stata interrotta da un segnale mentre era
+ in attesa di ricevere un messaggio.
+ \item[\macro{EINVAL}] Si è specificato un \param{msgid} invalido o un valore
+ di \param{msgsz} negativo.
+ \end{errlist}
+ ed inoltre \macro{EFAULT}.
+}
+\end{functions}
+
+La funzione legge un messaggio dalla coda specificata scrivendolo nel buffer
+indicato da \param{msgp}, che avrà un formato analogo a quello di
+\figref{fig:ipc_msbug}. L'argomento \param{msgsz} indica la lunghezza massima
+del testo del messaggio (equivalente al valore del parametro \macro{LENGHT}
+nell'esempio di \figref{fig:ipc_msbug}).
+
+Se il testo del messaggio ha lunghezza inferiore a \param{msgsz} esso viene
+rimosso dalla coda; in caso contrario, se \param{msgflg} è impostato a
+\macro{MSG\_NOERROR}, il messaggio viene troncato e la parte in eccesso viene
+perduta, altrimenti il messaggio non viene estratto e la funzione ritorna con
+un errore di \macro{E2BIG}.
+
+L'argomento \param{msgtyp} permette di restringere la ricerca ad un
+sottoinsieme dei messaggi presenti sulla coda; la ricerca infatti è fatta con
+una scansione della struttura mostrata in \figref{fig:ipc_mq_schema},
+restituendo il primo messaggio incontrato che corrisponde ai criteri
+specificati (che quindi, visto che i messaggi vengono sempre inseriti dalla
+coda, è quello meno recente); in particolare:
+\begin{itemize}
+\item se \param{msgtyp} è 0 viene estratto il messaggio in cima alla coda, cioè
+ quello fra i presenti che è stato inserito inserito per primo.
+\item se \param{msgtyp} è positivo viene estratto il primo messaggio il cui
+ tipo (il valore del campo \var{mtype}) corrisponde al valore di
+ \param{msgtyp}.
+\item se \param{msgtyp} è negativo viene estratto il primo fra i messaggi con
+ il tipo di valore più basso, fra tutti quelli con un tipo inferiore al
+ valore assoluto di \param{msgtyp}.
+\end{itemize}
+
+Il valore di \param{msgflg} permette di controllare il comportamento della
+funzione, esso può essere nullo o una maschera binaria composta da uno o più
+valori. Oltre al precedente \macro{MSG\_NOERROR}, sono possibili altri due
+valori: \macro{MSG\_EXCEPT}, che permette, quando \param{msgtyp} è positivo,
+di leggere il primo messaggio nella coda con tipo diverso da \param{msgtyp}, e
+\macro{IPC\_NOWAIT} che causa il ritorno immediato della funzione quando non
+ci sono messaggi sulla coda.
+
+Il comportamento usuale della funzione infatti, se non ci sono messaggi
+disponibili per la lettura, è di bloccare il processo in stato di
+\textit{sleep}. Nel caso però si sia specificato \macro{IPC\_NOWAIT} la
+funzione ritorna immediatamente con un errore \macro{ENOMSG}. Altrimenti la
+funzione ritorna normalmente non appena viene inserito un messaggio del tipo
+desiderato, oppure ritorna con errore qualora la coda sia rimossa (con
+\var{errno} settata a \macro{EIDRM}) o se il processo viene interrotto da un
+segnale (con \var{errno} settata a \macro{EINTR}).
+
+Una volta completata con successo l'estrazione del messaggio dalla coda, la
+funzione aggiorna i dati mantenuti in \var{msqid\_ds}, in particolare vengono
+modificati:
+\begin{itemize}
+\item Il valore di \var{msg\_lrpid}, che viene impostato al \acr{pid} del
+ processo chiamante.
+\item Il valore di \var{msg\_qnum}, che viene decrementato di uno.
+\item Il valore \var{msg\_rtime}, che viene impostato al tempo corrente.
+\end{itemize}
+
+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 coda di messaggi, usando il \acr{pid} del client come valore per
+il tipo di messaggio, per restituire indietro le frasi ai client.
Il secondo oggetto introdotto dal \textit{System V IPC} è quello dei semafori.
Un semaforo è uno speciale contatore che permette di controllare l'accesso a
-risorse condivise. La funzione che permette di ottenere un insieme di semafori
-è \func{semget} ed il suo prototipo è:
+risorse condivise. La funzione che permette di creare o ottenere
+l'identificatore di un insieme di semafori è \func{semget}, ed il suo prototipo
+è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/ipc.h}
\funcdecl{int semget(key\_t key, int nsems, int flag)}
- Restituisce l'identificatore di un semaforo.
+ Restituisce l'identificatore di un insieme di semafori.
\bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
in caso di errore, nel qual caso \var{errno} viene settato agli stessi
La funzione è del tutto analoga a \func{msgget} ed identico è l'uso degli
argomenti \param{key} e \param{flag}, per cui non ripeteremo quanto detto al
proposito in \secref{sec:ipc_sysv_mq}. L'argomento \param{nsems} permette di
-specificare quanti semfori deve contenere l'insieme qualora se ne richieda la
+specificare quanti semafori deve contenere l'insieme qualora se ne richieda la
creazione, e deve essere nullo quando si effettua una richiesta
dell'identificatore di un insieme già esistente.
+A ciascun insieme di semafori è associata una struttura \var{semid\_ds},
+riportata in \figref{fig:ipc_semid_sd}, come nel caso delle code di messaggi
+quando si crea un nuovo insieme di semafori con \func{semget} questa struttura
+viene inizializzata, in particolare il campo \var{sem\_perm} viene
+inizializzato come illustrato in \secref{sec:ipc_sysv_access_control}, per
+quanto riguarda gli altri campi invece:
+\begin{itemize*}
+\item il campo \var{sem\_nsems}, che esprime il numero di semafori
+ nell'insieme, viene inizializzato al valore di \param{nsems}.
+\item il campo \var{sem\_ctime}, che esprime il tempo di creazione
+ dell'insieme, viene inizializzato al tempo corrente
+\item il campo \var{sem\_otime}, che esprime il tempo dell'ultima operazione
+ effettuata, viene inizializzato a zero.
+\end{itemize*}
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}
+struct semid_ds
+{
+ struct ipc_perm sem_perm; /* operation permission struct */
+ time_t sem_otime; /* last semop() time */
+ time_t sem_ctime; /* last time changed by semctl() */
+ unsigned long int sem_nsems; /* number of semaphores in set */
+};
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \var{semid\_ds}, associata a ciascun insieme di
+ semafori.}
+ \label{fig:ipc_semid_sd}
+\end{figure}
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|c|r|l|l|}
+ \hline
+ \textbf{Costante} & \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \macro{SEMMNI}& 16& Numero massimo di insiemi di semafori. \\
+ \macro{SEMMAX}& 8192& .\\
+ \macro{SEMMNB}&16384& .\\
+ \hline
+ \end{tabular}
+ \caption{Valori delle costanti associate ai limiti degli insiemi di
+ semafori.}
+ \label{tab:ipc_sem_limits}
+\end{table}
\subsection{Memoria condivisa}
projects / gapil.git / blobdiff