X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=48cc7b89ae2b35f627671433bce6fc2ff4b0027c;hp=6bfab48e4e48563d08932b5ea2637f442dbcf754;hb=beece18eba2dcc2a9b915dab61277df8685a3da6;hpb=01f1457fa08fbadba9736d26996f3b7798788952 diff --git a/ipc.tex b/ipc.tex index 6bfab48..48cc7b8 100644 --- a/ipc.tex +++ b/ipc.tex @@ -1,6 +1,6 @@ %% ipc.tex %% -%% Copyright (C) 2000-2013 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2014 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free %% Documentation License, Version 1.1 or any later version published by the %% Free Software Foundation; with the Invariant Sections being "Un preambolo", @@ -200,9 +200,9 @@ 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} +\begin{Example} http://www.sito.it/cgi-bin/programma?argomento -\end{Verbatim} +\end{Example} ed il risultato dell'elaborazione deve essere presentato (con una intestazione che ne descrive il \textit{mime-type}) sullo \textit{standard output}, in modo che il server web possa reinviarlo al browser che ha effettuato la richiesta, @@ -690,9 +690,9 @@ stringa di richiesta dalla \textit{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 inviare, si procederà (\texttt{\small - 42--46}) all'apertura della \textit{fifo} per la risposta, che poi -\texttt{\small 47--48}) vi sarà scritta. Infine (\texttt{\small 49}) si chiude -la \textit{fifo} di risposta che non serve più. + 42--46}) all'apertura della \textit{fifo} per la risposta, che poi +(\texttt{\small 47--48}) vi sarà scritta. Infine (\texttt{\small 49}) si +chiude la \textit{fifo} di risposta che non serve più. Il codice del client è invece riportato in fig.~\ref{fig:ipc_fifo_client}, anche in questo caso si è omessa la gestione delle opzioni e la funzione che @@ -1422,7 +1422,7 @@ file; il suo prototipo è: \var{msg\_qbytes} oltre il limite \const{MSGMNB} senza essere amministratore. \end{errlist} - ed inoltre \errval{EFAULT} ed \errval{EINVAL} nel loro significato + ed inoltre \errval{EFAULT} ed \errval{EINVAL} nel loro significato generico.} \end{funcproto} @@ -1839,7 +1839,6 @@ dei \ids{PID} da parte dei processi, un client eseguito in un momento successivo potrebbe ricevere un messaggio non indirizzato a lui. - \subsection{I semafori} \label{sec:ipc_sysv_sem} @@ -1974,7 +1973,6 @@ quanto riguarda gli altri campi invece: effettuata, viene inizializzato a zero. \end{itemize*} - \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{.80\textwidth} @@ -2079,10 +2077,9 @@ 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}. - \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{.80\textwidth} + \begin{minipage}[c]{0.80\textwidth} \includestruct{listati/semun.h} \end{minipage} \normalsize @@ -2318,7 +2315,7 @@ possa essere ripristinato all'uscita del processo. Infine \var{sem\_op} è il campo che controlla qual'è l'operazione che viene eseguita e determina in generale il comportamento della chiamata a \func{semop}. I casi possibili per il valore di questo campo sono tre: -\begin{basedescript}{\desclabelwidth{2.0cm}} +\begin{basedescript}{\desclabelwidth{1.8cm}} \item[\var{sem\_op} $>0$] In questo caso il valore viene aggiunto al valore corrente di \var{semval} per il semaforo indicato. Questa operazione non causa mai un blocco del processo, ed eventualmente \func{semop} ritorna @@ -2410,7 +2407,7 @@ a queste strutture restano per compatibilità (in particolare con le vecchie versioni delle librerie del C, come le \acr{libc5}). \begin{figure}[!htb] - \centering \includegraphics[width=13cm]{img/semtruct} + \centering \includegraphics[width=12cm]{img/semtruct} \caption{Schema della struttura di un insieme di semafori.} \label{fig:ipc_sem_schema} \end{figure} @@ -2573,19 +2570,45 @@ memoria condivisa. La funzione di sistema che permette di ottenerne uno è già esiste \param{size} è maggiore delle sue dimensioni. \item[\errcode{ENOMEM}] il sistema non ha abbastanza memoria per poter contenere le strutture per un nuovo segmento di memoria condivisa. + \item[\errcode{ENOMEM}] si è specificato \const{IPC\_HUGETLB} ma non si + hanno i privilegi di amministratore. \end{errlist} ed inoltre \errval{EACCES}, \errval{ENOENT}, \errval{EEXIST}, \errval{EIDRM}, con lo stesso significato che hanno per \func{msgget}.} \end{funcproto} -La funzione, come \func{semget}, è 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 sez.~\ref{sec:ipc_sysv_mq}. L'argomento -\param{size} specifica invece la dimensione, in byte, del segmento, che viene -comunque arrotondata al multiplo superiore di \const{PAGE\_SIZE}. - -% TODO aggiungere l'uso di SHM_HUGETLB introdotto con il kernel 2.6.0 +La funzione, come \func{semget}, è analoga a \func{msgget}, ed identico è +l'uso degli argomenti \param{key} e \param{flag} per cui non ripeteremo quanto +detto al proposito in sez.~\ref{sec:ipc_sysv_mq}. A partire dal kernel 2.6 +però sono stati introdotti degli ulteriori bit di controllo per +l'argomento \param{flag}, specifici di \func{shmget}, attinenti alle modalità +di gestione del segmento di memoria condivisa in relazione al sistema della +memoria virtuale. + +Il primo dei due flag è \const{SHM\_HUGETLB} che consente di richiedere la +creazione del segmento usando una \itindex{huge~page} \textit{huge page}, le +pagine di memoria di grandi dimensioni introdotte con il kernel 2.6 per +ottimizzare le prestazioni nei sistemi più recenti che hanno grandi quantità +di memoria. L'operazione è privilegiata e richiede che il processo abbia la +\itindex{capability} \textit{capability} \const{CAP\_IPC\_LOCK}. Questa +funzionalità è specifica di Linux e non è portabile. + +Il secondo flag aggiuntivo, introdotto a partire dal kernel 2.6.15, è +\const{SHM\_NORESERVE}, ed ha lo stesso scopo del flag \const{MAP\_NORESERVE} +di \func{mmap} (vedi sez.~\ref{sec:file_memory_map}): non vengono riservate +delle pagine di swap ad uso del meccanismo del \textit{copy on write} +\itindex{copy~on~write} per mantenere le modifiche fatte sul segmento. Questo +significa che caso di scrittura sul segmento quando non c'è più memoria +disponibile, si avrà l'emissione di un \signal{SIGSEGV}. + +Infine l'argomento \param{size} specifica la dimensione del segmento di +memoria condivisa; il valore deve essere specificato in byte, ma verrà +comunque arrotondato al multiplo superiore di \const{PAGE\_SIZE}. Il valore +deve essere specificato quando si crea un nuovo segmento di memoria con +\const{IPC\_CREAT} o \const{IPC\_PRIVATE}, se invece si accede ad un segmento +di memoria condivisa esistente non può essere maggiore del valore con cui esso +è stato creato. La memoria condivisa è la forma più veloce di comunicazione fra due processi, in quanto permette agli stessi di vedere nel loro spazio di indirizzi una @@ -2607,7 +2630,7 @@ norma, significa insieme a dei semafori. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{\textwidth} + \begin{minipage}[c]{0.80\textwidth} \includestruct{listati/shmid_ds.h} \end{minipage} \normalsize @@ -2624,7 +2647,7 @@ campo \var{shm\_perm} viene inizializzato come illustrato in sez.~\ref{sec:ipc_sysv_access_control}, e valgono le considerazioni ivi fatte relativamente ai permessi di accesso; per quanto riguarda gli altri campi invece: -\begin{itemize} +\begin{itemize*} \item il campo \var{shm\_segsz}, che esprime la dimensione del segmento, viene inizializzato al valore di \param{size}. \item il campo \var{shm\_ctime}, che esprime il tempo di creazione del @@ -2638,7 +2661,7 @@ invece: creato il segmento, viene inizializzato al \ids{PID} del processo chiamante. \item il campo \var{shm\_nattac}, che esprime il numero di processi agganciati al segmento viene inizializzato a zero. -\end{itemize} +\end{itemize*} Come per le code di messaggi e gli insiemi di semafori, anche per i segmenti di memoria condivisa esistono una serie di limiti imposti dal sistema. Alcuni @@ -2679,7 +2702,9 @@ che permettono di cambiarne il valore. pagina di memoria).\\ \const{SHMSEG}& --- & --- & Numero massimo di segmenti di memoria condivisa per ciascun - processo.\\ + processo (l'implementazione non + prevede l'esistenza di questo + limite).\\ \hline @@ -2690,39 +2715,43 @@ che permettono di cambiarne il valore. \label{tab:ipc_shm_limits} \end{table} -Al solito la funzione che permette di effettuare le operazioni di controllo su -un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è: -\begin{functions} - \headdecl{sys/ipc.h} - \headdecl{sys/shm.h} - - \funcdecl{int shmctl(int shmid, int cmd, struct shmid\_ds *buf)} - - Esegue le operazioni di controllo su un segmento di memoria condivisa. - - \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di - errore, nel qual caso \var{errno} assumerà i valori: - \begin{errlist} +Al solito la funzione di sistema che permette di effettuare le operazioni di +controllo su un segmento di memoria condivisa è \funcd{shmctl}; il suo +prototipo è: + +\begin{funcproto}{ +\fhead{sys/ipc.h} +\fhead{sys/shm.h} +\fdecl{int shmctl(int shmid, int cmd, struct shmid\_ds *buf)} + +\fdesc{Esegue le operazioni di controllo su un segmento di memoria condivisa.} +} + +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà uno dei valori: + \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 - \param{cmd} non è un comando valido. + \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è + valido. \item[\errcode{EIDRM}] l'argomento \param{shmid} fa riferimento ad un segmento che è stato cancellato. - \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o - \const{IPC\_RMID} senza i permessi necessari. + \item[\errcode{EINVAL}] o \param{shmid} non è un identificatore valido o + \param{cmd} non è un comando valido. + \item[\errcode{ENOMEM}] si è richiesto un \textit{memory lock} di + dimensioni superiori al massimo consentito. \item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il valore del \ids{GID} o dell'\ids{UID} è troppo grande per essere memorizzato nella struttura puntata da \param{buf}. - \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è - valido. - \end{errlist} -} -\end{functions} + \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o + \const{IPC\_RMID} senza i permessi necessari. + \end{errlist} +} +\end{funcproto} Il comando specificato attraverso l'argomento \param{cmd} determina i diversi -effetti della funzione; i possibili valori che esso può assumere, ed il -corrispondente comportamento della funzione, sono i seguenti: +effetti della funzione. Nello standard POSIX.1-2001 i valori che esso può +assumere, ed il corrispondente comportamento della funzione, sono i seguenti: \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}} \item[\const{IPC\_STAT}] Legge le informazioni riguardo il segmento di memoria @@ -2738,20 +2767,35 @@ corrispondente comportamento della funzione, sono i seguenti: \var{shm\_perm.uid} e \var{shm\_perm.gid} occorre essere il proprietario o il creatore del segmento, oppure l'amministratore. Compiuta l'operazione aggiorna anche il valore del campo \var{shm\_ctime}. +\end{basedescript} + +Oltre ai precedenti su Linux sono definiti anche degli ulteriori comandi, che +consentono di estendere le funzionalità, ovviamente non devono essere usati se +si ha a cuore la portabilità. Questi comandi aggiuntivi sono: + +\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}} \item[\const{SHM\_LOCK}] Abilita il \itindex{memory~locking} \textit{memory - locking}\footnote{impedisce cioè che la memoria usata per il segmento - venga salvata su disco dal meccanismo della \index{memoria~virtuale} - 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. + locking} sul segmento di memoria condivisa, impedendo che la memoria usata + per il segmento venga salvata su disco dal meccanismo della + \index{memoria~virtuale} memoria virtuale. Come illustrato in + sez.~\ref{sec:proc_mem_lock} fino al kernel 2.6.9 solo l'amministratore + poteva utilizzare questa capacità,\footnote{che richiedeva la + \textit{capability} \const{CAP\_IPC\_LOCK}.} a partire dal dal kernel + 2.6.10 anche gli utenti normali possono farlo fino al limite massimo + determinato da \const{RLIMIT\_MEMLOCK} (vedi + sez.~\ref{sec:sys_resource_limit}). \item[\const{SHM\_UNLOCK}] Disabilita il \itindex{memory~locking} - \textit{memory locking} sul segmento di memoria condivisa. Solo - l'amministratore può utilizzare questo comando. + \textit{memory locking} sul segmento di memoria condivisa. Fino al kernel + 2.6.9 solo l'amministratore poteva utilizzare questo comando in + corrispondenza di un segmento da lui bloccato. \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 -previste da Linux, che permettono di abilitare e disabilitare il meccanismo -della \index{memoria~virtuale} memoria virtuale per il segmento. + +A questi due, come per \func{msgctl} e \func{semctl}, si aggiungono tre +ulteriori valori, \const{IPC\_INFO}, \const{MSG\_STAT} e \const{MSG\_INFO}, +introdotti ad uso del programma \cmd{ipcs} per ottenere le informazioni +generali relative alle risorse usate dai segmenti di memoria condivisa. Dato +che potranno essere modificati o rimossi in favore dell'uso di \texttt{/proc}, +non devono essere usati e non li tratteremo. L'argomento \param{buf} viene utilizzato solo con i comandi \const{IPC\_STAT} e \const{IPC\_SET} nel qual caso esso dovrà puntare ad una struttura @@ -2764,25 +2808,28 @@ l'interfaccia prevede due funzioni, \funcd{shmat} e \func{shmdt}. La prima di queste serve ad agganciare un segmento al processo chiamante, in modo che quest'ultimo possa inserirlo nel suo spazio di indirizzi per potervi accedere; il suo prototipo è: -\begin{functions} - \headdecl{sys/types.h} - \headdecl{sys/shm.h} - - \funcdecl{void *shmat(int shmid, const void *shmaddr, int shmflg)} - Aggancia al processo un segmento di memoria condivisa. - - \bodydesc{La funzione restituisce l'indirizzo del segmento in caso di - successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i - valori: - \begin{errlist} + +\begin{funcproto}{ +\fhead{sys/types.h} +\fhead{sys/shm.h} +\fdecl{void *shmat(int shmid, const void *shmaddr, int shmflg)} + +\fdesc{Aggancia un segmento di memoria condivisa al processo chiamante.} +} + +{La funzione ritorna l'indirizzo del segmento in caso di successo e $-1$ (in + un cast a \type{void *}) per un errore, nel qual caso \var{errno} assumerà + uno dei valori: + \begin{errlist} \item[\errcode{EACCES}] il processo non ha i privilegi per accedere al segmento nella modalità richiesta. \item[\errcode{EINVAL}] si è specificato un identificatore invalido per \param{shmid}, o un indirizzo non allineato sul confine di una pagina - per \param{shmaddr}. - \end{errlist} - ed inoltre \errval{ENOMEM}.} -\end{functions} + per \param{shmaddr} o il valore \val{NULL} indicando \const{SHM\_REMAP}. + \end{errlist} + ed inoltre \errval{ENOMEM} nel suo significato generico. +} +\end{funcproto} La funzione inserisce un segmento di memoria condivisa all'interno dello spazio di indirizzi del processo, in modo che questo possa accedervi @@ -2806,13 +2853,14 @@ L'argomento \param{shmaddr} specifica a quale indirizzo\footnote{lo standard come il valore di ritorno della funzione; in Linux è stato così con le \acr{libc4} e le \acr{libc5}, con il passaggio alla \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 -specificato è \val{NULL} è il sistema a scegliere opportunamente un'area di -memoria libera (questo è il modo più portabile e sicuro di usare la funzione). -Altrimenti il kernel aggancia il segmento all'indirizzo specificato da -\param{shmaddr}; questo però può avvenire solo se l'indirizzo coincide con il -limite di una pagina, cioè se è un multiplo esatto del parametro di sistema -\const{SHMLBA}, che in Linux è sempre uguale \const{PAGE\_SIZE}. + ritorno un \ctyp{void *} seguendo POSIX.1-2001.} deve essere associato il +segmento, se il valore specificato è \val{NULL} è il sistema a scegliere +opportunamente un'area di memoria libera (questo è il modo più portabile e +sicuro di usare la funzione). Altrimenti il kernel aggancia il segmento +all'indirizzo specificato da \param{shmaddr}; questo però può avvenire solo se +l'indirizzo coincide con il limite di una pagina, cioè se è un multiplo esatto +del parametro di sistema \const{SHMLBA}, che in Linux è sempre uguale +\const{PAGE\_SIZE}. Si tenga presente però che quando si usa \val{NULL} come valore di \param{shmaddr}, l'indirizzo restituito da \func{shmat} può cambiare da @@ -2821,15 +2869,17 @@ anche degli indirizzi, si deve avere cura di usare valori relativi (in genere riferiti all'indirizzo di partenza del segmento). L'argomento \param{shmflg} permette di cambiare il comportamento della -funzione; esso va specificato come maschera binaria, i bit utilizzati sono -solo due e sono identificati dalle costanti \const{SHM\_RND} e -\const{SHM\_RDONLY}, che vanno combinate con un OR aritmetico. Specificando -\const{SHM\_RND} si evita che \func{shmat} ritorni un errore quando -\param{shmaddr} non è allineato ai confini di una pagina. Si può quindi usare -un valore qualunque per \param{shmaddr}, e il segmento verrà comunque -agganciato, ma al più vicino multiplo di \const{SHMLBA} (il nome della +funzione; esso va specificato come maschera binaria, i bit utilizzati al +momento sono sono tre e sono identificati dalle costanti \const{SHM\_RND}, +\const{SHM\_RDONLY} e \const{SHM\_REMAP} che vanno combinate con un OR +aritmetico. + +Specificando \const{SHM\_RND} si evita che \func{shmat} ritorni un errore +quando \param{shmaddr} non è allineato ai confini di una pagina. Si può quindi +usare un valore qualunque per \param{shmaddr}, e il segmento verrà comunque +agganciato, ma al più vicino multiplo di \const{SHMLBA}; il nome della costante sta infatti per \textit{rounded}, e serve per specificare un -indirizzo come arrotondamento, in Linux è equivalente a \const{PAGE\_SIZE}). +indirizzo come arrotondamento. L'uso di \const{SHM\_RDONLY} permette di agganciare il segmento in sola lettura (si ricordi che anche le pagine di memoria hanno dei permessi), in tal @@ -2840,8 +2890,16 @@ di agganciare il segmento con l'accesso in lettura e scrittura (ed il processo deve aver questi permessi in \var{shm\_perm}), non è prevista la possibilità di agganciare un segmento in sola scrittura. -In caso di successo la funzione aggiorna anche i seguenti campi di -\struct{shmid\_ds}: +Infine \const{SHM\_REMAP} è una estensione specifica di Linux (quindi non +portabile) che indica che la mappatura del segmento deve rimpiazzare ogni +precedente mappatura esistente nell'intervallo iniziante +all'indirizzo \param{shmaddr} e di dimensione pari alla lunghezza del +segmento. In condizioni normali questo tipo di richiesta fallirebbe con un +errore di \errval{EINVAL}. Ovviamente usando \const{SHM\_REMAP} +l'argomento \param{shmaddr} non può essere nullo. + +In caso di successo la funzione \func{shmat} aggiorna anche i seguenti campi +della struttura \struct{shmid\_ds}: \begin{itemize*} \item il tempo \var{shm\_atime} dell'ultima operazione di aggancio viene impostato al tempo corrente. @@ -2849,7 +2907,7 @@ In caso di successo la funzione aggiorna anche i seguenti campi di segmento viene impostato a quello del processo corrente. \item il numero \var{shm\_nattch} di processi agganciati al segmento viene aumentato di uno. -\end{itemize*} +\end{itemize*} Come accennato in sez.~\ref{sec:proc_fork} un segmento di memoria condivisa agganciato ad un processo viene ereditato da un figlio attraverso una @@ -2863,18 +2921,21 @@ attraverso una \func{exit}. Una volta che un segmento di memoria condivisa non serve più, si può sganciarlo esplicitamente dal processo usando l'altra funzione dell'interfaccia, \funcd{shmdt}, il cui prototipo è: -\begin{functions} - \headdecl{sys/types.h} - \headdecl{sys/shm.h} - \funcdecl{int shmdt(const void *shmaddr)} - Sgancia dal processo un segmento di memoria condivisa. - - \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 \param{shmaddr}, con \var{errno} che assume il valore - \errval{EINVAL}.} -\end{functions} +\begin{funcproto}{ +\fhead{sys/types.h} +\fhead{sys/shm.h} +\fdecl{int shmdt(const void *shmaddr)} + +\fdesc{Sgancia dal processo un segmento di memoria condivisa.} +} + +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, la funzione + fallisce solo quando non c'è un segmento agganciato + all'indirizzo \param{shmaddr}, con \var{errno} che assume il valore + \errval{EINVAL}. +} +\end{funcproto} La funzione sgancia dallo spazio degli indirizzi del processo un segmento di memoria condivisa; questo viene identificato con l'indirizzo \param{shmaddr} @@ -3010,13 +3071,14 @@ 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 \index{directory~di~lavoro} directory di lavoro del programma nella directory da tenere sotto controllo, in vista del successivo uso della -funzione \func{daemon}.\footnote{si noti come si è potuta fare questa scelta, - nonostante le indicazioni illustrate in sez.~\ref{sec:sess_daemon}, per il - particolare scopo del programma, che necessita comunque di restare - all'interno di una directory.} Infine (\texttt{\small 27--29}) si installano -i gestori per i vari segnali di terminazione che, avendo a che fare con un -programma che deve essere eseguito come server, sono il solo strumento -disponibile per concluderne l'esecuzione. +funzione \func{daemon}. Si noti come si è potuta fare questa scelta, +nonostante le indicazioni illustrate in sez.~\ref{sec:sess_daemon}, per il +particolare scopo del programma, che necessita comunque di restare all'interno +di una directory. + +Infine (\texttt{\small 27--29}) si installano i gestori per i vari segnali di +terminazione che, avendo a che fare con un programma che deve essere eseguito +come server, sono il solo strumento disponibile per concluderne l'esecuzione. Il passo successivo (\texttt{\small 30--39}) è quello di creare gli oggetti di intercomunicazione necessari. Si inizia costruendo (\texttt{\small 30}) la @@ -3052,16 +3114,18 @@ Il primo passo (\texttt{\small 41}) è eseguire \func{daemon} per proseguire con l'esecuzione in background come si conviene ad un programma demone; si noti che si è mantenuta, usando un valore non nullo del primo argomento, la \index{directory~di~lavoro} directory di lavoro corrente. Una volta che il -programma è andato in background l'esecuzione prosegue (\texttt{\small - 42--48}) all'interno di un ciclo infinito: si inizia (\texttt{\small 43}) -bloccando il mutex con \func{MutexLock} per poter accedere alla memoria -condivisa (la funzione si bloccherà automaticamente se qualche client sta -leggendo), poi (\texttt{\small 44}) si cancellano i valori precedentemente -immagazzinati nella memoria condivisa con \func{memset}, e si esegue -(\texttt{\small 45}) un nuovo calcolo degli stessi utilizzando la funzione -\myfunc{dir\_scan}; infine (\texttt{\small 46}) si sblocca il mutex con -\func{MutexUnlock}, e si attende (\texttt{\small 47}) per il periodo di tempo -specificato a riga di comando con l'opzione \code{-p} con una \func{sleep}. +programma è andato in background l'esecuzione prosegue all'interno di un ciclo +infinito (\texttt{\small 42--48}). + +Si inizia (\texttt{\small 43}) bloccando il mutex con \func{MutexLock} per +poter accedere alla memoria condivisa (la funzione si bloccherà +automaticamente se qualche client sta leggendo), poi (\texttt{\small 44}) si +cancellano i valori precedentemente immagazzinati nella memoria condivisa con +\func{memset}, e si esegue (\texttt{\small 45}) un nuovo calcolo degli stessi +utilizzando la funzione \myfunc{dir\_scan}; infine (\texttt{\small 46}) si +sblocca il mutex con \func{MutexUnlock}, e si attende (\texttt{\small 47}) per +il periodo di tempo specificato a riga di comando con l'opzione \code{-p} +usando una \func{sleep}. Si noti come per il calcolo dei valori da mantenere nella memoria condivisa si sia usata ancora una volta la funzione \myfunc{dir\_scan}, già utilizzata (e @@ -3130,15 +3194,15 @@ il mutex, prima di uscire. Verifichiamo allora il funzionamento dei nostri programmi; al solito, usando le funzioni di libreria occorre definire opportunamente \code{LD\_LIBRARY\_PATH}; poi si potrà lanciare il server con: -\begin{Verbatim} -[piccardi@gont sources]$ ./dirmonitor ./ -\end{Verbatim} +\begin{Console} +[piccardi@gont sources]$ \textbf{./dirmonitor ./} +\end{Console} %$ ed avendo usato \func{daemon} il comando ritornerà immediatamente. Una volta che il server è in esecuzione, possiamo passare ad invocare il client per verificarne i risultati, in tal caso otterremo: -\begin{Verbatim} -[piccardi@gont sources]$ ./readmon +\begin{Console} +[piccardi@gont sources]$ \textbf{./readmon} Ci sono 68 file dati Ci sono 3 directory Ci sono 0 link @@ -3147,14 +3211,14 @@ Ci sono 0 socket Ci sono 0 device a caratteri Ci sono 0 device a blocchi Totale 71 file, per 489831 byte -\end{Verbatim} +\end{Console} %$ ed un rapido calcolo (ad esempio con \code{ls -a | wc} per contare i file) ci permette di verificare che il totale dei file è giusto. Un controllo con \cmd{ipcs} ci permette inoltre di verificare la presenza di un segmento di memoria condivisa e di un semaforo: -\begin{Verbatim} -[piccardi@gont sources]$ ipcs +\begin{Console} +[piccardi@gont sources]$ \textbf{ipcs} ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0xffffffff 54067205 piccardi 666 4096 1 @@ -3165,14 +3229,14 @@ key semid owner perms nsems ------ Message Queues -------- key msqid owner perms used-bytes messages -\end{Verbatim} +\end{Console} %$ Se a questo punto aggiungiamo un file, ad esempio con \code{touch prova}, potremo verificare che, passati nel peggiore dei casi almeno 10 secondi (o l'eventuale altro intervallo impostato per la rilettura dei dati) avremo: -\begin{Verbatim} -[piccardi@gont sources]$ ./readmon +\begin{Console} +[piccardi@gont sources]$ \textbf{./readmon} Ci sono 69 file dati Ci sono 3 directory Ci sono 0 link @@ -3181,21 +3245,21 @@ Ci sono 0 socket Ci sono 0 device a caratteri Ci sono 0 device a blocchi Totale 72 file, per 489887 byte -\end{Verbatim} +\end{Console} %$ A questo punto possiamo far uscire il server inviandogli un segnale di \signal{SIGTERM} con il comando \code{killall dirmonitor}, a questo punto ripetendo la lettura, otterremo un errore: -\begin{Verbatim} -[piccardi@gont sources]$ ./readmon +\begin{Console} +[piccardi@gont sources]$ \textbf{./readmon} Cannot find shared memory: No such file or directory -\end{Verbatim} +\end{Console} %$ e inoltre potremo anche verificare che anche gli oggetti di intercomunicazione visti in precedenza sono stati regolarmente cancellati: -\begin{Verbatim} -[piccardi@gont sources]$ ipcs +\begin{Console} +[piccardi@gont sources]$ \textbf{ipcs} ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status @@ -3204,7 +3268,7 @@ key semid owner perms nsems ------ Message Queues -------- key msqid owner perms used-bytes messages -\end{Verbatim} +\end{Console} %$ @@ -3255,7 +3319,7 @@ diversa con un uso combinato della memoria condivisa e dei meccanismi di sincronizzazione, per cui alla fine l'uso delle code di messaggi classiche è relativamente poco diffuso. -% TODO: trattare qui, se non ssis trova posto migliore, copy_from_process e +% TODO: trattare qui, se non si trova posto migliore, copy_from_process e % copy_to_process, introdotte con il kernel 3.2. Vedi % http://lwn.net/Articles/405346/ e % http://ozlabs.org/~cyeoh/cma/process_vm_readv.txt @@ -3275,19 +3339,19 @@ necessità di un contatore come i semafori, si possono utilizzare metodi alternativi. La prima possibilità, utilizzata fin dalle origini di Unix, è quella di usare -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_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} - \textit{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 lock (e della -risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata -ad \func{unlink}. +dei \textsl{file di lock} (per i quali è stata anche riservata una opportuna +directory, \file{/var/lock}, nella standardizzazione del \textit{Filesystem + Hierarchy Standard}). Per questo si usa la caratteristica della funzione +\func{open} (illustrata in 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} \textit{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 lock (e della risorsa ad esso associata) mentre +il rilascio si può eseguire con una chiamata ad \func{unlink}. Un esempio dell'uso di questa funzione è mostrato dalle funzioni \func{LockFile} ed \func{UnlockFile} riportate in fig.~\ref{fig:ipc_file_lock} @@ -3450,22 +3514,24 @@ nessun inconveniente. \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 \textit{pipe} può costituire una valida alternativa alle code di -messaggi; nella stessa situazione si può evitare l'uso di una memoria -condivisa facendo ricorso al cosiddetto \textit{memory mapping} anonimo. +\textsl{correlati}, se cioè hanno almeno un progenitore comune, l'uso delle +\textit{pipe} può costituire una valida alternativa alle code di messaggi; +nella stessa situazione si può evitare l'uso di una memoria condivisa facendo +ricorso al cosiddetto \textit{memory mapping} anonimo. In sez.~\ref{sec:file_memory_map} abbiamo visto come sia possibile mappare il contenuto di un file nella memoria di un processo, e che, quando viene usato il flag \const{MAP\_SHARED}, le modifiche effettuate al contenuto del file vengono viste da tutti i processi che lo hanno mappato. Utilizzare questa tecnica per creare una memoria condivisa fra processi diversi è estremamente -inefficiente, in quanto occorre passare attraverso il disco. Però abbiamo -visto anche che se si esegue la mappatura con il flag \const{MAP\_ANONYMOUS} -la regione mappata non viene associata a nessun file, anche se quanto scritto -rimane in memoria e può essere riletto; allora, dato che un processo figlio -mantiene nel suo spazio degli indirizzi anche le regioni mappate, esso sarà -anche in grado di accedere a quanto in esse è contenuto. +inefficiente, in quanto occorre passare attraverso il disco. + +Però abbiamo visto anche che se si esegue la mappatura con il flag +\const{MAP\_ANONYMOUS} la regione mappata non viene associata a nessun file, +anche se quanto scritto rimane in memoria e può essere riletto; allora, dato +che un processo figlio mantiene nel suo spazio degli indirizzi anche le +regioni mappate, esso sarà anche in grado di accedere a quanto in esse è +contenuto. In questo modo diventa possibile creare una memoria condivisa fra processi diversi, purché questi abbiano almeno un progenitore comune che ha effettuato @@ -3526,70 +3592,67 @@ richiesto è che: \end{itemize*} Data la assoluta genericità delle specifiche, il comportamento delle funzioni -è subordinato in maniera quasi completa alla relativa -implementazione.\footnote{tanto che Stevens in \cite{UNP2} cita questo caso - come un esempio della maniera standard usata dallo standard POSIX per - consentire implementazioni non standardizzabili.} Nel caso di Linux, sia per -quanto riguarda la memoria condivisa ed i semafori, che per quanto riguarda le -code di messaggi, tutto viene creato usando come radici delle opportune -directory (rispettivamente \file{/dev/shm} e \file{/dev/mqueue}, per i -dettagli si faccia riferimento a sez.~\ref{sec:ipc_posix_shm}, -sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq}) ed i nomi -specificati nelle relative funzioni sono considerati come un -\itindsub{pathname}{assoluto} \textit{pathname} assoluto (comprendente -eventuali sottodirectory) rispetto a queste radici. +è subordinato in maniera quasi completa alla relativa implementazione, tanto +che Stevens in \cite{UNP2} cita questo caso come un esempio della maniera +standard usata dallo standard POSIX per consentire implementazioni non +standardizzabili. + +Nel caso di Linux, sia per quanto riguarda la memoria condivisa ed i semafori, +che per le code di messaggi, tutto viene creato usando come radici delle +opportune directory (rispettivamente \file{/dev/shm} e \file{/dev/mqueue}, per +i dettagli si faccia riferimento a sez.~\ref{sec:ipc_posix_shm}, +sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq}). I nomi +specificati nelle relative funzioni devono essere nella forma di un +\textit{pathname} assoluto (devono cioè iniziare con ``\texttt{/}'') e +corrisponderanno ad altrettanti file creati all'interno di queste directory; +per questo motivo detti nomi non possono contenere altre ``\texttt{/}'' oltre +quella iniziale. Il vantaggio degli oggetti di IPC POSIX è comunque che essi vengono inseriti nell'albero dei file, e possono essere maneggiati con le usuali funzioni e -comandi di accesso ai file,\footnote{questo è vero nel caso di Linux, che usa - una implementazione che lo consente, non è detto che altrettanto valga per - altri kernel; in particolare, come si può facilmente verificare con uno - \cmd{strace}, sia per la memoria condivisa che per le code di messaggi le - system call utilizzate da Linux sono le stesse di quelle dei file, essendo - detti oggetti realizzati come tali in appositi filesystem.} che funzionano -come su dei file normali. +comandi di accesso ai file, che funzionano come su dei file normali. Questo +però è vero nel caso di Linux, che usa una implementazione che lo consente, +non è detto che altrettanto valga per altri kernel. In particolare, come si +può facilmente verificare con il comando \cmd{strace}, sia per la memoria +condivisa che per le code di messaggi varie \textit{system call} utilizzate da +Linux corrispondono in realtà a quelle ordinarie dei file, essendo detti +oggetti realizzati come tali in appositi filesystem. In particolare i permessi associati agli oggetti di IPC POSIX sono identici ai permessi dei file, ed il controllo di accesso segue esattamente la stessa semantica (quella illustrata in sez.~\ref{sec:file_access_control}), e non quella particolare (si ricordi quanto visto in sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del -SysV-IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo +SysV-IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata secondo la semantica SysV: corrispondono cioè a \ids{UID} e \ids{GID} effettivi del processo che esegue la creazione. -\subsection{Code di messaggi} +\subsection{Code di messaggi Posix} \label{sec:ipc_posix_mq} Le code di messaggi POSIX sono supportate da Linux a partire dalla versione -2.6.6-rc1 del kernel,\footnote{l'implementazione è dovuta a Michal Wronski e - Krzysztof Benedyczak, e le relative informazioni si possono trovare su - \url{http://www.geocities.com/wronski12/posix_ipc/index.html}.} In generale, -come le corrispettive del \textit{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 -mutex (o semafori) e memoria condivisa con tutta la flessibilità che occorre. +2.6.6 del kernel. In generale, come le corrispettive del \textit{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 mutex (o semafori) e memoria condivisa con +tutta la flessibilità che occorre. Per poter utilizzare le code di messaggi, oltre ad utilizzare un kernel -superiore al 2.6.6 (o precedente, se sono stati opportunamente applicati i -relativi patch) occorre utilizzare la libreria \file{libmqueue}\footnote{i - programmi che usano le code di messaggi cioè devono essere compilati - aggiungendo l'opzione \code{-lmqueue} al comando \cmd{gcc}; in - corrispondenza all'inclusione del supporto nel kernel ufficiale anche - \file{libmqueue} è stata inserita nella \acr{glibc}, a partire dalla - versione 2.3.4 delle medesime.} che contiene le funzioni dell'interfaccia -POSIX.\footnote{in realtà l'implementazione è realizzata tramite delle - opportune chiamate ad \func{ioctl} sui file del filesystem speciale su cui - vengono mantenuti questi oggetti di IPC.} +superiore al 2.6.6 occorre utilizzare la libreria \file{librt} che contiene le +funzioni dell'interfaccia POSIX ed i programmi che usano le code di messaggi +devono essere compilati aggiungendo l'opzione \code{-lrt} al comando +\cmd{gcc}. In corrispondenza all'inclusione del supporto nel kernel ufficiale +le funzioni di libreria sono state inserite nella \acr{glibc}, e sono +disponibili a partire dalla versione 2.3.4 delle medesime. La libreria inoltre richiede la presenza dell'apposito filesystem di tipo -\texttt{mqueue} montato su \file{/dev/mqueue}; questo può essere fatto -aggiungendo ad \conffile{/etc/fstab} una riga come: -\begin{verbatim} +\texttt{mqueue} montato sulla directory \file{/dev/mqueue}; questo può essere +fatto aggiungendo ad \conffile{/etc/fstab} una riga come: +\begin{FileExample}[label=/etc/fstab] mqueue /dev/mqueue mqueue defaults 0 0 -\end{verbatim} +\end{FileExample} ed esso sarà utilizzato come radice sulla quale vengono risolti i nomi delle code di messaggi che iniziano con una ``\texttt{/}''. Le opzioni di mount accettate sono \texttt{uid}, \texttt{gid} e \texttt{mode} che permettono @@ -3597,54 +3660,63 @@ rispettivamente di impostare l'utente, il gruppo ed i permessi associati al filesystem. -La funzione che permette di aprire (e crearla se non esiste ancora) una coda -di messaggi POSIX è \funcd{mq\_open}, ed il suo prototipo è: -\begin{functions} - \headdecl{mqueue.h} - - \funcdecl{mqd\_t mq\_open(const char *name, int oflag)} - - \funcdecl{mqd\_t mq\_open(const char *name, int oflag, unsigned long mode, +La funzione di sistema che permette di aprire (e crearla se non esiste ancora) +una coda di messaggi POSIX è \funcd{mq\_open}, ed il suo prototipo è: + +\begin{funcproto}{ +\fhead{fcntl.h} +\fhead{sys/stat.h} +\fhead{mqueue.h} +\fdecl{mqd\_t mq\_open(const char *name, int oflag)} +\fdecl{mqd\_t mq\_open(const char *name, int oflag, unsigned long mode, struct mq\_attr *attr)} - - Apre una coda di messaggi POSIX impostandone le caratteristiche. - - \bodydesc{La funzione restituisce il descrittore associato alla coda in caso - di successo e -1 per un errore; nel quel caso \var{errno} assumerà i - valori: - \begin{errlist} - \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. - \item[\errcode{EINVAL}] il file non supporta la funzione, o si è - specificato \const{O\_CREAT} con una valore non nullo di \param{attr} e - valori non validi di \var{mq\_maxmsg} e \var{mq\_msgsize}. - \item[\errcode{ENOENT}] non si è specificato \const{O\_CREAT} ma la coda - non esiste. - \end{errlist} - ed inoltre \errval{ENOMEM}, \errval{ENOSPC}, \errval{EFAULT}, - \errval{EMFILE}, \errval{EINTR} ed \errval{ENFILE}. + +\fdesc{Apre una coda di messaggi POSIX impostandone le caratteristiche.} } -\end{functions} + +{La funzione ritorna il descrittore associato alla coda in caso di successo e + $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\errcode{EACCES}] il processo non ha i privilegi per accedere alla + coda secondo quanto specificato da \param{oflag} oppure \const{name} + contiene più di una ``\texttt{/}''. + \item[\errcode{EEXIST}] si è specificato \const{O\_CREAT} e \const{O\_EXCL} + ma la coda già esiste. + \item[\errcode{EINVAL}] il file non supporta la funzione, o si è specificato + \const{O\_CREAT} con una valore non nullo di \param{attr} e valori non + validi dei campi \var{mq\_maxmsg} e \var{mq\_msgsize}; questi valori + devono essere positivi ed inferiori ai limiti di sistema se il processo + non ha privilegi amministrativi, inoltre \var{mq\_maxmsg} non può comunque + superare \const{HARD\_MAX}. + \item[\errcode{ENOENT}] non si è specificato \const{O\_CREAT} ma la coda non + esiste o si è usato il nome ``\texttt{/}''. + \item[\errcode{ENOSPC}] lo spazio è insufficiente, probabilmente per aver + superato il limite di \texttt{queues\_max}. + \end{errlist} + ed inoltre \errval{EMFILE}, \errval{ENAMETOOLONG}, \errval{ENFILE}, + \errval{ENOMEM} ed nel loro significato generico. } +\end{funcproto} La funzione apre la coda di messaggi identificata dall'argomento \param{name} restituendo il descrittore ad essa associato, del tutto analogo ad un file descriptor, con l'unica differenza che lo standard prevede un apposito tipo -\type{mqd\_t}.\footnote{nel caso di Linux si tratta in effetti proprio di un - normale file descriptor; pertanto, anche se questo comportamento non è - portabile, lo si può tenere sotto osservazione con le funzioni dell'I/O - multiplexing (vedi sez.~\ref{sec:file_multiplexing}) come possibile - alternativa all'uso dell'interfaccia di notifica di \func{mq\_notify} (che - vedremo a breve).} Se la coda esiste già il descrittore farà riferimento -allo stesso oggetto, consentendo così la comunicazione fra due processi -diversi. +\type{mqd\_t}. Nel caso di Linux si tratta in effetti proprio di un normale +file descriptor; pertanto, anche se questo comportamento non è portabile, lo +si può tenere sotto osservazione con le funzioni dell'I/O multiplexing (vedi +sez.~\ref{sec:file_multiplexing}) come possibile alternativa all'uso +dell'interfaccia di notifica di \func{mq\_notify} (che vedremo a breve). + +Se il nome indicato fa riferimento ad una coda di messaggi già esistente, il +descrittore ottenuto farà riferimento allo stesso oggetto, pertanto tutti i +processi che hanno usato \func{mq\_open} su quel nome otterranno un +riferimento alla stessa coda. Diventa così immediato costruire un canale di +comunicazione fra detti processi. 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 -sez.~\ref{sec:file_open_close} dei quali però \func{mq\_open} riconosce solo i -seguenti: +sez.~\ref{sec:file_open_close} (per questo occorre includere \texttt{fcntl.h}) +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 processo potrà usare il descrittore con \func{mq\_receive} ma non con @@ -3676,15 +3748,17 @@ Se la coda non esiste e la si vuole creare si deve specificare creazione con l'argomento \param{mode};\footnote{fino al 2.6.14 per un bug i valori della \textit{umask} del processo non venivano applicati a questi permessi.} i valori di quest'ultimo sono identici a quelli usati per -\func{open}, anche se per le code di messaggi han senso solo i permessi di -lettura e scrittura. Oltre ai permessi di creazione possono essere specificati -anche gli attributi specifici della coda tramite l'argomento \param{attr}; -quest'ultimo è un puntatore ad una apposita struttura \struct{mq\_attr}, la -cui definizione è riportata in fig.~\ref{fig:ipc_mq_attr}. +\func{open} (per questo occorre includere \texttt{sys/stat.h}), anche se per +le code di messaggi han senso solo i permessi di lettura e scrittura. + +Oltre ai permessi di creazione possono essere specificati anche gli attributi +specifici della coda tramite l'argomento \param{attr}; quest'ultimo è un +puntatore ad una apposita struttura \struct{mq\_attr}, la cui definizione è +riportata in fig.~\ref{fig:ipc_mq_attr}. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{\textwidth} + \begin{minipage}[c]{0.90\textwidth} \includestruct{listati/mq_attr.h} \end{minipage} \normalsize @@ -3697,51 +3771,101 @@ Per la creazione della coda i campi della struttura che devono essere specificati sono \var{mq\_maxmsg} e \var{mq\_msgsize}, che indicano rispettivamente il numero massimo di messaggi che può contenere e la dimensione massima di un messaggio. Il valore dovrà essere positivo e minore -dei rispettivi limiti di sistema \const{MQ\_MAXMSG} e \const{MQ\_MSGSIZE}, -altrimenti la funzione fallirà con un errore di \errcode{EINVAL}. -Se \param{attr} è un puntatore nullo gli attributi della coda saranno -impostati ai valori predefiniti. +dei rispettivi limiti di sistema altrimenti la funzione fallirà con un errore +di \errcode{EINVAL}. Se \param{attr} è un puntatore nullo gli attributi della +coda saranno impostati ai valori predefiniti. + +I suddetti limiti di sistema sono impostati attraverso altrettanti file in +\texttt{/proc/sys/fs/mqueue}, in particolare i file che controllano i valori +dei limiti sono: +\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}} +\item[\sysctlfile{fs/mqueue/msg\_max}] Indica il valore massimo del numero di + messaggi in una coda e agisce come limite superiore per il valore di + \var{attr->mq\_maxmsg} in \func{mq\_open}. Il suo valore di default è 10. Il + valore massimo è \const{HARD\_MAX} che vale \code{(131072/sizeof(void *))}, + ed il valore minimo 1 (ma era 10 per i kernel precedenti il 2.6.28). Questo + limite viene ignorato per i processi con privilegi amministrativi (più + precisamente con la \itindex{capability} \textit{capability} + \const{CAP\_SYS\_RESOURCE}) ma \const{HARD\_MAX} resta comunque non + superabile. + +\item[\sysctlfile{fs/mqueue/msgsize\_max}] Indica il valore massimo della + dimensione in byte di un messaggio sulla coda ed agisce come limite + superiore per il valore di \var{attr->mq\_msgsize} in \func{mq\_open}. Il + suo valore di default è 8192. Il valore massimo è 1048576 ed il valore + minimo 128 (ma per i kernel precedenti il 2.6.28 detti limiti erano + rispettivamente \const{INT\_MAX} e 8192). Questo limite viene ignorato dai + processi con privilegi amministrativi (con la \itindex{capability} + \textit{capability} \const{CAP\_SYS\_RESOURCE}). + +\item[\sysctlfile{fs/mqueue/queues\_max}] Indica il numero massimo di code di + messaggi creabili in totale sul sistema, il valore di default è 256 ma si + può usare un valore qualunque fra $0$ e \const{INT\_MAX}. Il limite non + viene applicato ai processi con privilegi amministrativi (cioè con la + \itindex{capability} \textit{capability} \const{CAP\_SYS\_RESOURCE}). + +\end{basedescript} + +Infine sulle code di messaggi si applica il limite imposto sulla risorsa +\const{RLIMIT\_MSGQUEUE} (vedi sez.~\ref{sec:sys_resource_limit}) che indica +lo spazio massimo (in byte) occupabile dall'insieme di tutte le code di +messaggi appartenenti ai processi di uno stesso utente, che viene identificato +in base al \textit{real user ID} degli stessi. Quando l'accesso alla coda non è più necessario si può chiudere il relativo descrittore con la funzione \funcd{mq\_close}, il cui prototipo è: -\begin{prototype}{mqueue.h} -{int mq\_close(mqd\_t mqdes)} -Chiude la coda \param{mqdes}. - -\bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore; - nel quel caso \var{errno} assumerà i valori \errval{EBADF} o - \errval{EINTR}.} -\end{prototype} +\begin{funcproto}{ +\fhead{mqueue.h} +\fdecl{int mq\_close(mqd\_t mqdes)} -La funzione è analoga a \func{close},\footnote{in Linux, dove le code sono - implementate come file su un filesystem dedicato, è esattamente la stessa - funzione.} dopo la sua esecuzione il processo non sarà più in grado di usare -il descrittore della coda, ma quest'ultima continuerà ad esistere nel sistema -e potrà essere acceduta con un'altra chiamata a \func{mq\_open}. All'uscita di -un processo tutte le code aperte, così come i file, vengono chiuse -automaticamente. Inoltre se il processo aveva agganciato una richiesta di -notifica sul descrittore che viene chiuso, questa sarà rilasciata e potrà -essere richiesta da qualche altro processo. +\fdesc{Chiude una coda di messaggi.} +} +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà uno dei valori \errval{EBADF} o \errval{EINTR} nel + loro significato generico. +} +\end{funcproto} + +La funzione è analoga a \func{close},\footnote{su Linux, dove le code sono + implementate come file su un filesystem dedicato, è esattamente la stessa + funzione, per cui non esiste una \textit{system call} autonoma e la funzione + viene rimappata su \func{close} dalle \acr{glibc}.} dopo la sua esecuzione +il processo non sarà più in grado di usare il descrittore della coda, ma +quest'ultima continuerà ad esistere nel sistema e potrà essere acceduta con +un'altra chiamata a \func{mq\_open}. All'uscita di un processo tutte le code +aperte, così come i file, vengono chiuse automaticamente. Inoltre se il +processo aveva agganciato una richiesta di notifica sul descrittore che viene +chiuso, questa sarà rilasciata e potrà essere richiesta da qualche altro +processo. Quando si vuole effettivamente rimuovere una coda dal sistema occorre usare la -funzione \funcd{mq\_unlink}, il cui prototipo è: -\begin{prototype}{mqueue.h} -{int mq\_unlink(const char *name)} +funzione di sistema \funcd{mq\_unlink}, il cui prototipo è: -Rimuove una coda di messaggi. - -\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di - errore; nel quel caso \var{errno} assumerà gli stessi valori riportati da - \func{unlink}.} -\end{prototype} +\begin{funcproto}{ +\fhead{mqueue.h} +\fdecl{int mq\_unlink(const char *name)} + +\fdesc{Rimuove una coda di messaggi.} +} + +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà gli uno dei valori: + \begin{errlist} + \item[\errcode{EACCES}] non si hanno i permessi per cancellare la coda. + \item[\errcode{ENAMETOOLONG}] il nome indicato è troppo lungo. + \item[\errcode{ENOENT}] non esiste una coda con il nome indicato. + \end{errlist} +} +\end{funcproto} Anche in questo caso il comportamento della funzione è analogo a quello di -\func{unlink} per i file,\footnote{di nuovo l'implementazione di Linux usa - direttamente \func{unlink}.} la funzione rimuove la coda \param{name}, così -che una successiva chiamata a \func{mq\_open} fallisce o crea una coda -diversa. +\func{unlink} per i file, la funzione rimuove la coda \param{name} (ed il +relativo file sotto \texttt{/dev/mqueue}), così che una successiva chiamata a +\func{mq\_open} fallisce o crea una coda diversa. + +% TODO, verificare se mq_unlink è davvero una system call indipendente. Come per i file ogni coda di messaggi ha un contatore di riferimenti, per cui la coda non viene effettivamente rimossa dal sistema fin quando questo non si @@ -3751,141 +3875,163 @@ di essa. Allo stesso modo una coda ed i suoi contenuti resteranno disponibili all'interno del sistema anche quando quest'ultima non è aperta da nessun processo (questa è una delle differenze più rilevanti nei confronti di \textit{pipe} e \textit{fifo}). La sola differenza fra code di messaggi POSIX -e file normali è che, essendo il filesystem delle code di messaggi virtuale e +e file normali è che, essendo il filesystem delle code di messaggi virtuale, e basato su oggetti interni al kernel, il suo contenuto viene perduto con il riavvio del sistema. Come accennato ad ogni coda di messaggi è associata una struttura \struct{mq\_attr}, che può essere letta e modificata attraverso le due funzioni \funcd{mq\_getattr} e \funcd{mq\_setattr}, i cui prototipi sono: -\begin{functions} - \headdecl{mqueue.h} - - \funcdecl{int mq\_getattr(mqd\_t mqdes, struct mq\_attr *mqstat)} - Legge gli attributi di una coda di messaggi POSIX. - - \funcdecl{int mq\_setattr(mqd\_t mqdes, const struct mq\_attr *mqstat, + +\begin{funcproto}{ +\fhead{mqueue.h} +\fdecl{int mq\_getattr(mqd\_t mqdes, struct mq\_attr *mqstat)} +\fdesc{Legge gli attributi di una coda di messaggi POSIX.} +\fdecl{int mq\_setattr(mqd\_t mqdes, const struct mq\_attr *mqstat, struct mq\_attr *omqstat)} - Modifica gli attributi di una coda di messaggi POSIX. - - \bodydesc{Entrambe le funzioni restituiscono 0 in caso di successo e -1 in - caso di errore; nel quel caso \var{errno} assumerà i valori \errval{EBADF} - o \errval{EINVAL}.} -\end{functions} +\fdesc{Modifica gli attributi di una coda di messaggi POSIX.} +} + +{Entrambe le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, + nel qual caso \var{errno} assumerà i valori \errval{EBADF} + o \errval{EINVAL} nel loro significato generico. +} +\end{funcproto} La funzione \func{mq\_getattr} legge i valori correnti degli attributi della -coda nella struttura puntata da \param{mqstat}; di questi l'unico relativo -allo stato corrente della coda è \var{mq\_curmsgs} che indica il numero di -messaggi da essa contenuti, gli altri indicano le caratteristiche generali -della stessa. +coda \param{mqdes} nella struttura \struct{mq\_attr} puntata +da \param{mqstat}; di questi l'unico relativo allo stato corrente della coda è +\var{mq\_curmsgs} che indica il numero di messaggi da essa contenuti, gli +altri indicano le caratteristiche generali della stessa impostate in fase di +apertura. La funzione \func{mq\_setattr} permette di modificare gli attributi di una -coda tramite i valori contenuti nella struttura puntata da \param{mqstat}, ma -può essere modificato solo il campo \var{mq\_flags}, gli altri campi vengono -ignorati. In particolare i valori di \var{mq\_maxmsg} e \var{mq\_msgsize} -possono essere specificati solo in fase ci creazione della coda. Inoltre i -soli valori possibili per \var{mq\_flags} sono 0 e \const{O\_NONBLOCK}, per -cui alla fine la funzione può essere utilizzata solo per abilitare o -disabilitare la modalità non bloccante. L'argomento \param{omqstat} viene -usato, quando diverso da \val{NULL}, per specificare l'indirizzo di una -struttura su cui salvare i valori degli attributi precedenti alla chiamata -della funzione. - -Per inserire messaggi su di una coda sono previste due funzioni, -\funcd{mq\_send} e \funcd{mq\_timedsend}, i cui prototipi sono: -\begin{functions} - \headdecl{mqueue.h} - - \funcdecl{int mq\_send(mqd\_t mqdes, const char *msg\_ptr, size\_t msg\_len, - unsigned int msg\_prio)} - Esegue l'inserimento di un messaggio su una coda. - - \funcdecl{int mq\_timedsend(mqd\_t mqdes, const char *msg\_ptr, size\_t - msg\_len, unsigned msg\_prio, const struct timespec *abs\_timeout)} - Esegue l'inserimento di un messaggio su una coda entro il tempo - \param{abs\_timeout}. +coda (indicata da \param{mqdes}) tramite i valori contenuti nella struttura +\struct{mq\_attr} puntata da \param{mqstat}, ma può essere modificato solo il +campo \var{mq\_flags}, gli altri campi vengono comunque ignorati. + +In particolare i valori di \var{mq\_maxmsg} e \var{mq\_msgsize} possono essere +specificati solo in fase ci creazione della coda. Inoltre i soli valori +possibili per \var{mq\_flags} sono 0 e \const{O\_NONBLOCK}, per cui alla fine +la funzione può essere utilizzata solo per abilitare o disabilitare la +modalità non bloccante. L'argomento \param{omqstat} viene usato, quando +diverso da \val{NULL}, per specificare l'indirizzo di una struttura su cui +salvare i valori degli attributi precedenti alla chiamata della funzione. + +Per inserire messaggi su di una coda sono previste due funzioni di sistema, +\funcd{mq\_send} e \funcd{mq\_timedsend}. In realtà su Linux la \textit{system + call} è soltanto \func{mq\_timedsend}, mentre \func{mq\_send} viene +implementata come funzione di libreria che si appoggia alla +precedente. Inoltre \func{mq\_timedsend} richiede che sia definita la macro +\macro{\_XOPEN\_SOURCE} ad un valore pari ad almeno \texttt{600} o la macro +\macro{\_POSIX\_C\_SOURCE} ad un valore uguale o maggiore di \texttt{200112L}. +I rispettivi prototipi sono: - - \bodydesc{Le funzioni restituiscono 0 in caso di successo e $-1$ per un - errore; nel quel caso \var{errno} assumerà i valori: - \begin{errlist} +\begin{funcproto}{ +\fhead{mqueue.h} +\fdecl{int mq\_send(mqd\_t mqdes, const char *msg\_ptr, size\_t msg\_len, + unsigned int msg\_prio)} +\fdesc{Esegue l'inserimento di un messaggio su una coda.} +\fhead{mqueue.h} +\fhead{time.h} +\fdecl{int mq\_timedsend(mqd\_t mqdes, const char *msg\_ptr, size\_t + msg\_len, unsigned int msg\_prio,\\ +\phantom{int mq\_timedsend(}const struct timespec *abs\_timeout)} +\fdesc{Esegue l'inserimento di un messaggio su una coda entro un tempo + specificato} +} + +{Entrambe le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, + nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la coda è piena. - \item[\errcode{EMSGSIZE}] la lunghezza del messaggio \param{msg\_len} - eccede il limite impostato per la coda. + \item[\errcode{EBADF}] si specificato un file descriptor non valido. \item[\errcode{EINVAL}] si è specificato un valore nullo per \param{msg\_len}, o un valore di \param{msg\_prio} fuori dai limiti, o un valore non valido per \param{abs\_timeout}. + \item[\errcode{EMSGSIZE}] la lunghezza del messaggio \param{msg\_len} + eccede il limite impostato per la coda. \item[\errcode{ETIMEDOUT}] l'inserimento del messaggio non è stato - effettuato entro il tempo stabilito. - \end{errlist} - ed inoltre \errval{EBADF}, \errval{ENOMEM} ed \errval{EINTR}.} -\end{functions} + effettuato entro il tempo stabilito (solo \func{mq\_timedsend}). + \end{errlist} + ed inoltre \errval{EBADF}, \errval{EINTR} nel suo significato generico. } +\end{funcproto} -Entrambe le funzioni richiedono un puntatore al testo del messaggio -nell'argomento \param{msg\_ptr} e la relativa lunghezza in \param{msg\_len}. +Entrambe le funzioni richiedono un puntatore ad un buffer in memoria +contenente il testo del messaggio da inserire nella coda \param{mqdes} +nell'argomento \param{msg\_ptr}, e la relativa lunghezza in \param{msg\_len}. Se quest'ultima eccede la dimensione massima specificata da \var{mq\_msgsize} le funzioni ritornano immediatamente con un errore di \errcode{EMSGSIZE}. -L'argomento \param{msg\_prio} indica la priorità dell'argomento; i messaggi di -priorità maggiore vengono inseriti davanti a quelli di priorità inferiore (e -quindi saranno riletti per primi). A parità del valore della priorità il -messaggio sarà inserito in coda a tutti quelli con la stessa priorità. Il -valore della priorità non può eccedere il limite di sistema -\const{MQ\_PRIO\_MAX}, che nel caso è pari a 32768. +L'argomento \param{msg\_prio} indica la priorità dell'argomento, che, essendo +definito come \ctyp{unsigned int}, è sempre un intero positivo. I messaggi di +priorità maggiore vengono inseriti davanti a quelli di priorità inferiore, e +quindi saranno riletti per primi. A parità del valore della priorità il +messaggio sarà inserito in coda a tutti quelli che hanno la stessa priorità +che quindi saranno letti con la politica di una \textit{fifo}. Il valore della +priorità non può eccedere il limite di sistema \const{MQ\_PRIO\_MAX}, che al +momento è pari a 32768. Qualora la coda sia piena, entrambe le funzioni si bloccano, a meno che non -sia stata selezionata in fase di apertura la modalità non -bloccante,\footnote{o si sia impostato il flag \const{O\_NONBLOCK} sul file - descriptor della coda.} nel qual caso entrambe ritornano \errcode{EAGAIN}. -La sola differenza fra le due funzioni è che la seconda, passato il tempo -massimo impostato con l'argomento \param{abs\_timeout},\footnote{deve essere - specificato un tempo assoluto tramite una struttura \struct{timespec} (vedi - fig.~\ref{fig:sys_timespec_struct}) indicato in numero di secondi e - nanosecondi a partire dal 1 gennaio 1970.} ritorna comunque con un errore di -\errcode{ETIMEDOUT}, se invece il tempo è già scaduto al momento della -chiamata e la coda è vuota la funzione ritorna immediatamente. +sia stata selezionata in fase di apertura della stessa la modalità non +bloccante o non si sia impostato il flag \const{O\_NONBLOCK} sul file +descriptor della coda, nel qual caso entrambe ritornano con un codice di +errore di \errcode{EAGAIN}. + +La sola differenza fra le due funzioni è che \func{mq\_timedsend}, passato il +tempo massimo impostato con l'argomento \param{abs\_timeout}, ritorna comunque +con un errore di \errcode{ETIMEDOUT}, se invece il tempo è già scaduto al +momento della chiamata e la coda è piena la funzione ritorna +immediatamente. Il valore di \param{abs\_timeout} deve essere specificato come +tempo assoluto tramite una struttura \struct{timespec} (vedi +fig.~\ref{fig:sys_timespec_struct}) indicato in numero di secondi e +nanosecondi a partire dal 1 gennaio 1970. Come per l'inserimento, anche per l'estrazione dei messaggi da una coda sono -previste due funzioni, \funcd{mq\_receive} e \funcd{mq\_timedreceive}, i cui -prototipi sono: -\begin{functions} - \headdecl{mqueue.h} - - \funcdecl{ssize\_t mq\_receive(mqd\_t mqdes, char *msg\_ptr, size\_t - msg\_len, unsigned int *msg\_prio)} - Effettua la ricezione di un messaggio da una coda. - - \funcdecl{ssize\_t mq\_timedreceive(mqd\_t mqdes, char *msg\_ptr, size\_t - msg\_len, unsigned int *msg\_prio, const struct timespec *abs\_timeout)} - Effettua la ricezione di un messaggio da una coda entro il tempo - \param{abs\_timeout}. - - \bodydesc{Le funzioni restituiscono il numero di byte del messaggio in caso - di successo e -1 in caso di errore; nel quel caso \var{errno} assumerà i - valori: - \begin{errlist} +previste due funzioni di sistema, \funcd{mq\_receive} e +\funcd{mq\_timedreceive}. Anche in questo caso su Linux soltanto +\func{mq\_timedreceive} è effettivamente, una \textit{system call} e per +usarla devono essere definite le opportune macro come per +\func{mq\_timedsend}. I rispettivi prototipi sono: + +\begin{funcproto}{ +\fhead{mqueue.h} +\fdecl{ssize\_t mq\_receive(mqd\_t mqdes, char *msg\_ptr, size\_t + msg\_len, unsigned int *msg\_prio)} +\fdesc{Effettua la ricezione di un messaggio da una coda.} +\fhead{mqueue.h} +\fhead{time.h} +\fdecl{ssize\_t mq\_timedreceive(mqd\_t mqdes, char *msg\_ptr, size\_t + msg\_len,\\ +\phantom{ssize\_t mq\_timedreceive(}unsigned int *msg\_prio, const struct timespec +*abs\_timeout)} +\fdesc{Riceve un messaggio da una coda entro un limite di tempo.} +} +{Entrambe le funzioni ritornano il numero di byte del messaggio in caso di + successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei + valori: + \begin{errlist} \item[\errcode{EAGAIN}] si è aperta la coda con \const{O\_NONBLOCK}, e la coda è vuota. - \item[\errcode{EMSGSIZE}] la lunghezza del messaggio sulla coda eccede il - valore \param{msg\_len} specificato per la ricezione. \item[\errcode{EINVAL}] si è specificato un valore nullo per \param{msg\_ptr}, o un valore non valido per \param{abs\_timeout}. + \item[\errcode{EMSGSIZE}] la lunghezza del messaggio sulla coda eccede il + valore \param{msg\_len} specificato per la ricezione. \item[\errcode{ETIMEDOUT}] la ricezione del messaggio non è stata effettuata entro il tempo stabilito. - \end{errlist} - ed inoltre \errval{EBADF}, \errval{EINTR}, \errval{ENOMEM}, o - \errval{EINVAL}.} -\end{functions} + \end{errlist} + ed inoltre \errval{EBADF} o \errval{EINTR} nel loro significato generico. } +\end{funcproto} -La funzione estrae dalla coda il messaggio a priorità più alta, o il più -vecchio fra quelli della stessa priorità. Una volta ricevuto il messaggio -viene tolto dalla coda e la sua dimensione viene restituita come valore di -ritorno.\footnote{si tenga presente che 0 è una dimensione valida e che la - condizione di errore è restituita dal valore -1; Stevens in \cite{UNP2} fa - notare che questo è uno dei casi in cui vale ciò che lo standard - \textsl{non} dice, una dimensione nulla infatti, pur non essendo citata, non - viene proibita.} +La funzione estrae dalla coda \param{mqdes} il messaggio a priorità più alta, +o il più vecchio fra quelli della stessa priorità. Una volta ricevuto il +messaggio viene tolto dalla coda e la sua dimensione viene restituita come +valore di ritorno; si tenga presente che 0 è una dimensione valida e che la +condizione di errore è indicata soltanto da un valore di +$-1$.\footnote{Stevens in \cite{UNP2} fa notare che questo è uno dei casi in + cui vale ciò che lo standard \textsl{non} dice, una dimensione nulla + infatti, pur non essendo citata, non viene proibita.} Se la dimensione specificata da \param{msg\_len} non è sufficiente a contenere il messaggio, entrambe le funzioni, al contrario di quanto avveniva nelle code @@ -3906,8 +4052,6 @@ selezionare quale messaggio estrarre con delle condizioni sulla priorità, a differenza di quanto avveniva con le code di messaggi di SysV che permettono invece la selezione in base al valore del campo \var{mtype}. -% 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 @@ -3927,39 +4071,48 @@ superare in parte questo problema. Una caratteristica specifica delle code di messaggi POSIX è la possibilità di usufruire di un meccanismo di notifica asincrono; questo può essere attivato usando la funzione \funcd{mq\_notify}, il cui prototipo è: -\begin{prototype}{mqueue.h} -{int mq\_notify(mqd\_t mqdes, const struct sigevent *notification)} -Attiva il meccanismo di notifica per la coda \param{mqdes}. - -\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di - errore; nel quel caso \var{errno} assumerà i valori: - \begin{errlist} - \item[\errcode{EBUSY}] c'è già un processo registrato per la notifica. +\begin{funcproto}{ +\fhead{mqueue.h} +\fdecl{int mq\_notify(mqd\_t mqdes, const struct sigevent *notification)} + +\fdesc{Attiva il meccanismo di notifica per una coda.} +} + +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà uno dei valori: + \begin{errlist} \item[\errcode{EBADF}] il descrittore non fa riferimento ad una coda di messaggi. - \end{errlist}} -\end{prototype} + \item[\errcode{EBUSY}] c'è già un processo registrato per la notifica. + \item[\errcode{EINVAL}] si è richiesto un meccanismo di notifica invalido + o specificato nella notifica con i segnali il valore di un segnale non + esistente. + \end{errlist} + ed inoltre \errval{ENOMEM} nel suo significato generico. + +} +\end{funcproto} Il meccanismo di notifica permette di segnalare in maniera asincrona ad un -processo la presenza di dati sulla coda, in modo da evitare la necessità di -bloccarsi nell'attesa. Per far questo un processo deve registrarsi con la -funzione \func{mq\_notify}, ed il meccanismo è disponibile per un solo -processo alla volta per ciascuna coda. +processo la presenza di dati sulla coda indicata da \param{mqdes}, in modo da +evitare la necessità di bloccarsi nell'attesa. Per far questo un processo deve +registrarsi con la funzione \func{mq\_notify}, ed il meccanismo è disponibile +per un solo processo alla volta per ciascuna coda. -Il comportamento di \func{mq\_notify} dipende dal valore dell'argomento -\param{notification}, che è un puntatore ad una apposita struttura +Il comportamento di \func{mq\_notify} dipende dai valori passati con +l'argomento \param{notification}, che è un puntatore ad una apposita struttura \struct{sigevent}, (definita in fig.~\ref{fig:struct_sigevent}) introdotta dallo standard POSIX.1b per gestire la notifica di eventi; per altri dettagli -si può vedere quanto detto in sez.~\ref{sec:sig_timer_adv} a proposito -dell'uso della stessa struttura per la notifica delle scadenze dei +su di essa si può rivedere quanto detto in sez.~\ref{sec:sig_timer_adv} a +proposito dell'uso della stessa struttura per la notifica delle scadenze dei \textit{timer}. Attraverso questa struttura si possono impostare le modalità con cui viene effettuata la notifica nel campo \var{sigev\_notify}, che può assumere i -valori di tab.~\ref{tab:sigevent_sigev_notify}.\footnote{la pagina di manuale - riporta soltanto i primi tre (inizialmente era possibile solo - \const{SIGEV\_SIGNAL}).} Il metodo consigliato è quello di usare +valori di tab.~\ref{tab:sigevent_sigev_notify}; fra questi la pagina di +manuale riporta soltanto i primi tre, ed inizialmente era possibile solo +\const{SIGEV\_SIGNAL}. Il metodo consigliato è quello di usare \const{SIGEV\_SIGNAL} usando il campo \var{sigev\_signo} per indicare il quale segnale deve essere inviato al processo. Inoltre il campo \var{sigev\_value} è un puntatore ad una struttura \struct{sigval} (definita in @@ -3973,12 +4126,12 @@ La funzione registra il processo chiamante per la notifica se \param{notification} punta ad una struttura \struct{sigevent} opportunamente inizializzata, o cancella una precedente registrazione se è \val{NULL}. Dato che un solo processo alla volta può essere registrato, la funzione fallisce -con \errcode{EBUSY} se c'è un altro processo già registrato.\footnote{questo - significa anche che se si registra una notifica con \const{SIGEV\_NONE} il - processo non la riceverà, ma impedirà anche che altri possano registrarsi - per poterlo fare.} Si tenga presente inoltre che alla chiusura del -descrittore associato alla coda (e quindi anche all'uscita del processo) ogni -eventuale registrazione di notifica presente viene cancellata. +con \errcode{EBUSY} se c'è un altro processo già registrato. Questo significa +anche che se si registra una notifica con \const{SIGEV\_NONE} il processo non +la riceverà, ma impedirà anche che altri possano registrarsi per poterlo fare. +Si tenga presente inoltre che alla chiusura del descrittore associato alla +coda (e quindi anche all'uscita del processo) ogni eventuale registrazione di +notifica presente viene cancellata. La notifica del segnale avviene all'arrivo di un messaggio in una coda vuota (cioè solo se sulla coda non ci sono messaggi) e se non c'è nessun processo @@ -3993,8 +4146,8 @@ la coda diventa disponibile per una ulteriore registrazione. Questo comporta che se si vuole mantenere il meccanismo di notifica occorre ripetere la registrazione chiamando nuovamente \func{mq\_notify} all'interno del gestore del segnale di notifica. A differenza della situazione simile che si aveva con -i segnali non affidabili,\footnote{l'argomento è stato affrontato in - \ref{sec:sig_semantics}.} questa caratteristica non configura una +i segnali non affidabili (l'argomento è stato affrontato in +\ref{sec:sig_semantics}) questa caratteristica non configura una \itindex{race~condition} \textit{race condition} perché l'invio di un segnale avviene solo se la coda è vuota; pertanto se si vuole evitare di correre il rischio di perdere eventuali ulteriori segnali inviati nel lasso di tempo che @@ -4005,13 +4158,12 @@ L'invio del segnale di notifica avvalora alcuni campi di informazione restituiti al gestore attraverso la struttura \struct{siginfo\_t} (definita in fig.~\ref{fig:sig_siginfo_t}). In particolare \var{si\_pid} viene impostato al valore del \ids{PID} del processo che ha emesso il segnale, \var{si\_uid} -all'userid effettivo, \var{si\_code} a \const{SI\_MESGQ}, e \var{si\_errno} a -0. Questo ci dice che, se si effettua la ricezione dei messaggi usando -esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni -sul processo che ha inserito un messaggio usando un gestore per il segnale in -forma estesa.\footnote{di nuovo si faccia riferimento a quanto detto al - proposito in sez.~\ref{sec:sig_sigaction} e sez.~\ref{sec:sig_real_time}.} - +all'\textsl{user-ID} effettivo, \var{si\_code} a \const{SI\_MESGQ}, e +\var{si\_errno} a 0. Questo ci dice che, se si effettua la ricezione dei +messaggi usando esclusivamente il meccanismo di notifica, è possibile ottenere +le informazioni sul processo che ha inserito un messaggio usando un gestore +per il segnale in forma estesa, di nuovo si faccia riferimento a quanto detto +al proposito in sez.~\ref{sec:sig_sigaction} e sez.~\ref{sec:sig_real_time}. \subsection{Memoria condivisa} @@ -4024,18 +4176,19 @@ suoi contenuti in memoria, che viene attivato abilitando l'opzione \texttt{CONFIG\_TMPFS} in fase di compilazione del kernel. Per potere utilizzare l'interfaccia POSIX per la memoria condivisa la -\acr{glibc}\footnote{le funzioni sono state introdotte con la versione 2.2.} -richiede di compilare i programmi con l'opzione \code{-lrt}; inoltre è -necessario che in \file{/dev/shm} sia montato un filesystem \texttt{tmpfs}; -questo di norma viene fatto aggiungendo una riga del tipo di: -\begin{verbatim} +\acr{glibc} (le funzioni sono state introdotte con la versione 2.2) richiede +di compilare i programmi con l'opzione \code{-lrt}; inoltre è necessario che +in \file{/dev/shm} sia montato un filesystem \texttt{tmpfs}; questo di norma +viene fatto aggiungendo una riga del tipo di: +\begin{FileExample}[label=/etc/fstab] tmpfs /dev/shm tmpfs defaults 0 0 -\end{verbatim} -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} +\end{FileExample} +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{Example} mount -t tmpfs -o size=128M,nr_inodes=10k,mode=700 tmpfs /mytmpfs -\end{verbatim} +\end{Example} Il filesystem riconosce, oltre quelle mostrate, le opzioni \texttt{uid} e \texttt{gid} che identificano rispettivamente utente e gruppo cui assegnarne @@ -4329,7 +4482,7 @@ Si tenga presente che la funzione può sempre essere interrotta da un segnale (nel qual caso si avrà un errore di \const{EINTR}) e che questo avverrà comunque, anche se si è richiesta la semantica BSD installando il relativo gestore con \const{SA\_RESTART} (vedi sez.~\ref{sec:sig_sigaction}) per -riavviare le system call interrotte. +riavviare le \textit{system call} interrotte. Della funzione \func{sem\_wait} esistono due varianti che consentono di gestire diversamente le modalità di attesa in caso di risorsa occupata, la @@ -4858,14 +5011,15 @@ testo alla terminazione di quest'ultimo. % LocalWords: process getvalue sval execve pshared ENOSYS heap PAGE destroy it % LocalWords: xffffffff Arrays owner perms Queues used bytes messages device % LocalWords: Cannot find such Segments getter Signal MSGMAXSIZE been stable -% LocalWords: for now it's break Berlin sources Let's an accidental feature +% LocalWords: for now it's break Berlin sources Let's an accidental feature fs % LocalWords: Larry Wall Escape the Hell William ipctestid Identifier segment % LocalWords: violation dell'I SIGINT setter Fri Dec Sleeping seconds ECHILD +% LocalWords: SysV capability short RESOURCE INFO UNDEFINED EFBIG semtimedop +% LocalWords: scan HUGETLB huge page NORESERVE copy RLIMIT MEMLOCK REMAP +% LocalWords: readmon Hierarchy defaults queues MSGQUEUE %%% Local Variables: %%% mode: latex %%% TeX-master: "gapil" %%% End: -% LocalWords: SysV capability short RESOURCE INFO UNDEFINED EFBIG semtimedop -% LocalWords: scan