programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
generato da \cmd{barcode} utilizzando lo switch \cmd{-E}). Utilizzando un PDF
al posto di un EPS \cmd{gs} esegue la conversione rispettando le dimensioni
-originarie del codice a barre e produce un JPEG delle dimensioni adeguate.
-
-Questo però ci porta a scontrarci con una caratteristica peculiare delle pipe,
-che a prima vista non è evidente. Per poter effettuare la conversione di un
-PDF infatti è necessario, per la struttura del formato, dover eseguire delle
-\func{lseek} sul file da convertire; se si esegue \cmd{gs} su un file regolare
-non ci sono problemi, ma una pipe però è rigidamente sequenziale, ed il
-tentativo di eseguire detta operazione su una pipe comporta l'immediato
-fallimento con un errore di \macro{ESPIPE}. Questo ci dice che in generale la
-concatenazione di vari programmi funzionerà soltanto quando tutti prevedono
-una lettura sequenziale del loro input.
-
-Per questo motivo si è dovuto utilizzare una strada diversa, che prevede la
-conversione attraverso \cmd{gs} del PS in un altro formato intermedio, il
-PPM,\footnote{il \textit{Portable PixMap file format} è un formato usato
- spesso come formato intermedio per effettuare conversioni, è estremamente
- inefficiente, ma molto facile da manipolare dato che usa caratteri ASCII per
- memorizzare le immagini.} dal quale poi si può ottenere un'immagine di
-dimensioni corrette attraverso vari programmi di manipolazione (\cmd{pnmcrop},
-\cmd{pnmmargin}) che può essere infine trasformata in PNG (con \cmd{pnm2png}).
+originarie del codice a barre e produce un JPEG di dimensioni corrette.
+
+Questo approccio però non funziona, per via di una delle caratteristiche
+principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
+necessario, per la struttura del formato, potersi spostare (con \func{lseek})
+all'interno del file da convertire; se si eseguela conversione con \cmd{gs} su
+un file regolare non ci sono problemi, una pipe però è rigidamente
+sequenziale, e l'uso di \func{lseek} su di essa fallisce sempre con un errore
+di \macro{ESPIPE}, rendendo impossibile la conversione. Questo ci dice che in
+generale la concatenazione di vari programmi funzionerà soltanto quando tutti
+prevedono una lettura sequenziale del loro input.
+
+Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
+prima la conversione (sempre con \cmd{gs}) del PS in un altro formato
+intermedio, il PPM,\footnote{il \textit{Portable PixMap file format} è un
+ formato usato spesso come formato intermedio per effettuare conversioni, è
+ infatti molto facile da manipolare, dato che usa caratteri ASCII per
+ memorizzare le immagini, anche se per questo è estremamente inefficiente.}
+dal quale poi si può ottenere un'immagine di dimensioni corrette attraverso
+vari programmi di manipolazione (\cmd{pnmcrop}, \cmd{pnmmargin}) che può
+essere infine trasformata in PNG (con \cmd{pnm2png}).
In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
inviando l'output di ciascuno all'input del successivo, per poi ottenere il
primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
(\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
-ciclo, che chiuda, nell'ordine inverso rispetto a quello in cui le si sono
+ciclo che chiuda, nell'ordine inverso rispetto a quello in cui le si sono
create, tutte le pipe create con \func{pclose}.
l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
l'errore di \macro{ENXIO} fintanto che non verrà aperto il capo in lettura.
-In Linux\footnote{lo standard POSIX lascia indefinito questo comportamento.} è
-possibile aprire le fifo anche in lettura/scrittura, operazione che avrà
-sempre successo immediato qualunque sia la modalità di apertura (bloccante e
-non bloccante); questo può essere utilizzato per aprire comunque una fifo in
-scrittura anche se non ci sono ancora processi il lettura; è possibile anche
-usare la fifo all'interno di un solo processo, nel qual caso però occorre
-stare molto attenti alla possibili deadlock.\footnote{se si cerca di leggere
- da una fifo che non contiene dati si avrà un deadlock immediato, dato che il
- processo si blocca e non potrà quindi mai eseguire le funzioni di
- scrittura.}
+In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
+ standard POSIX lascia indefinito il comportamento in questo caso.}
+operazione che avrà sempre successo immediato qualunque sia la modalità di
+apertura (bloccante e non bloccante); questo può essere utilizzato per aprire
+comunque una fifo in scrittura anche se non ci sono ancora processi il
+lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
+qual caso però occorre stare molto attenti alla possibili
+deadlock.\footnote{se si cerca di leggere da una fifo che non contiene dati si
+ avrà un deadlock immediato, dato che il processo si blocca e non potrà
+ quindi mai eseguire le funzioni di scrittura.}
Per la loro caratteristica di essere accessibili attraverso il filesystem, è
piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
-situazioni un processo deve ricevere informazioni dagli altri. In questo caso
-è fondamentale che le operazioni di scrittura siano atomiche; per questo si
-deve sempre tenere presente che questo è vero soltanto fintanto che non si
-supera il limite delle dimensioni di \macro{PIPE\_BUF} (si ricordi quanto
-detto in \secref{sec:ipc_pipes}).
-
-A parte il precedente, che resta probabilmente il più comune, Stevens riporta
-in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
+situazioni un processo deve ricevere informazioni da altri. In questo caso è
+fondamentale che le operazioni di scrittura siano atomiche; per questo si deve
+sempre tenere presente che questo è vero soltanto fintanto che non si supera
+il limite delle dimensioni di \macro{PIPE\_BUF} (si ricordi quanto detto in
+\secref{sec:ipc_pipes}).
+
+A parte il caso precedente, che resta probabilmente il più comune, Stevens
+riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
\begin{itemize}
\item Da parte dei comandi di shell, per evitare la creazione di file
temporanei quando si devono inviare i dati di uscita di un processo
sull'input di parecchi altri (attraverso l'uso del comando \cmd{tee}).
-\item Come canale di comunicazione fra un client ed un server (il modello
+\item Come canale di comunicazione fra client ed server (il modello
\textit{client-server} è illustrato in \secref{sec:net_cliserv}).
\end{itemize}
-Nel primo caso quello che si fa è creare tante pipe quanti sono i processi a
-cui i vogliono inviare i dati, da usare come standard input per gli stessi; una
-volta che li si saranno posti in esecuzione ridirigendo lo standard input si
-potrà eseguire il processo iniziale replicandone, con il comando \cmd{tee},
-l'output sulle pipe.
+Nel primo caso quello che si fa è creare tante fifo, da usare come standard
+input, quanti sono i processi a cui i vogliono inviare i dati, questi ultimi
+saranno stati posti in esecuzione ridirigendo lo standard input dalle fifo, si
+potrà poi eseguire il processo che fornisce l'output replicando quest'ultimo,
+con il comando \cmd{tee}, sulle varie fifo.
Il secondo caso è relativamente semplice qualora si debba comunicare con un
-processo alla volta (nel qual caso basta usare due pipe, una per leggere ed
+processo alla volta (nel qual caso basta usare due fifo, una per leggere ed
una per scrivere), le cose diventano invece molto più complesse quando si
vuole effettuare una comunicazione fra il server ed un numero imprecisato di
client; se il primo infatti può ricevere le richieste attraverso una fifo
generale infatti l'interfaccia delle fifo non è adatta a risolvere questo tipo
di problemi, che possono essere affrontati in maniera più semplice ed efficace
o usando i \textit{socket}\index{socket} (che tratteremo in dettaglio a
-partire da \capref{cha:socket_intro}) o ricorrendo a diversi meccanismi di
-comunicazione, come quelli che esamineremo in \secref{sec:ipc_sysv}.
+partire da \capref{cha:socket_intro}) o ricorrendo a meccanismi di
+comunicazione diversi, come quelli che esamineremo in seguito.
\section{La comunicazione fra processi di System V}
\label{sec:ipc_sysv}
-Benché le pipe (e le fifo) siano ancora ampiamente usate, esse presentano
-numerosi limiti, il principale dei quali è che il meccanismo di comunicazione
-è rigidamente sequenziale; per questo una situazione in cui un processo scrive
-qualcosa che molti altri devono poter leggere non può essere implementata in
-maniera semplice con una pipe.
+Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
+limite fondamentale che il meccanismo di comunicazione che forniscono è
+rigidamente sequenziale: una situazione in cui un processo scrive qualcosa che
+molti altri devono poter leggere non può essere implementata con una pipe.
-Per superare questi limiti nello sviluppo di System V vennero introdotti una
-serie di nuovi oggetti di comunicazione e relative interfacce di
-programmazione in grado di garantire una maggiore flessibilità; in questa
-sezione esamineremo quello che viene ormai chiamato il \textsl{Sistema di
- comunicazione inter-processo} di System V, (o \textit{System V IPC
- (Inter-Process Comunication)}.
+Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
+oggetti per la comunicazione fra processi ed una nuova interfaccia di
+programmazione, che fossero in grado di garantire una maggiore flessibilità;
+in questa sezione esamineremo quello che viene ormai chiamato il
+\textsl{Sistema di comunicazione inter-processo} di System V, (o
+\textit{System V IPC (Inter-Process Comunication)}.
La principale caratteristica del sistema di IPC di System V è quella di essere
basato su oggetti permanenti che risiedono nel kernel. Questi, a differenza di
quanto avviene per i file descriptor, non mantengono un contatore dei
-riferimenti, pertanto non vengono cancellati dal sistema una volta che non
-sono più in uso. Questo comporta che, al contrario di quanto avviene per pipe
-e fifo, la memoria allocata per questi oggetti non viene rilasciata
-automaticamente, ed essi devono essere cancellati esplicitamente, altrimenti
-resteranno attivi fintanto che non si riavvia il sistema.
+riferimenti, e non vengono cancellati dal sistema una volta che non sono più
+in uso. Questo comporta che, al contrario di quanto avviene per pipe e fifo,
+la memoria allocata per questi oggetti non viene rilasciata automaticamente,
+ed essi devono essere cancellati esplicitamente, altrimenti resteranno attivi
+fino al riavvio del sistema.
Gli oggetti usati nel System V IPC vengono creati direttamente dal kernel, e
-sono accessibili solo specificando il relativo \textsl{identificatore}, che è
-il numero progressivo che il kernel gli assengna quanto vengono creati (il
-prodedimento è simile a quello con cui si assegna il \acr{pid} dei processi).
+sono accessibili solo specificando il relativo \textsl{identificatore}. Questo
+è il numero progressivo che il kernel assengna a ciascuno di questi oggetti
+quanto vengono creati (il prodedimento è simile a quello con cui si assegna il
+\acr{pid} ai processi).
L'identificatore è in genere restituito dalle funzioni che creano l'oggetto,
nasce quindi il problema di come processi diversi possono accedere allo stesso
oggetto. Per far questo a ciascuno di essi viene anche associata una
\textsl{chiave}, che può essere indicata in fasi di creazione. Usando la
stessa chiave due processi diversi potranno ricavare l'identificatore
-associato ad un oggetto e accedervi entrambi.
-
-Questa caratteristica mostra il primo dei problemi associati al sistema di IPC
-di System V. Un secondo problema riguarda le modalità per l'accesso a questi
-oggetti.
-
+associato ad un oggetto e accedervi entrambi.
+Il problema che sorge a questo punto è come due processi diversi possono
\subsection{Code di messaggi}
Lo standard POSIX.1b ha introdotto dei nuovi meccanismi di comunicazione,
rifacendosi a quelli di System V, introducendo una nuova interfaccia che
-evitasse i principali problemi evidenziati in ...
+evitasse i principali problemi evidenziati in coda a
+\secref{sec:ipc_sysv_generic}.
projects / gapil.git / blobdiff