il cui codice completo è disponibile nel file \file{BarCodePage.c} che si
trova nella directory dei sorgenti.
-
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
(dove di norma vengono creati sia i programmi che la libreria), il comando da
dare sarà \code{export LD\_LIBRARY\_PATH=./}; a questo punto potremo lanciare
il server, facendogli leggere una decina di frasi, con:
-\begin{verbatim}
+\begin{Verbatim}
[piccardi@gont sources]$ ./fortuned -n10
-\end{verbatim}
+\end{Verbatim}
+%$
Avendo usato \func{daemon} per eseguire il server in background il comando
ritornerà immediatamente, ma potremo verificare con \cmd{ps} che in effetti il
programma resta un esecuzione in background, e senza avere associato un
terminale di controllo (si ricordi quanto detto in sez.~\ref{sec:sess_daemon}):
-\begin{verbatim}
+\begin{Verbatim}
[piccardi@gont sources]$ ps aux
...
piccardi 27489 0.0 0.0 1204 356 ? S 01:06 0:00 ./fortuned -n10
piccardi 27492 3.0 0.1 2492 764 pts/2 R 01:08 0:00 ps aux
-\end{verbatim}%$
+\end{Verbatim}
+%$
e si potrà verificare anche che in \file{/tmp} è stata creata la fifo di
ascolto \file{fortune.fifo}. A questo punto potremo interrogare il server con
il programma client; otterremo così:
-\begin{verbatim}
+\begin{Verbatim}
[piccardi@gont sources]$ ./fortune
Linux ext2fs has been stable for a long time, now it's time to break it
-- Linuxkongreß '95 in Berlin
[piccardi@gont sources]$ ./fortune
Linux ext2fs has been stable for a long time, now it's time to break it
-- Linuxkongreß '95 in Berlin
-\end{verbatim}%$
+\end{Verbatim}
+%$
e ripetendo varie volte il comando otterremo, in ordine casuale, le dieci
frasi tenute in memoria dal server.
Il secondo livello di controllo è quello delle varie funzioni che accedono
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}
+\begin{itemize*}
\item se il processo ha i privilegi di amministratore l'accesso è sempre
consentito.
\item se l'user-ID effettivo del processo corrisponde o al valore del campo
valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
per il gruppo in \var{mode} è appropriato l'accesso è consentito.
\item se il permesso per gli altri è appropriato l'accesso è consentito.
-\end{itemize}
+\end{itemize*}
solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
a differenza di quanto avviene per i permessi dei file, fallire in uno dei
passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
stampa, cancellazione. I valori di default sono per l'uso delle code di
messaggi e un ciclo di 5 volte. Se si lancia il comando si otterrà qualcosa
del tipo:
-\begin{verbatim}
+\begin{Verbatim}
piccardi@gont sources]$ ./ipctestid
Identifier Value 0
Identifier Value 32768
Identifier Value 65536
Identifier Value 98304
Identifier Value 131072
-\end{verbatim}%$
+\end{Verbatim}
+%$
il che ci mostra che abbiamo un kernel della serie 2.4.x nel quale non avevamo
ancora usato nessuna coda di messaggi. Se ripetiamo il comando otterremo
ancora:
-\begin{verbatim}
+\begin{Verbatim}
[piccardi@gont sources]$ ./ipctestid
Identifier Value 163840
Identifier Value 196608
Identifier Value 229376
Identifier Value 262144
Identifier Value 294912
-\end{verbatim}%$
+\end{Verbatim}
+%$
che ci mostra come il valore di \var{seq} sia in effetti una quantità
mantenuta staticamente all'interno del sistema.
\procrelfile{/proc/sys/kernel}{msgmnb} e
\procrelfile{/proc/sys/kernel}{msgmni} di \file{/proc/sys/kernel/}.
-
\begin{figure}[htb]
- \centering \includegraphics[width=15cm]{img/mqstruct}
+ \centering \includegraphics[width=13cm]{img/mqstruct}
\caption{Schema della struttura di una coda messaggi.}
\label{fig:ipc_mq_schema}
\end{figure}
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
+ \bodydesc{La funzione restituisce 0 in caso di successo o $-1$ in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] si è richiesto \const{IPC\_STAT} ma processo
Invia un messaggio sulla coda \param{msqid}.
- \bodydesc{La funzione restituisce 0, e -1 in caso di errore, nel qual caso
+ \bodydesc{La funzione restituisce 0, e $-1$ in caso di errore, nel qual caso
\var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] non si hanno i privilegi di accesso sulla coda.
\item[\errcode{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 \const{IPC\_NOWAIT} in \param{flag}.
- \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\item[\errcode{EINVAL}] si è specificato un \param{msgid} invalido, o un
valore non positivo per \param{mtype}, o un valore di \param{msgsz}
maggiore di \const{MSGMAX}.
\end{errlist}
- ed inoltre \errval{EFAULT} ed \errval{ENOMEM}.
-}
+ ed inoltre \errval{EFAULT}, \errval{EINTR} ed \errval{ENOMEM}. }
\end{functions}
La funzione inserisce il messaggio sulla coda specificata da \param{msqid}; il
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}
+\begin{Verbatim}
[piccardi@gont sources]$ ./dirmonitor ./
-\end{verbatim}%$
+\end{Verbatim}
+%$
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}
+\begin{Verbatim}
[piccardi@gont sources]$ ./readmon
Ci sono 68 file dati
Ci sono 3 directory
Ci sono 0 device a caratteri
Ci sono 0 device a blocchi
Totale 71 file, per 489831 byte
-\end{verbatim}%$
+\end{Verbatim}
+%$
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}
+\begin{Verbatim}
[piccardi@gont sources]$ ipcs
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
------ Message Queues --------
key msqid owner perms used-bytes messages
-\end{verbatim}%$
+\end{Verbatim}
+%$
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}
+\begin{Verbatim}
[piccardi@gont sources]$ ./readmon
Ci sono 69 file dati
Ci sono 3 directory
Ci sono 0 device a caratteri
Ci sono 0 device a blocchi
Totale 72 file, per 489887 byte
-\end{verbatim}%$
+\end{Verbatim}
+%$
A questo punto possiamo far uscire il server inviandogli un segnale di
\const{SIGTERM} con il comando \code{killall dirmonitor}, a questo punto
ripetendo la lettura, otterremo un errore:
-\begin{verbatim}
+\begin{Verbatim}
[piccardi@gont sources]$ ./readmon
Cannot find shared memory: No such file or directory
-\end{verbatim}%$
+\end{Verbatim}
+%$
e inoltre potremo anche verificare che anche gli oggetti di intercomunicazione
visti in precedenza sono stati regolarmente cancellati:
-\begin{verbatim}
+\begin{Verbatim}
[piccardi@gont sources]$ ipcs
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
------ Message Queues --------
key msqid owner perms used-bytes messages
-\end{verbatim}%$
-
+\end{Verbatim}
+%$
%% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
lo standard è molto generico riguardo l'implementazione, ed i nomi stessi
possono avere o meno una corrispondenza sul filesystem; tutto quello che è
richiesto è che:
-\begin{itemize}
+\begin{itemize*}
\item i nomi devono essere conformi alle regole che caratterizzano i
\itindex{pathname} \textit{pathname}, in particolare non essere più lunghi di
\const{PATH\_MAX} byte e terminati da un carattere nullo.
nome dipende dall'implementazione.
\item l'interpretazione di ulteriori \texttt{/} presenti nel nome dipende
dall'implementazione.
-\end{itemize}
+\end{itemize*}
Data la assoluta genericità delle specifiche, il comportamento delle funzioni
è subordinato in maniera quasi completa alla relativa
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{EINTR}] la funzione è stata interrotta da un segnale.
\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}.
non esiste.
\end{errlist}
ed inoltre \errval{ENOMEM}, \errval{ENOSPC}, \errval{EFAULT},
- \errval{EMFILE} ed \errval{ENFILE}.}
+ \errval{EMFILE}, \errval{EINTR} ed \errval{ENFILE}.
+}
\end{functions}
La funzione apre la coda di messaggi identificata dall'argomento \param{name}
\param{abs\_timeout}.
- \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di
+ \bodydesc{Le funzioni restituiscono 0 in caso di successo e $-1$ in caso di
errore; nel quel caso \var{errno} assumerà i 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{ENOMEM}] il kernel non ha memoria sufficiente. Questo
- errore può avvenire quando l'inserimento del messaggio
\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{ETIMEDOUT}] l'inserimento del messaggio non è stato
effettuato entro il tempo stabilito.
\end{errlist}
- ed inoltre \errval{EBADF} ed \errval{EINTR}.}
+ ed inoltre \errval{EBADF}, \errval{ENOMEM} ed \errval{EINTR}.}
\end{functions}
Entrambe le funzioni richiedono un puntatore al testo del messaggio
Il comportamento di \func{mq\_notify} dipende dal valore dell'argomento
\param{notification}, che è un puntatore ad una apposita struttura
-\struct{sigevent}, (definita in fig.~\ref{fig:file_sigevent}) introdotta dallo
-standard POSIX.1b per gestire la notifica di eventi; per altri dettagli si può
-vedere quanto detto in sez.~\ref{sec:file_asyncronous_io} a proposito dell'uso
-della stessa struttura per l'invio dei segnali usati per l'I/O asincrono.
+\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:file_asyncronous_io} a proposito
+dell'uso della stessa struttura per l'invio dei segnali usati per l'I/O
+asincrono.
Attraverso questa struttura si possono impostare le modalità con cui viene
effettuata la notifica; in particolare il campo \var{sigev\_notify} deve
projects / gapil.git / blobdiff