è in grado di visualizzarlo opportunamente.
Per realizzare quanto voluto useremo in sequenza i programmi \cmd{barcode} e
-\cmd{gs}, il primo infatti è in grado di generare immagini postscript di
+\cmd{gs}, il primo infatti è in grado di generare immagini PostScript di
codici a barre corrispondenti ad una qualunque stringa, mentre il secondo
serve per poter effettuare la conversione della stessa immagine in formato
JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
\cmd{barcode}. Quest'ultimo legge dallo standard input una stringa di
-caratteri, la converte nell'immagine postscript del codice a barre ad essa
+caratteri, la converte nell'immagine PostScript del codice a barre ad essa
corrispondente, e poi scrive il risultato direttamente sullo standard output.
Per poter utilizzare queste caratteristiche prima di eseguire \cmd{barcode} si
\func{dup2}. Si ricordi che invocando \func{dup2} il secondo file, qualora
risulti aperto, viene, come nel caso corrente, chiuso prima di effettuare la
duplicazione. Allo stesso modo, dato che \cmd{barcode} scrive l'immagine
-postscript del codice a barre sullo standard output, per poter effettuare una
+PostScript del codice a barre sullo standard output, per poter effettuare una
ulteriore redirezione il capo in lettura della seconda pipe viene chiuso
(\texttt{\small 22}) mentre il capo in scrittura viene collegato allo standard
output (\texttt{\small 23}).
In questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} (cui si
passa in \var{size} la dimensione della pagina per l'immagine) quest'ultimo
leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
-padre, e scriverà l'immagine postscript del codice a barre sulla seconda.
+padre, e scriverà l'immagine PostScript del codice a barre sulla seconda.
Al contempo una volta lanciato il primo figlio, il processo padre prima chiude
(\texttt{\small 26}) il capo inutilizzato della prima pipe (quello in input) e
29}) che l'esecuzione di \cmd{barcode} sia completata.
Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
-postscript del codice a barre sul capo in scrittura della seconda pipe; a
+PostScript del codice a barre sul capo in scrittura della seconda pipe; a
questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
programma \cmd{gs}. Per questo si crea (\texttt{\small 30--34}) un secondo
processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
-leggendo l'immagine postscript creata da \cmd{barcode} dallo standard input,
+leggendo l'immagine PostScript creata da \cmd{barcode} dallo standard input,
per convertirla in JPEG.
Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
inoltre nella pratica sconta un problema di \cmd{gs} che non è in
grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
-riconoscere correttamente l'encapsulated postscript, per cui deve essere usato
-il postscript e tutte le volte viene generata una pagina intera, invece che
+riconoscere correttamente l'Encapsulated PostScript, per cui deve essere usato
+il PostScript e tutte le volte viene generata una pagina intera, invece che
una immagine delle dimensioni corrispondenti al codice a barre.
Se si vuole generare una immagine di dimensioni appropriate si deve usare un
};
char content[]="Content-type: image/png\n\n";
int i;
- /* write mime-type to stout */
+ /* write mime-type to stdout */
write(STDOUT_FILENO, content, strlen(content));
/* execute chain of command */
for (i=0; i<4; i++) {
kernel, andando a modificarne la definizione nei relativi header file. A
partire dal kernel 2.4.x è possibile cambiare questi valori a sistema attivo
scrivendo sui file \file{shmmni}, \file{msgmni} e \file{sem} di
- \file{/proc/sys/kernel} o con l'uso di \texttt{syscntl}.} e per ciascuno di
+ \file{/proc/sys/kernel} o con l'uso di \func{sysctl}.} e per ciascuno di
essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
l'oggetto viene creato usando uno spazio che era già stato utilizzato in
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
+modificare questi limiti attraverso l'uso di \func{sysctl} o scrivendo nei
file \file{msgmax}, \file{msgmnb} e \file{msgmni} di \file{/proc/sys/kernel/}.
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \structd{msgid\_ds}, associata a ciascuna coda di
+ \caption{La struttura \structd{msqid\_ds}, associata a ciascuna coda di
messaggi.}
- \label{fig:ipc_msgid_ds}
+ \label{fig:ipc_msqid_ds}
\end{figure}
A ciascuna coda è associata una struttura \struct{msgid\_ds}, la cui
-definizione, è riportata in \secref{fig:ipc_msgid_ds}. In questa struttura il
+definizione, è riportata in \secref{fig:ipc_msqid_ds}. In questa struttura il
kernel mantiene le principali informazioni riguardo lo stato corrente della
coda.\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
sia una differenza con i campi mostrati nello schema di
\figref{fig:ipc_mq_schema} che sono presi dalla definizione di
\file{linux/msg.h}, e fanno riferimento alla definizione della omonima
- struttura usata nel kernel.} In \figref{fig:ipc_msgid_ds} sono elencati i
+ struttura usata nel kernel.} In \figref{fig:ipc_msqid_ds} 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.
aggancia (\texttt{\small 39--41}) al processo all'indirizzo \var{shmptr}; sarà
attraverso questo puntatore che potremo accedere alla memoria condivisa, che
sarà vista nella forma data da \struct{DirProp}. Infine con la stessa chiave
-si crea (\texttt{\small 42--45}) anche un mutex, che utilizzaremo per regolare
-l'accesso alla memoria condivisa.
+si crea (\texttt{\small 42--45}) anche un mutex (utilizzando le funzioni di
+interfaccia già descritte in \secref{sec:ipc_sysv_sem}) che utilizzeremo per
+regolare l'accesso alla memoria condivisa.
Una volta completata l'inizializzazione e la creazione degli oggetti di
intercomunicazione il programma eseguirà indefinitamente (\texttt{\small
(\texttt{\small 51}), e si attende (\texttt{\small 52}) per il periodo di
tempo specificato a riga di comando con l'opzione \code{-p}.
-
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
\begin{lstlisting}{}
...
/*
- * Routine to print file name and size inside DirScan
+ * Routine to compute directory properties inside DirScan
*/
int ComputeValues(struct dirent * direntry)
{
\tabref{tab:file_type_macro}, si contano (\texttt{\small 11--17}) quanti ce ne
sono per ciascun tipo.
-In \figref{fig:ipc_dirmonitor_sub} è riportato inoltre (\texttt{\small
- 23--35}) il codice del gestore di segnali usato per terminare il programma,
-che si incarica di cancellare tutti gli oggetti non più necessari.
+In \figref{fig:ipc_dirmonitor_sub} è riportato anche (\texttt{\small 23--35})
+il codice del gestore di segnali di terminazione usato per chiudere il
+programma, che oltre a provocare l'uscita del programma si incarica anche di
+cancellare tutti gli oggetti di intercomunicazione non più necessari. Nel
+caso anzitutto (\texttt{\small 24}) si acquisisce il mutex per evitare di
+operare mentre un client sta ancora leggendo i dati, dopo di che prima si
+distacca (\texttt{\small 25--28}) il segmento e poi lo si cancella
+(\texttt{\small 29--32}). Infine (\texttt{\small 33}) si rimuove il mutex e si
+esce.
+
+Il codice del client che permette di leggere le informazioni mantenute nella
+memoria condivisa è riportato in \figref{fig:ipc_dirmonitor_client}, al solito
+si è omessa la sezione di gestione delle opzioni e la funzione che stampa a
+video le istruzioni; il codice completo è nei sorgenti allegati, nel file
+\file{ReadMonitor.c}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}{}
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <dirent.h> /* directory */
+#include <stdlib.h> /* C standard library */
+#include <unistd.h>
+
+#include "Gapil.h"
+#include "macros.h"
+
+int main(int argc, char *argv[])
+{
+ int i;
+ key_t key;
+ ..
+ /* find needed IPC objects */
+ key = ftok("./DirMonitor.c", 1); /* define a key */
+ shmid = shmget(key, 4096, 0); /* get the shared memory ID */
+ if (shmid < 0) {
+ perror("Cannot find shared memory");
+ exit(1);
+ }
+ if ( (shmptr = shmat(shmid, NULL, 0)) == NULL ) { /* attach to process */
+ perror("Cannot attach segment");
+ exit(1);
+ }
+ if ((mutex = MutexFind(key)) == -1) { /* get the Mutex */
+ perror("Cannot find mutex");
+ exit(1);
+ }
+ /* main loop */
+ MutexLock(mutex); /* lock shared memory */
+ printf("File presenti %d file, per un totale di %d byte\n",
+ shmptr->tot_files, shmptr->tot_size);
+ printf("Ci sono %d file dati\n", shmptr->tot_regular);
+ printf("Ci sono %d directory\n", shmptr->tot_dir);
+ printf("Ci sono %d link\n", shmptr->tot_link);
+ printf("Ci sono %d fifo\n", shmptr->tot_fifo);
+ printf("Ci sono %d socket\n", shmptr->tot_sock);
+ printf("Ci sono %d device a caratteri\n", shmptr->tot_char);
+ printf("Ci sono %d device a blocchi\n", shmptr->tot_block);
+ MutexUnlock(mutex); /* unlock shared memory */
+}
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{Codice del programma client \file{ReadMonitor.c}.}
+ \label{fig:ipc_dirmonitor_client}
+\end{figure}
+
+Una volta completata la gestione delle opzioni a riga di comando il programma
+rigenera (\texttt{\small 16}) la chiave usata per identificare memoria
+condivisa e mutex, richiede (\texttt{\small 17}) l'identificatore della
+memoria condivisa (che in questo caso deve già esistere), uscendo in caso di
+errore (\texttt{\small 18--21}). Una volta ottenuto l'identificatore si può
+(\texttt{\small 22--25}) agganciare il segmento al processo (anche in questo
+caso uscendo se qualcosa non funziona). Infine (\texttt{\small 26--29}) si
+richiede pure l'identificatore del mutex.
-Anzitutto (\texttt{\small 24}) si acquisisce il mutex per evitare di operare
-mentre un client sta ancora leggendo i dati, dopo di che si distacca
-(\texttt{\small 25--28}) il segmento e lo si cancella (\texttt{\small
- 29--32}). Infine (\texttt{\small 33}) si rimuove il mutex e si esce.
+Una volta completata l'inizializzazione ed ottenuti i riferimenti agli oggetti
+di intercomunicazione necessari viene eseguito il corpo principale del
+programma (\texttt{\small 30--41}); si acquisisce (\texttt{\small 31}) il
+mutex (qui avviene il blocco se la memoria condivisa non è disponibile), e poi
+(\texttt{\small 32--40}) si stampano i vari valori in essa contenuti. Infine
+(\texttt{\small 41}) si rilascia il mutex.
%% Per capire meglio il funzionamento delle funzioni facciamo ancora una volta
return 0;
}
/*
- * Function UnLockMutex: unlock a file.
+ * Function UnlockMutex: unlock a file.
*/
int UnlockMutex(const char *path_name)
{
projects / gapil.git / blobdiff