Aggiunte figura dello schema del fortune server con le fifo
[gapil.git] / ipc.tex
1 \chapter{La comunicazione fra processi}
2 \label{cha:IPC}
3
4
5 Uno degli aspetti fondamentali della programmazione in un sistema unix-like è
6 la comunicazione fra processi. In questo capitolo affronteremo solo i
7 meccanismi più elementari che permettono di mettere in comunicazione processi
8 diversi, come quelli tradizionali che coinvolgono \textit{pipe} e
9 \textit{fifo} e i meccanismi di intercomunicazione di System V e quelli POSIX.
10
11 Tralasceremo invece tutte le problematiche relative alla comunicazione
12 attraverso la rete (e le relative interfacce) che saranno affrontate in
13 dettaglio in un secondo tempo.  Non affronteremo neanche meccanismi più
14 complessi ed evoluti come le RPC (\textit{Remote Procedure Calls}) e CORBA
15 (\textit{Common Object Request Brocker Architecture}) che in genere sono
16 implementati con un ulteriore livello sopra i meccanismi elementari.
17
18
19 \section{La comunicazione fra processi tradizionale}
20 \label{sec:ipc_unix}
21
22 Il primo meccanismo di comunicazione fra processi introdotto nei sistemi Unix,
23 è quello delle cosiddette \textit{pipe}; esse costituiscono una delle
24 caratteristiche peculiari del sistema, in particolar modo dell'interfaccia a
25 linea di comando. In questa sezione descriveremo le sue basi, le funzioni che
26 ne gestiscono l'uso e le varie forme in cui si è evoluto.
27
28
29 \subsection{Le \textit{pipe} standard}
30 \label{sec:ipc_pipes}
31
32 Le \textit{pipe} nascono sostanzialmente con Unix, e sono il primo, e tuttora
33 uno dei più usati, meccanismi di comunicazione fra processi. Si tratta in
34 sostanza di una una coppia di file descriptor\footnote{si tenga presente che
35   le pipe sono oggetti creati dal kernel e non risiedono su disco.} connessi
36 fra di loro in modo che se quanto scrive su di uno si può rileggere
37 dall'altro. Si viene così a costituire un canale di comunicazione tramite i
38 due file descriptor, nella forma di un \textsl{tubo} (da cui il nome)
39 attraverso cui fluiscono i dati.
40
41 La funzione che permette di creare questa speciale coppia di file descriptor
42 associati ad una \textit{pipe} è appunto \func{pipe}, ed il suo prototipo è:
43 \begin{prototype}{unistd.h}
44 {int pipe(int filedes[2])} 
45   
46 Crea una coppia di file descriptor associati ad una \textit{pipe}.
47   
48   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
49     errore, nel qual caso \var{errno} potrà assumere i valori \macro{EMFILE},
50     \macro{ENFILE} e \macro{EFAULT}.}
51 \end{prototype}
52
53 La funzione restituisce la coppia di file descriptor nell'array
54 \param{filedes}; il primo è aperto in lettura ed il secondo in scrittura. Come
55 accennato concetto di funzionamento di una pipe è semplice: quello che si
56 scrive nel file descriptor aperto in scrittura viene ripresentato tale e quale
57 nel file descriptor aperto in lettura. I file descriptor infatti non sono
58 connessi a nessun file reale, ma ad un buffer nel kernel, la cui dimensione è
59 specificata dalla costante \macro{PIPE\_BUF}, (vedi
60 \secref{sec:sys_file_limits}). Lo schema di funzionamento di una pipe è
61 illustrato in \figref{fig:ipc_pipe_singular}, in cui sono illustrati i due
62 capi della pipe, associati a ciascun file descriptor, con le frecce che
63 indicano la direzione del flusso dei dati.
64
65 \begin{figure}[htb]
66   \centering
67   \includegraphics[height=5cm]{img/pipe}
68   \caption{Schema della struttura di una pipe.}
69   \label{fig:ipc_pipe_singular}
70 \end{figure}
71
72 Chiaramente creare una pipe all'interno di un singolo processo non serve a
73 niente; se però ricordiamo quanto esposto in \secref{sec:file_sharing}
74 riguardo al comportamento dei file descriptor nei processi figli, è immediato
75 capire come una pipe possa diventare un meccanismo di intercomunicazione. Un
76 processo figlio infatti condivide gli stessi file descriptor del padre,
77 compresi quelli associati ad una pipe (secondo la situazione illustrata in
78 \figref{fig:ipc_pipe_fork}). In questo modo se uno dei processi scrive su un
79 capo della pipe, l'altro può leggere.
80
81 \begin{figure}[htb]
82   \centering
83   \includegraphics[height=5cm]{img/pipefork}
84   \caption{Schema dei collegamenti ad una pipe, condivisi fra processo padre e
85     figlio dopo l'esecuzione \func{fork}.}
86   \label{fig:ipc_pipe_fork}
87 \end{figure}
88
89 Tutto ciò ci mostra come sia immediato realizzare un meccanismo di
90 comunicazione fra processi attraverso una pipe, utilizzando le proprietà
91 ordinarie dei file, ma ci mostra anche qual'è il principale\footnote{Stevens
92   in \cite{APUE} riporta come limite anche il fatto che la comunicazione è
93   unidirezionale, ma in realtà questo è un limite facilmente superabile usando
94   una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i
95 processi possano condividere i file descriptor della pipe, e per questo essi
96 devono comunque essere \textsl{parenti} (dall'inglese \textit{siblings}), cioè
97 o derivare da uno stesso processo padre in cui è avvenuta la creazione della
98 pipe, o, più comunemente, essere nella relazione padre/figlio.
99
100 A differenza di quanto avviene con i file normali, la lettura da una pipe può
101 essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
102 pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
103 (vale a dire che la funzione \func{read} ritornerà restituendo 0).  Se invece
104 si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
105 processo riceverà il segnale \macro{EPIPE}, e la funzione di scrittura
106 restituirà un errore di \macro{EPIPE} (al ritorno del manipolatore, o qualora
107 il segnale sia ignorato o bloccato).
108
109 La dimensione del buffer della pipe (\macro{PIPE\_BUF}) ci dà inoltre un'altra
110 importante informazione riguardo il comportamento delle operazioni di lettura
111 e scrittura su di una pipe; esse infatti sono atomiche fintanto che la
112 quantità di dati da scrivere non supera questa dimensione. Qualora ad esempio
113 si effettui una scrittura di una quantità di dati superiore l'operazione verrà
114 effettuata in più riprese, consentendo l'intromissione di scritture effettuate
115 da altri processi.
116
117
118 \subsection{Un esempio dell'uso delle pipe}
119 \label{sec:ipc_pipe_use}
120
121 Per capire meglio il funzionamento delle pipe faremo un esempio di quello che
122 è il loro uso più comune, analogo a quello effettuato della shell, e che
123 consiste nell'inviare l'output di un processo (lo standard output) sull'input
124 di un'altro. Realizzeremo il programma di esempio nella forma di un
125 \textit{CGI}\footnote{Un CGI (\textit{Common Gateway Interface}) è un
126   programma che permette la creazione dinamica di un oggetto da inserire
127   all'interno di una pagina HTML.}  per apache, che genera una immagine JPEG
128 di un codice a barre, specificato come parametro di input.
129
130 Un programma che deve essere eseguito come \textit{CGI} deve rispondere a
131 delle caratteristiche specifiche, esso infatti non viene lanciato da una
132 shell, ma dallo stesso web server, alla richiesta di una specifica URL, che di
133 solito ha la forma:
134 \begin{verbatim}
135     http://www.sito.it/cgi-bin/programma?parametro
136 \end{verbatim}
137 ed il risultato dell'elaborazione deve essere presentato (con una intestazione
138 che ne descrive il mime-type) sullo standard output, in modo che il web-server
139 possa reinviarlo al browser che ha effettuato la richiesta, che in questo modo
140 è in grado di visualizzarlo opportunamente.
141
142 Per realizzare quanto voluto useremo in sequenza i programmi \cmd{barcode} e
143 \cmd{gs}, il primo infatti è in grado di generare immagini postscript di
144 codici a barre corrispondenti ad una qualunque stringa, mentre il secondo
145 serve per poter effettuare la conversione della stessa immagine in formato
146 JPEG. Usando una pipe potremo inviare l'output del primo sull'input del
147 secondo, secondo lo schema mostrato in \figref{fig:ipc_pipe_use}, in cui la
148 direzione del flusso dei dati è data dalle frecce continue.
149
150 \begin{figure}[htb]
151   \centering
152   \includegraphics[height=5cm]{img/pipeuse}
153   \caption{Schema dell'uso di una pipe come mezzo di comunicazione fra
154     due processi attraverso attraverso l'esecuzione una \func{fork} e la
155     chiusura dei capi non utilizzati.}
156   \label{fig:ipc_pipe_use}
157 \end{figure}
158
159 Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato
160 intermedio su un file temporaneo. Questo però non tiene conto del fatto che un
161 \textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una
162 evidente race condition in caso di accesso simultaneo a detto
163 file.\footnote{il problema potrebbe essere superato determinando in anticipo
164   un nome appropriato per il file temporaneo, che verrebbe utilizzato dai vari
165   sotto-processi, e cancellato alla fine della loro esecuzione; ma a questo le
166   cose non sarebbero più tanto semplici.}  L'uso di una pipe invece permette
167 di risolvere il problema in maniera semplice ed elegante, oltre ad essere
168 molto più efficiente, dato che non si deve scrivere su disco.
169
170 Il programma ci servirà anche come esempio dell'uso delle funzioni di
171 duplicazione dei file descriptor che abbiamo trattato in
172 \secref{sec:file_dup}, in particolare di \func{dup2}. È attraverso queste
173 funzioni infatti che è possibile dirottare gli stream standard dei processi
174 (che abbiamo visto in \secref{sec:file_std_descr} e
175 \secref{sec:file_std_stream}) sulla pipe. In \figref{fig:ipc_barcodepage_code}
176 abbiamo riportato il corpo del programma, il cui codice completo è disponibile
177 nel file \file{BarCodePage.c} che si trova nella directory dei sorgenti.
178
179
180 \begin{figure}[!htb]
181   \footnotesize \centering
182   \begin{minipage}[c]{15cm}
183     \begin{lstlisting}{}
184 int main(int argc, char *argv[], char *envp[])
185 {
186     ...
187     /* create two pipes, pipein and pipeout, to handle communication */
188     if ( (retval = pipe(pipein)) ) {
189         WriteMess("input pipe creation error");
190         exit(0);        
191     }
192     if ( (retval = pipe(pipeout)) ) {
193         WriteMess("output pipe creation error");
194         exit(0);        
195     }    
196     /* First fork: use child to run barcode program */
197     if ( (pid = fork()) == -1) {          /* on error exit */
198         WriteMess("child creation error");
199         exit(0);        
200     }
201     /* if child */
202     if (pid == 0) {
203         close(pipein[1]);                /* close pipe write end  */
204         dup2(pipein[0], STDIN_FILENO);   /* remap stdin to pipe read end */
205         close(pipeout[0]);
206         dup2(pipeout[1], STDOUT_FILENO); /* remap stdout in pipe output */
207         execlp("barcode", "barcode", size, NULL);
208     } 
209     close(pipein[0]);                    /* close input side of input pipe */
210     write(pipein[1], argv[1], strlen(argv[1]));  /* write parameter to pipe */
211     close(pipein[1]);                    /* closing write end */
212     waitpid(pid, NULL, 0);               /* wait child completion */
213     /* Second fork: use child to run ghostscript */
214     if ( (pid = fork()) == -1) {
215         WriteMess("child creation error");
216         exit(0);
217     }
218     /* second child, convert PS to JPEG  */
219     if (pid == 0) {                     
220         close(pipeout[1]);              /* close write end */
221         dup2(pipeout[0], STDIN_FILENO); /* remap read end to stdin */
222         /* send mime type */
223         write(STDOUT_FILENO, content, strlen(content));
224         execlp("gs", "gs", "-q", "-sDEVICE=jpeg", "-sOutputFile=-", "-", NULL);
225     }
226     /* still parent */
227     close(pipeout[1]); 
228     waitpid(pid, NULL, 0);
229     exit(0);
230 }
231     \end{lstlisting}
232   \end{minipage} 
233   \normalsize 
234   \caption{Sezione principale del codice del \textit{CGI} 
235     \file{BarCodePage.c}.}
236   \label{fig:ipc_barcodepage_code}
237 \end{figure}
238
239 La prima operazione del programma (\texttt{\small 4--12}) è quella di creare
240 le due pipe che serviranno per la comunicazione fra i due comandi utilizzati
241 per produrre il codice a barre; si ha cura di controllare la riuscita della
242 chiamata, inviando in caso di errore un messaggio invece dell'immagine
243 richiesta.\footnote{la funzione \func{WriteMess} non è riportata in
244   \secref{fig:ipc_barcodepage_code}; essa si incarica semplicemente di
245   formattare l'uscita alla maniera dei CGI, aggiungendo l'opportuno
246   \textit{mime type}, e formattando il messaggio in HTML, in modo che
247   quest'ultimo possa essere visualizzato correttamente da un browser.}
248
249 Una volta create le pipe, il programma può creare (\texttt{\small 13-17}) il
250 primo processo figlio, che si incaricherà (\texttt{\small 19--25}) di eseguire
251 \cmd{barcode}. Quest'ultimo legge dallo standard input una stringa di
252 caratteri, la converte nell'immagine postscript del codice a barre ad essa
253 corrispondente, e poi scrive il risultato direttamente sullo standard output.
254
255 Per poter utilizzare queste caratteristiche prima di eseguire \cmd{barcode} si
256 chiude (\texttt{\small 20}) il capo aperto in scrittura della prima pipe, e se
257 ne collega (\texttt{\small 21}) il capo in lettura allo standard input, usando
258 \func{dup2}. Si ricordi che invocando \func{dup2} il secondo file, qualora
259 risulti aperto, viene, come nel caso corrente, chiuso prima di effettuare la
260 duplicazione. Allo stesso modo, dato che \cmd{barcode} scrive l'immagine
261 postscript del codice a barre sullo standard output, per poter effettuare una
262 ulteriore redirezione il capo in lettura della seconda pipe viene chiuso
263 (\texttt{\small 22}) mentre il capo in scrittura viene collegato allo standard
264 output (\texttt{\small 23}).
265
266 In questo modo all'esecuzione (\texttt{\small 25}) di \cmd{barcode} (cui si
267 passa in \var{size} la dimensione della pagina per l'immagine) quest'ultimo
268 leggerà dalla prima pipe la stringa da codificare che gli sarà inviata dal
269 padre, e scriverà l'immagine postscript del codice a barre sulla seconda.
270
271 Al contempo una volta lanciato il primo figlio, il processo padre prima chiude
272 (\texttt{\small 26}) il capo inutilizzato della prima pipe (quello in input) e
273 poi scrive (\texttt{\small 27}) la stringa da convertire sul capo in output,
274 così che \cmd{barcode} possa riceverla dallo standard input. A questo punto
275 l'uso della prima pipe da parte del padre è finito ed essa può essere
276 definitivamente chiusa (\texttt{\small 28}), si attende poi (\texttt{\small
277   29}) che l'esecuzione di \cmd{barcode} sia completata.
278
279 Alla conclusione della sua esecuzione \cmd{barcode} avrà inviato l'immagine
280 postscript del codice a barre sul capo in scrittura della seconda pipe; a
281 questo punto si può eseguire la seconda conversione, da PS a JPEG, usando il
282 programma \cmd{gs}. Per questo si crea (\texttt{\small 30--34}) un secondo
283 processo figlio, che poi (\texttt{\small 35--42}) eseguirà questo programma
284 leggendo l'immagine postscript creata da \cmd{barcode} dallo standard input,
285 per convertirla in JPEG.
286
287 Per fare tutto ciò anzitutto si chiude (\texttt{\small 37}) il capo in
288 scrittura della seconda pipe, e se ne collega (\texttt{\small 38}) il capo in
289 lettura allo standard input. Per poter formattare l'output del programma in
290 maniera utilizzabile da un browser, si provvede anche \texttt{\small 40}) alla
291 scrittura dell'apposita stringa di identificazione del mime-type in testa allo
292 standard output. A questo punto si può invocare \texttt{\small 41}) \cmd{gs},
293 provvedendo gli appositi switch che consentono di leggere il file da
294 convertire dallo standard input e di inviare la conversione sullo standard
295 output.
296
297 Per completare le operazioni il processo padre chiude (\texttt{\small 44}) il
298 capo in scrittura della seconda pipe, e attende la conclusione del figlio
299 (\texttt{\small 45}); a questo punto può (\texttt{\small 46}) uscire. Si tenga
300 conto che l'operazione di chiudere il capo in scrittura della seconda pipe è
301 necessaria, infatti, se non venisse chiusa, \cmd{gs}, che legge il suo
302 standard input da detta pipe, resterebbe bloccato in attesa di ulteriori dati
303 in ingresso (l'unico modo che un programma ha per sapere che l'input è
304 terminato è rilevare che lo standard input è stato chiuso), e la \func{wait}
305 non ritornerebbe.
306
307
308 \subsection{Le funzioni \func{popen} e \func{pclose}}
309 \label{sec:ipc_popen}
310
311 Come si è visto la modalità più comune di utilizzo di una pipe è quella di
312 utilizzarla per fare da tramite fra output ed input di due programmi invocati
313 in sequenza; per questo motivo lo standard POSIX.2 ha introdotto due funzioni
314 che permettono di sintetizzare queste operazioni. La prima di esse si chiama
315 \func{popen} ed il suo prototipo è:
316 \begin{prototype}{stdio.h}
317 {FILE *popen(const char *command, const char *type)}
318
319 Esegue il programma \param{command}, di cui, a seconda di \param{type},
320 restituisce, lo standard input o lo standard output nella pipe collegata allo
321 stream restituito come valore di ritorno.
322   
323 \bodydesc{La funzione restituisce l'indirizzo dello stream associato alla pipe
324   in caso di successo e \macro{NULL} per un errore, nel qual caso \var{errno}
325   potrà assumere i valori relativi alle sottostanti invocazioni di \func{pipe}
326   e \func{fork} o \macro{EINVAL} se \param{type} non è valido.}
327 \end{prototype}
328
329 La funzione crea una pipe, esegue una \func{fork}, ed invoca il programma
330 \param{command} attraverso la shell (in sostanza esegue \file{/bin/sh} con il
331 flag \code{-c}); l'argomento \param{type} deve essere una delle due stringhe
332 \verb|"w"| o \verb|"r"|, per indicare se la pipe sarà collegata allo standard
333 input o allo standard output del comando invocato.
334
335 La funzione restituisce il puntatore allo stream associato alla pipe creata,
336 che sarà aperto in sola lettura (e quindi associato allo standard output del
337 programma indicato) in caso si sia indicato \code{"r"}, o in sola scrittura (e
338 quindi associato allo standard input) in caso di \code{"w"}.
339
340 Lo stream restituito da \func{popen} è identico a tutti gli effetti ai file
341 stream visti in \secref{cha:files_std_interface}, anche se è collegato ad una
342 pipe e non ad un inode, e viene sempre aperto in modalità
343 \textit{fully-buffered} (vedi \secref{sec:file_buffering}); l'unica differenza
344 con gli usuali stream è che dovrà essere chiuso dalla seconda delle due nuove
345 funzioni, \func{pclose}, il cui prototipo è:
346 \begin{prototype}{stdio.h}
347 {int pclose(FILE *stream)}
348
349 Chiude il file \param{stream}, restituito da una precedente \func{popen}
350 attendendo la terminazione del processo ad essa associato.
351   
352 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
353   errore; nel quel caso il valore di \func{errno} deriva dalle sottostanti
354   chiamate.}
355 \end{prototype}
356 \noindent che oltre alla chiusura dello stream si incarica anche di attendere
357 (tramite \func{wait4}) la conclusione del processo creato dalla precedente
358 \func{popen}.
359
360 Per illustrare l'uso di queste due funzioni riprendiamo il problema
361 precedente: il programma mostrato in \figref{fig:ipc_barcodepage_code} per
362 quanto funzionante, è (volutamente) codificato in maniera piuttosto complessa,
363 inoltre nella pratica sconta un problema di \cmd{gs} che non è in
364 grado\footnote{nella versione GNU Ghostscript 6.53 (2002-02-13).} di
365 riconoscere correttamente l'encapsulated postscript, per cui deve essere usato
366 il postscript e tutte le volte viene generata una pagina intera, invece che
367 una immagine delle dimensioni corrispondenti al codice a barre.
368
369 Se si vuole generare una immagine di dimensioni appropriate si deve usare un
370 approccio diverso. Una possibilità sarebbe quella di ricorrere ad ulteriore
371 programma, \cmd{epstopsf}, per convertire in PDF un file EPS (che può essere
372 generato da \cmd{barcode} utilizzando lo switch \cmd{-E}).  Utilizzando un PDF
373 al posto di un EPS \cmd{gs} esegue la conversione rispettando le dimensioni
374 originarie del codice a barre e produce un JPEG di dimensioni corrette.
375
376 Questo approccio però non funziona, per via di una delle caratteristiche
377 principali delle pipe. Per poter effettuare la conversione di un PDF infatti è
378 necessario, per la struttura del formato, potersi spostare (con \func{lseek})
379 all'interno del file da convertire; se si eseguela conversione con \cmd{gs} su
380 un file regolare non ci sono problemi, una pipe però è rigidamente
381 sequenziale, e l'uso di \func{lseek} su di essa fallisce sempre con un errore
382 di \macro{ESPIPE}, rendendo impossibile la conversione.  Questo ci dice che in
383 generale la concatenazione di vari programmi funzionerà soltanto quando tutti
384 prevedono una lettura sequenziale del loro input.
385
386 Per questo motivo si è dovuto utilizzare un procedimento diverso, eseguendo
387 prima la conversione (sempre con \cmd{gs}) del PS in un altro formato
388 intermedio, il PPM,\footnote{il \textit{Portable PixMap file format} è un
389   formato usato spesso come formato intermedio per effettuare conversioni, è
390   infatti molto facile da manipolare, dato che usa caratteri ASCII per
391   memorizzare le immagini, anche se per questo è estremamente inefficiente.}
392 dal quale poi si può ottenere un'immagine di dimensioni corrette attraverso
393 vari programmi di manipolazione (\cmd{pnmcrop}, \cmd{pnmmargin}) che può
394 essere infine trasformata in PNG (con \cmd{pnm2png}).
395
396 In questo caso però occorre eseguire in sequenza ben quattro comandi diversi,
397 inviando l'output di ciascuno all'input del successivo, per poi ottenere il
398 risultato finale sullo standard output: un caso classico di utilizzazione
399 delle pipe, in cui l'uso di \func{popen} e \func{pclose} permette di
400 semplificare notevolmente la stesura del codice.
401
402 Nel nostro caso, dato che ciascun processo deve scrivere il suo output sullo
403 standard input del successivo, occorrerà usare \func{popen} aprendo la pipe in
404 scrittura. Il codice del nuovo programma è riportato in
405 \figref{fig:ipc_barcode_code}.  Come si può notare l'ordine di invocazione dei
406 programmi è l'inverso di quello in cui ci si aspetta che vengano
407 effettivamente eseguiti. Questo non comporta nessun problema dato che la
408 lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato
409 per primo, si bloccherà in attesa di ricevere sullo standard input il
410 risultato dell'elaborazione del precedente, benchè quest'ultimo venga
411 invocato dopo.
412
413 \begin{figure}[!htb]
414   \footnotesize \centering
415   \begin{minipage}[c]{15cm}
416     \begin{lstlisting}{}
417 int main(int argc, char *argv[], char *envp[])
418 {
419     FILE *pipe[4];
420     FILE *pipein;
421     char *cmd_string[4]={
422         "pnmtopng",
423         "pnmmargin -white 10",
424         "pnmcrop",
425         "gs -sDEVICE=ppmraw -sOutputFile=- -sNOPAUSE -q - -c showpage -c quit"
426     };  
427     char content[]="Content-type: image/png\n\n";
428     int i;
429     /* write mime-type to stout */ 
430     write(STDOUT_FILENO, content, strlen(content));
431     /* execute chain of command */
432     for (i=0; i<4; i++) {
433         pipe[i] = popen(cmd_string[i], "w");
434         dup2(fileno(pipe[i]), STDOUT_FILENO); 
435     }
436     /* create barcode (in PS) */
437     pipein = popen("barcode", "w");
438     /* send barcode string to barcode program */
439     write(fileno(pipein), argv[1], strlen(argv[1]));
440     /* close all pipes (in reverse order) */
441     for (i=4; i==0; i--) {
442         pclose((pipe[i]));
443     }
444     exit(0);
445 }
446     \end{lstlisting}
447   \end{minipage} 
448   \normalsize 
449   \caption{Codice completo del \textit{CGI} \file{BarCode.c}.}
450   \label{fig:ipc_barcode_code}
451 \end{figure}
452
453 Nel nostro caso il primo passo (\texttt{\small 14}) è scrivere il mime-type
454 sullo standard output; a questo punto il processo padre non necessita più di
455 eseguire ulteriori operazioni sullo standard output e può tranquillamente
456 provvedere alla redirezione.
457
458 Dato che i vari programmi devono essere lanciati in successione, si è
459 approntato un ciclo (\texttt{\small 15--19}) che esegue le operazioni in
460 sequenza: prima crea una pipe (\texttt{\small 17}) per la scrittura eseguendo
461 il programma con \func{popen}, in modo che essa sia collegata allo standard
462 input, e poi redirige (\texttt{\small 18}) lo standard output su detta pipe.
463
464 In questo modo il primo processo ad essere invocato (che è l'ultimo della
465 catena) scriverà ancora sullo standard output del processo padre, ma i
466 successivi, a causa di questa redirezione, scriveranno sulla pipe associata
467 allo standard input del processo invocato nel ciclo precedente.
468
469 Alla fine tutto quello che resta da fare è lanciare (\texttt{\small 21}) il
470 primo processo della catena, che nel caso è \cmd{barcode}, e scrivere
471 (\texttt{\small 23}) la stringa del codice a barre sulla pipe, che è collegata
472 al suo standard input, infine si può eseguire (\texttt{\small 24--27}) un
473 ciclo che chiuda, nell'ordine inverso rispetto a quello in cui le si sono
474 create, tutte le pipe create con \func{pclose}.
475
476
477 \subsection{Le \textit{pipe} con nome, o \textit{fifo}}
478 \label{sec:ipc_named_pipe}
479
480 Come accennato in \secref{sec:ipc_pipes} il problema delle \textit{pipe} è che
481 esse possono essere utilizzate solo da processi con un progenitore comune o
482 nella relazione padre/figlio; per superare questo problema lo standard POSIX.1
483 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
484 caratteristiche delle pipe, ma che invece di essere strutture interne del
485 kernel, visibili solo attraverso un file descriptor, sono accessibili
486 attraverso un inode che risiede sul filesystem, così che i processi le possono
487 usare senza dovere per forza essere in una relazione di \textsl{parentela}.
488
489 Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
490 attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
491 l'inode allocato sul filesystem serve infatti solo a fornire un punto di
492 riferimento per i processi, che permetta loro di accedere alla stessa fifo; il
493 comportamento delle funzioni di lettura e scrittura è identico a quello
494 illustrato per le pipe in \secref{sec:ipc_pipes}.
495
496 Abbiamo già visto in \secref{sec:file_mknod} le funzioni \func{mknod} e
497 \func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
498 processo non avrà che da aprire il relativo file speciale o in lettura o
499 scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
500 leggere, nel secondo al capo di ingresso, e dovrà scrivere.
501
502 Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
503 essere acceduta contemporaneamente da più processi, sia in lettura che in
504 scrittura. Dato che per funzionare deve essere aperta in entrambe le
505 direzioni, per una fifo di norma la funzione \func{open} si blocca se viene
506 eseguita quando l'altro capo non è aperto.
507
508 Le fifo però possono essere anche aperte in modalità \textsl{non-bloccante},
509 nel qual caso l'apertura del capo in lettura avrà successo solo quando anche
510 l'altro capo è aperto, mentre l'apertura del capo in scrittura restituirà
511 l'errore di \macro{ENXIO} fintanto che non verrà aperto il capo in lettura.
512
513 In Linux è possibile aprire le fifo anche in lettura/scrittura,\footnote{lo
514   standard POSIX lascia indefinito il comportamento in questo caso.}
515 operazione che avrà sempre successo immediato qualunque sia la modalità di
516 apertura (bloccante e non bloccante); questo può essere utilizzato per aprire
517 comunque una fifo in scrittura anche se non ci sono ancora processi il
518 lettura; è possibile anche usare la fifo all'interno di un solo processo, nel
519 qual caso però occorre stare molto attenti alla possibili
520 deadlock.\footnote{se si cerca di leggere da una fifo che non contiene dati si
521   avrà un deadlock immediato, dato che il processo si blocca e non potrà
522   quindi mai eseguire le funzioni di scrittura.}
523
524 Per la loro caratteristica di essere accessibili attraverso il filesystem, è
525 piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle
526 situazioni un processo deve ricevere informazioni da altri. In questo caso è
527 fondamentale che le operazioni di scrittura siano atomiche; per questo si deve
528 sempre tenere presente che questo è vero soltanto fintanto che non si supera
529 il limite delle dimensioni di \macro{PIPE\_BUF} (si ricordi quanto detto in
530 \secref{sec:ipc_pipes}).
531
532 A parte il caso precedente, che resta probabilmente il più comune, Stevens
533 riporta in \cite{APUE} altre due casistiche principali per l'uso delle fifo:
534 \begin{itemize}
535 \item Da parte dei comandi di shell, per evitare la creazione di file
536   temporanei quando si devono inviare i dati di uscita di un processo
537   sull'input di parecchi altri (attraverso l'uso del comando \cmd{tee}).
538   
539 \item Come canale di comunicazione fra client ed server (il modello
540   \textit{client-server} è illustrato in \secref{sec:net_cliserv}).
541 \end{itemize}
542
543 Nel primo caso quello che si fa è creare tante fifo, da usare come standard
544 input, quanti sono i processi a cui i vogliono inviare i dati, questi ultimi
545 saranno stati posti in esecuzione ridirigendo lo standard input dalle fifo, si
546 potrà poi eseguire il processo che fornisce l'output replicando quest'ultimo,
547 con il comando \cmd{tee}, sulle varie fifo.
548
549 Il secondo caso è relativamente semplice qualora si debba comunicare con un
550 processo alla volta (nel qual caso basta usare due fifo, una per leggere ed
551 una per scrivere), le cose diventano invece molto più complesse quando si
552 vuole effettuare una comunicazione fra il server ed un numero imprecisato di
553 client; se il primo infatti può ricevere le richieste attraverso una fifo
554 ``nota'', per le risposte non si può fare altrettanto, dato che, per la
555 struttura sequenziale delle fifo, i client dovrebbero sapere, prima di
556 leggerli, quando i dati inviati sono destinati a loro.
557
558 Per risolvere questo problema, si può usare un'architettura come quella
559 illustrata in \figref{fig:ipc_fifo_server_arch} in cui i client inviano le
560 richieste al server su una fifo nota mentre le risposte vengono reinviate dal
561 server a ciascuno di essi su una fifo temporanea creata per l'occazione.
562
563 \begin{figure}[htb]
564   \centering
565   \includegraphics[height=9cm]{img/fifoserver}
566   \caption{Schema dell'utilizzo delle fifo nella realizzazione di una
567   architettura di comunicazione client/server.}
568   \label{fig:ipc_fifo_server_arch}
569 \end{figure}
570
571 Come esempio di uso questa architettura e dell'uso delle fifo, abbiamo scritto
572 un server di \textit{fortunes}, che restituisce, alle richieste di un client,
573 un detto a caso estratto da un insieme di frasi; sia il numero delle frasi
574 dell'insieme, che i file da cui esse vengono lette all'avvio, sono importabili
575 da riga di comando. Il corpo principale del server è riportato in
576 \figref{fig:ipc_fifo_server}, dove si è tralasciata la parte che tratta la
577 gestione delle opzioni a riga di comando, che effettua il settaggio delle
578 variabili \var{fortunefilename}, che indica il file da cui leggere le frasi,
579 ed \var{n}, che indica il numero di frasi tenute in memoria, ad un valore
580 diverso da quelli preimpostati. Il codice completo è nel file
581 \file{FortuneServer.c}.
582
583 \begin{figure}[!htb]
584   \footnotesize \centering
585   \begin{minipage}[c]{15cm}
586     \begin{lstlisting}{}
587 int main(int argc, char *argv[])
588 {
589     int i, n = 10;
590     char *fortunefilename = "/usr/share/games/fortunes/kids";
591     char *fifoname = "/tmp/fortune.fifo";
592     char **fortune;
593     char line[80];
594     int fifo_server, fifo_client;
595     int nread;
596     ...
597     if (n==0) usage();          /* if no pool depth exit printing usage info */
598     i = FortuneParse(fortunefilename, fortune, n);          /* parse phrases */
599     /* 
600      * Comunication section 
601      */
602     if (mkfifo(fifoname, 0622)) {  /* create well known fifo if does't exist */
603         if (errno!=EEXIST) {
604             perror("Cannot create well known fifo");
605             exit(-1);
606         }
607     }
608     while (1) {
609         fifo_server = open(fifoname, O_RDONLY);      /* open well known fifo */
610         if (fifo_server < 0) {
611             perror("Cannot open well known fifo");
612             exit(-1);
613         }
614         nread = read(fifo_server, line, 79);                 /* read request */
615         line[nread] = 0;
616         n = random() % i;                             /* select random value */
617         fifo_client = open(line, O_WRONLY);              /* open client fifo */
618         nread = write(fifo_client,                           /* write phrase */
619                       fortune[n], strlen(fortune[n])+1);
620         close(fifo_client);                         /* close well known fifo */
621         close(fifo_server);                             /* close client fifo */
622     }
623 }
624     \end{lstlisting}
625   \end{minipage} 
626   \normalsize 
627   \caption{Sezione principale del codice del server di \textit{fortunes}
628     basato sulle fifo.}
629   \label{fig:ipc_fifo_server}
630 \end{figure}
631
632 Il server richiede (\texttt{\small 11}) che sia stata impostata una dimensione
633 dell'insieme delle frasi non nulla, stampando, nel caso ciò non avvenga, un
634 messaggio apposito ed uscendo. Poi (\texttt{\small 12}) effettua la chiamata
635 alla funzione \code{FortuneParse} che legge dal file specificato in
636 \var{fortunefilename} le prime \var{n} frasi e le memorizza nel vettore di
637 puntatori \var{fortune}. Il codice della funzione non è riportato, in quanto
638 non direttamente attinente allo scopo dell'esempio, lo si può trovare nel file
639 \file{FortuneParse.c} allegato coi sorgenti degli esempi.
640
641 Il passo successivo \texttt{\small 16--21}) è quello di creare, se non esiste
642 già, la fifo nota sulla quale il server ascolterà le richieste, qualora si
643 riscontri un errore il server uscirà (escludendo ovviamente il caso in cui la
644 funzione \func{mkfifo} fallisce per la precedente esistenza della fifo. 
645
646 Fatto questo si entra nel ciclo principale del programma \texttt{\small
647   22--36}), che viene eseguito indefinitamente (l'uscita del server deve
648 essere effettuata tramite segnale), e che provvede a fornire le risposte ai
649 client. Il server è progettato per accettare le richieste dai client che
650 devono scrivere il nome della fifo sulla quale vogliono ricevere la risposta
651 sulla fifo su cui il server è in ascolto.
652
653 Il primo passo è aprire in lettura la fifo (\texttt{\small 23}), se nessun
654 client ha effettuato una richiesta la fifo non ha capi aperti in scrittura, e
655 pertanto il server si bloccherà. Una volta che un client ha aperto la fifo in
656 scrittura il server si sbloccherà ed effetturà la lettura (\texttt{\small 28})
657 della richiesta del client (nel caso limitata a 79 byte).
658
659 Dopo di che verrà calcolato (\texttt{\small 30}) un numero casuale nel range
660 delle frasi disponibili nella nostra lista, e verrà aperta (\texttt{\small
661   31}) la fifo sulla quale il client vuole ricevere la risposta, che sarà poi
662 scritta (\texttt{\small 32}). Dopo di che \texttt{\small 34--35}) entrambe le
663 fifo verranno chiuse.
664
665
666 Benché il nostro sistema client-server funzioni, la sua struttura è piuttosto
667 complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
668   che esamina questa architettura in \cite{APUE}, nota come sia impossibile
669   per il server sapere se un client è andato in crash, con la possibilità di
670   far restare le fifo temporanee sul filesystem, come sia necessario
671   intercettare \macro{SIGPIPE} dato che un client può terminare dopo aver
672   fatto una richiesta, ma prima che la risposta sia inviata, e come occorra
673   gestire il caso in cui non ci sono client attivi (e la lettura dalla fifo
674   nota restituisca al serve un end-of-file.}; in generale infatti
675 l'interfaccia delle fifo non è adatta a risolvere questo tipo di problemi, che
676 possono essere affrontati in maniera più semplice ed efficace o usando i
677 \textit{socket}\index{socket} (che tratteremo in dettaglio a partire da
678 \capref{cha:socket_intro}) o ricorrendo a meccanismi di comunicazione diversi,
679 come quelli che esamineremo in seguito.
680
681
682
683 \section{La comunicazione fra processi di System V}
684 \label{sec:ipc_sysv}
685
686 Benché le pipe e le fifo siano ancora ampiamente usate, esse scontano il
687 limite fondamentale che il meccanismo di comunicazione che forniscono è
688 rigidamente sequenziale: una situazione in cui un processo scrive qualcosa che
689 molti altri devono poter leggere non può essere implementata con una pipe.
690
691 Per questo nello sviluppo di System V vennero introdotti una serie di nuovi
692 oggetti per la comunicazione fra processi ed una nuova interfaccia di
693 programmazione, che fossero in grado di garantire una maggiore flessibilità.
694 In questa sezione esamineremo come Linux supporta quello che viene ormai
695 chiamato il \textsl{Sistema di comunicazione inter-processo} di System V, o
696 \textit{System V IPC (Inter-Process Comunication)}.
697
698
699
700 \subsection{Considerazioni generali}
701 \label{sec:ipc_sysv_generic}
702
703 La principale caratteristica del sistema di IPC di System V è quella di essere
704 basato su oggetti permanenti che risiedono nel kernel. Questi, a differenza di
705 quanto avviene per i file descriptor, non mantengono un contatore dei
706 riferimenti, e non vengono cancellati dal sistema una volta che non sono più
707 in uso. 
708
709 Questo comporta due problemi: il primo è che, al contrario di quanto avviene
710 per pipe e fifo, la memoria allocata per questi oggetti non viene rilasciata
711 automaticamente quando nessuno li vuole più utilizzare, ed essi devono essere
712 cancellati esplicitamente, se non si vuole che restino attivi fino al riavvio
713 del sistema. Il secondo è che, dato che non c'è un contatore di riferimenti,
714 essi possono essere cancellati anche se ci sono dei processi che li stanno
715 utilizzando, con tutte le conseguenze (negative) del caso.
716
717 Gli oggetti usati nel System V IPC vengono creati direttamente dal kernel, e
718 sono accessibili solo specificando il relativo \textsl{identificatore}. Questo
719 è un numero progressivo (un po' come il \acr{pid} dei processi) che il kernel
720 assegna a ciascuno di essi quanto vengono creati (sul prodedimento di
721 assegnazione torneremo in \secref{sec:ipc_sysv_id_use}). L'identificatore
722 viene restituito dalle funzioni che creano l'oggetto, ed è quindi locale al
723 processo che le ha eseguite. Dato che l'identificatore viene assegnato
724 dinamicamente dal kernel non è possibile prevedere quale sarà, ne utilizzare
725 un qualche valore statico, si pone perciò il problema di come processi diversi
726 possono accedere allo stesso oggetto.
727
728 Per risolvere il problema il kernel associa a ciascun oggetto una struttura
729 \var{ipc\_perm}; questa contiene una \textsl{chiave}, identificata da una
730 variabile del tipo primitivo \type{key\_t}, che viene specificata in fase di
731 creazione e tramite la quale è possibile ricavare l'identificatore. La
732 struttura, la cui definizione è riportata in \figref{fig:ipc_ipc_perm},
733 contiene anche le varie proprietà associate all'oggetto. 
734
735 \begin{figure}[!htb]
736   \footnotesize \centering
737   \begin{minipage}[c]{15cm}
738     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm ]{}
739 struct ipc_perm
740 {
741     key_t key;                        /* Key.  */
742     uid_t uid;                        /* Owner's user ID.  */
743     gid_t gid;                        /* Owner's group ID.  */
744     uid_t cuid;                       /* Creator's user ID.  */
745     gid_t cgid;                       /* Creator's group ID.  */
746     unsigned short int mode;          /* Read/write permission.  */
747     unsigned short int seq;           /* Sequence number.  */
748 };
749     \end{lstlisting}
750   \end{minipage} 
751   \normalsize 
752   \caption{La struttura \var{ipc\_perm}, come definita in \file{sys/ipc.h}.} 
753   \label{fig:ipc_ipc_perm}
754 \end{figure}
755
756 Usando la stessa chiave due processi diversi possono ricavare l'identificatore
757 associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
758 come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
759 sono \textsl{parenti} la soluzione è relativamente semplice, in tal caso
760 infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
761 nuovo oggetto nel processo padre, l'idenficatore così ottenuto sarà
762 disponibile in tutti i figli, e potrà essere passato come parametro attraverso
763 una \func{exec}.
764
765 Però quando i processi non sono \textsl{parenti} (come capita tutte le volte
766 che si ha a che fare con un sistema client-server) tutto questo non è
767 possibile; si potebbe comunque salvare l'identificatore su un file noto, ma
768 questo ovviamente comporta lo svantaggio di doverselo andare a rileggere.  Una
769 alternativa più efficace è quella che i programmi usino un valore comune per
770 la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
771 sempre il rischio che questa chiave possa essere stata già utilizzata da
772 qualcun altro.  Dato che non esiste una convenzione su come assegnare queste
773 chiavi in maniera univoca l'interfaccia mette a disposizione una funzione,
774 \func{ftok}, che permette di ottenere una chiave specificando il nome di un
775 file ed un numero di versione; il suo prototipo è:
776 \begin{functions}
777   \headdecl{sys/types.h} 
778   \headdecl{sys/ipc.h} 
779   
780   \funcdecl{key\_t ftok(const char *pathname, int proj\_id)}
781   
782   Restituisce una chiave per identificare un oggetto del System V IPC.
783   
784   \bodydesc{La funzione restituisce la chiave in caso di successo e -1
785   altrimenti, nel qual caso \var{errno} viene settata ad uno dei possibili
786   codici di errore di \func{stat}.}
787 \end{functions}
788
789 La funzione determina un valore della chiave sulla base di \param{pathname},
790 che deve specificare il pathname di un file effettivamente esistente e di un
791 numero di progetto \param{proj\_id)}, che di norma viene specificato come
792 carattere, dato che ne vengono utilizzati solo gli 8 bit meno
793 significativi.\footnote{nelle libc4 e libc5, come avviene in SunOS,
794   l'argomento \param{proj\_id)} è dichiarato tipo \ctyp{char}, le \acr{glibc}
795   han modificato il prototipo, ma vengono lo stesso utilizzati gli 8 bit meno
796   significativi.}
797
798 Il problema è che anche così non c'è la sicurezza che il valore della chiave
799 sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
800 con i 16 bit meno significativi dell'inode del file \param{pathname} (che
801 vengono ottenuti attraverso \func{stat}, da cui derivano i possibili errori),
802 e gli 8 bit meno significativi del numero del device su cui è il file. Diventa
803 perciò relativamente facile ottenere delle collisioni, specie se i file sono
804 su dispositivi con lo stesso \textit{minor number}, come \file{/dev/hda1} e
805 \file{/dev/sda1}.
806
807 In genere quello che si fa è utilizzare un file comune usato dai programmi che
808 devono comunicare (ad esempio un haeder, o uno dei programmi che devono usare
809 l'oggetto in questione), utilizzando il numero di progetto per ottere le
810 chiavi che interessano. In ogni caso occorre sempre controllare, prima di
811 creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
812 bene in fase di creazione, le cose possono complicarsi per i programmi che
813 devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
814 attributi di \var{ipc\_perm}, non esiste una modalità semplice per essere
815 sicuri della validità di una certa chiave.
816
817 Questo è, insieme al fatto che gli oggetti sono permanenti e non mantengono un
818 contatore di riferimenti per la cancellazione automatica, il principale
819 problema del sistema di IPC di System V. Non esiste infatti una modalità
820 chiara per identificare un oggetto, come sarebbe stato se lo si fosse
821 associato ad in file, e tutta l'interfaccia è inutilmente complessa.  Per
822 questo ne è stata effettuata una revisione completa nello standard POSIX.1b,
823 che tratteremo in \secref{sec:ipc_posix}.
824
825
826 \subsection{Il controllo di accesso}
827 \label{sec:ipc_sysv_access_control}
828
829 Oltre alle chiavi, abbiamo visto che ad ogni oggetto sono associate in
830 \var{ipc\_perm} ulteriori informazioni, come gli identificatori del creatore
831 (nei campi \var{cuid} e \var{cgid}) e del proprietario (nei campi \var{uid} e
832 \var{gid}) dello stesso, e un insieme di permessi (nel campo \var{mode}). In
833 questo modo è possibile definire un controllo di accesso sugli oggetti, simile
834 a quello che si ha per i file (vedi \secref{sec:file_perm_overview}).  
835
836 Benché il controllo di accesso relativo agli oggetti di intercomunicazione sia
837 molto simile a quello dei file, restano delle importanti differenze. La prima
838 è che il permesso di esecuzione non esiste (e viene ignorato), per cui si può
839 parlare solo di permessi di lettura e scrittura (nel caso dei semafori poi
840 quest'ultimo è più propriamente il permesso di modificarne lo stato). I valori
841 di \var{mode} sono gli stessi ed hanno lo stesso significato di quelli
842 riportati in \secref{tab:file_mode_flags}\footnote{se però si vogliono usare
843   le costanti simboliche ivi definite occorrerà includere il file
844   \file{sys/stat.h}, alcuni sistemi definiscono le costanti \macro{MSG\_R}
845   (\texttt{0400}) e \macro{MSG\_W} (\texttt{0200}) per indicare i permessi
846   base di lettura e scrittura per il proprietario, da utilizzare, con gli
847   opportuni shift, pure per il gruppo e gli altri, in Linux, visto la loro
848   scarsa utilità, queste costanti non sono definite.} e come per i file
849 definiscono gli accessi per il proprietario, il suo gruppo e tutti gli altri.
850
851 Si tenga presente che per gli oggetti di IPC han senso solo i permessi di
852 lettura e scrittura, quelli di esecuzione vengono ignorati. Quando l'oggetto
853 viene creato i campi \var{cuid} e \var{uid} di \var{ipc\_perm} ed i campi
854 \var{cgid} e \var{gid} vengono settati rispettivamente al valore dell'userid e
855 del groupid effettivo del processo che ha chiamato la funzione, ma mentre i
856 campi \var{uid} e \var{gid} possono essere cambiati, \var{cuid} e \var{cgid}
857 restano sempre gli stessi.
858
859 Il controllo di accesso è effettuato a due livelli. Il primo è nelle funzioni
860 che richiedono l'identificatore di un oggetto data la chiave, che specificano
861 tutte un argomento \param{flag}.  In tal caso quando viene effettuata la
862 ricerca di una chiave, se \param{flag} specifica dei permessi, questi vengono
863 controllati e l'identificatore viene restituito solo se essi corrispondono a
864 quelli dell'oggetto. Se sono presenti dei permessi non presenti in \var{mode}
865 l'accesso sarà invece negato. Questo però è di utilità indicativa, dato che è
866 sempre possibile specificare un valore nullo per \param{flag}, nel qual caso
867 il controllo avrà sempre successo.
868
869 Il secondo livello è quello delle varie funzioni che accedono (in lettura o
870 scrittura) all'oggetto. In tal caso lo schema dei controlli è simile a quello
871 dei file, ed avviene secondo questa sequenza:
872 \begin{itemize}
873 \item se il processo ha i privilegi di amministatore l'accesso è sempre
874   consentito. 
875 \item se l'userid effettivo del processo corrisponde o al valore del campo
876   \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
877   in \var{mode} è appropriato\footnote{per appropriato si intende che è
878     settato il permesso di scrittura per le operazioni di scrittura e quello
879     di lettura per le operazioni di lettura.} l'accesso è consentito.
880 \item se il groupid effettivo del processo corrisponde o al
881   valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
882   per il gruppo in \var{mode} è appropriato l'accesso è consentito.
883 \item se il permesso per gli altri è appropriato l'accesso è consentito.
884 \end{itemize}
885 solo se tutti i controlli elencati falliscono l'accesso è negato. Si noti che
886 a differenza di quanto avviene per i permessi dei file, fallire in uno dei
887 passi elencati non comporta il fallimento dell'accesso. Un'altra differenza è
888 che per gli oggetti di IPC il valore di \var{umask} (si ricordi quanto esposto
889 in \secref{sec:file_umask}) non ha alcun effetto.
890
891
892 \subsection{Gli identificatori ed il loro utilizzo}
893 \label{sec:ipc_sysv_id_use}
894
895 L'unico campo di \var{ipc\_perm} del quale non abbiamo ancora parlato è
896 \var{seq}, che in \figref{fig:ipc_ipc_perm} è qualificato con un criptico
897 ``\textit{numero di sequenza}'', ne parliamo adesso dato che esso è
898 strettamente attinente alle modalità con cui il kernel assegna gli
899 identificatori degli oggetti del sistema di IPC.
900
901 Quando il sistema si avvia, alla creazione di ogni nuovo oggetto di IPC viene
902 assegnato un numero progressivo, pari al numero di oggetti di quel tipo
903 esistenti. Se il comportamente fosse sempre questo sarebbe identico a quello
904 usato nell'assegnazione dei file descriptor nei processi, ed i valori degli
905 identificatori tenderebbero ad essere riutilizzati spesso e restare di piccole
906 dimensioni ed inferiori al numero massimo di oggetti diponibili.
907
908 Questo va benissimo nel caso dei file descriptor, che sono locali ad un
909 processo, ma qui il comportamento varrebbe per tutto il sistema, e per
910 processi del tutto scorrelati fra loro. Così si potrebbero avere situazioni
911 come quella in cui un server esce e cancella le sue code di messaggi, ed il
912 relativo identificatore viene immediatamente assegnato a quelle di un altro
913 server partito subito dopo, con la possibilità che i client del primo non
914 facciano in tempo ad accorgersi dell'avvenuto, e finiscano con l'interagire
915 con gli oggetti del secondo, con conseguenze imprevedibili.
916
917 Proprio per evitare questo tipo di situazioni il sistema usa il valore di
918 \var{req} per provvedere un meccanismo che porti gli identificatori ad
919 assumere tutti i valori possibili, rendendo molto più lungo il periodo in cui
920 un identificatore può venire riutilizzato.
921
922 Il sistema dispone sempre di un numero fisso di oggetti di IPC,\footnote{fino
923   al kernel 2.2.x questi valori, definiti dalle costanti \macro{MSGMNI},
924   \macro{SEMMNI} e \macro{SHMMNI}, potevano essere cambiati (come tutti gli
925   altri limiti relativi al \textit{System V IPC}) solo con una ricompilazione
926   del kernel, andando a modificarne la definizione nei relativi haeder file.
927   A partire dal kernel 2.4.x è possibile cambiare questi valori a sistema
928   attivo scrivendo sui file \file{shmmni}, \file{msgmni} e \file{sem} di
929   \file{/proc/sys/kernel} o con l'uso di \texttt{syscntl}.} e per ciascuno di
930 essi viene mantenuto in \var{seq} un numero di sequenza progressivo che viene
931 incrementato di uno ogni volta che l'oggetto viene cancellato. Quando
932 l'oggetto viene creato usando uno spazio che era già stato utilizzato in
933 precedenza per restituire l'identificatore al numero di oggetti presenti viene
934 sommato il valore di \var{seq} moltiplicato per il numero massimo di oggetti
935 di quel tipo,\footnote{questo vale fino ai kernel della serie 2.2.x, dalla
936   serie 2.4.x viene usato lo stesso fattore per tutti gli oggetti, esso è dato
937   dalla costante \macro{IPCMNI}, definita in \file{include/linux/ipc.h}, che
938   indica il limite massimo per il numero di oggetti di IPC, ed il cui valore è
939   32768.}  si evita così il riutilizzo degli stessi numeri, e si fa sì che
940 l'identificatore assuma tutti i valori possibili.
941
942 In \figref{fig:ipc_sysv_idtest} è riportato il codice di un semplice programma
943 di test che si limita a creare un oggetto (specificato a riga di comando),
944 stamparne il numero di identificatore e cancellarlo per un numero specificato
945 di volte. 
946
947 \begin{figure}[!htb]
948   \footnotesize \centering
949   \begin{minipage}[c]{15cm}
950     \begin{lstlisting}{}
951 int main(int argc, char *argv[])
952 {
953     ...
954     switch (type) {
955     case 'q':   /* Message Queue */
956         debug("Message Queue Try\n");
957         for (i=0; i<n; i++) {
958             id = msgget(IPC_PRIVATE, IPC_CREAT|0666);
959             printf("Identifier Value %d \n", id);
960             msgctl(id, IPC_RMID, NULL);
961         }
962         break;
963     case 's':   /* Semaphore */
964         debug("Semaphore\n");
965         for (i=0; i<n; i++) {
966             id = semget(IPC_PRIVATE, 1, IPC_CREAT|0666);
967             printf("Identifier Value %d \n", id);
968             semctl(id, 0, IPC_RMID);
969         }
970         break;
971     case 'm':   /* Shared Memory */
972         debug("Shared Memory\n");
973         for (i=0; i<n; i++) {
974             id = shmget(IPC_PRIVATE, 1000, IPC_CREAT|0666);
975             printf("Identifier Value %d \n", id);
976             shmctl(id, IPC_RMID, NULL);
977         }
978         break;
979     default:    /* should not reached */
980         return -1;
981     }
982     return 0;
983 }
984     \end{lstlisting}
985   \end{minipage} 
986   \normalsize 
987   \caption{Sezione principale del programma di test per l'assegnazione degli
988     identificatori degli oggetti di IPC \file{IPCTestId.c}.}
989   \label{fig:ipc_sysv_idtest}
990 \end{figure}
991
992 La figura non riporta il codice di selezione delle opzioni, che permette di
993 inizializzare i valori delle variabili \var{type} al tipo di oggetto voluto, e
994 \var{n} al numero di volte che si vuole effettuare il ciclo di creazione,
995 stampa, cancellazione. I valori di default sono per l'uso delle code di
996 messaggi e un ciclo di 10 volte. Se si lancia il comando si otterrà qualcosa
997 del tipo:
998 \begin{verbatim}
999 piccardi@gont sources]$ ./ipctestid
1000 Identifier Value 0 
1001 Identifier Value 32768 
1002 Identifier Value 65536 
1003 Identifier Value 98304 
1004 Identifier Value 131072 
1005 Identifier Value 163840 
1006 Identifier Value 196608 
1007 Identifier Value 229376 
1008 Identifier Value 262144 
1009 Identifier Value 294912 
1010 \end{verbatim}%$
1011 il che ci mostra che abbiamo un kernel della serie 2.4.x nel quale non avevamo
1012 ancora usato nessuna coda di messaggi. Se ripetiamo il comando otterremo
1013 ancora:
1014 \begin{verbatim}
1015 [piccardi@gont sources]$ ./ipctestid
1016 Identifier Value 327680 
1017 Identifier Value 360448 
1018 Identifier Value 393216 
1019 Identifier Value 425984 
1020 Identifier Value 458752 
1021 Identifier Value 491520 
1022 Identifier Value 524288 
1023 Identifier Value 557056 
1024 Identifier Value 589824 
1025 Identifier Value 622592 
1026 \end{verbatim}%$
1027 che ci mostra come il valore di \var{seq} sia in effetti una quantità
1028 mantenuta staticamente all'interno del sistema.
1029
1030
1031 \subsection{Code di messaggi}
1032 \label{sec:ipc_sysv_mq}
1033
1034 Il primo oggetto introdotto dal \textit{System V IPC} è quello delle code di
1035 messaggi.  Le code di messaggi sono oggetti analoghi alle pipe o alle fifo,
1036 anche se la loro struttura è diversa. La funzione che permette di ottenerne
1037 una è \func{msgget} ed il suo prototipo è:
1038 \begin{functions}
1039   \headdecl{sys/types.h} 
1040   \headdecl{sys/ipc.h} 
1041   \headdecl{sys/msg.h} 
1042   
1043   \funcdecl{int msgget(key\_t key, int flag)}
1044   
1045   Restituisce l'identificatore di una cosa di messaggi.
1046   
1047   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
1048     in caso di errore, nel qual caso \var{errno} viene settato ad uno dei
1049     valori: 
1050   \begin{errlist}
1051   \item[\macro{EACCES}] Il processo chiamante non ha i provilegi per accedere
1052   alla coda richiesta.  
1053   \item[\macro{EEXIST}] Si è richiesta la creazione di una coda che già
1054   esiste, ma erano specificati sia \macro{IPC\_CREAT} che \macro{IPC\_EXCL}. 
1055   \item[\macro{EIDRM}] La coda richiesta è marcata per essere cancellata.
1056   \item[\macro{ENOENT}] Si è cercato di ottenere l'identificatore di una coda
1057     di messaggi specificando una chiave che non esiste e \macro{IPC\_CREAT}
1058     non era specificato.
1059   \item[\macro{ENOSPC}] Si è cercato di creare una coda di messaggi quando è
1060     stato il limite massimo del sistema.
1061   \end{errlist}
1062   ed inoltre \macro{ENOMEM}.
1063 }
1064 \end{functions}
1065
1066 Le funzione (come le analoghe che si usano per gli altri oggetti) serve sia a
1067 ottenere l'identificatore di una coda di messaggi esistente, che a crearne una
1068 nuova. L'argomento \param{key} specifica la chiave che è associata
1069 all'oggetto, eccetto il caso in cui si specifichi il valore
1070 \macro{IPC\_PRIVATE}, nel qual caso la coda è creata ex-novo e non vi è
1071 associata alcuna chiave, il processo (ed i suoi eventuali figli) potranno
1072 farvi riferimento solo attraverso l'identificatore.
1073
1074 Se invece si specifica un valore diverso da \macro{IPC\_PRIVATE}\footnote{in
1075   Linux questo significa un valore diverso da zero.} l'effetto della funzione
1076 dipende dal valore di \param{flag}, se questo è nullo la funzione si limita ad
1077 effettuare una ricerca sugli oggetti esistenti, restituendo l'identificatore
1078 se trova una corrispondenza, o fallendo con un errore di \macro{ENOENT} se non
1079 esiste o di \macro{EACCESS} se si sono specificati dei permessi non validi.
1080
1081 Se invece si vuole creare una nuova coda di messaggi \param{flag} non può
1082 essere nullo e deve essere fornito come maschera binaria, impostando il bit
1083 corrispondente al valore \macro{IPC\_CREAT}. In questo caso i nove bit meno
1084 significativi di \param{flag} saranno usati come permessi per il nuovo
1085 oggetto, secondo quanto illustrato in \secref{sec:ipc_sysv_access_control}.
1086 Se si imposta anche il bit corrispondente a \macro{IPC\_EXCL} la funzione avrà
1087 successo solo se l'oggetto non esiste già, fallendo con un errore di
1088 \macro{EEXIST} altrimenti.
1089
1090
1091
1092 Una coda di messaggi è costituita da una \textit{linked list} in cui nuovi
1093 messaggi vengono inseriti in coda e letti dalla cima, con una struttura del
1094 tipo di quella illustrata in
1095
1096
1097
1098 \subsection{Semafori}
1099 \label{sec:ipc_sysv_sem}
1100
1101 Il secondo oggetto introdotto dal \textit{System V IPC} è quello dei semafori.
1102 Un semaforo è uno speciale contatore che permette di controllare l'accesso a
1103 risorse condivise. La funzione che permette di ottenere un insieme di semafori
1104 è \func{semget} ed il suo prototipo è:
1105 \begin{functions}
1106   \headdecl{sys/types.h} 
1107   \headdecl{sys/ipc.h} 
1108   \headdecl{sys/sem.h} 
1109   
1110   \funcdecl{int semget(key\_t key, int nsems, int flag)}
1111   
1112   Restituisce l'identificatore di un semaforo.
1113   
1114   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
1115     in caso di errore, nel qual caso \var{errno} viene settato agli stessi
1116     valori visti per \func{msgget}.}
1117 \end{functions}
1118
1119 La funzione è del tutto analoga a \func{msgget} ed identico è l'uso degli
1120 argomenti \param{key} e \param{flag}, per cui non ripeteremo quanto detto al
1121 proposito in \secref{sec:ipc_sysv_mq}. L'argomento \param{nsems} permette di
1122 specificare quanti semfori deve contenere l'insieme qualora se ne richieda la
1123 creazione, e deve essere nullo quando si effettua una richiesta
1124 dell'identificatore di un insieme già esistente.
1125
1126
1127
1128 \subsection{Memoria condivisa}
1129 \label{sec:ipc_sysv_shm}
1130
1131 Il terzo oggetto introdotto dal \textit{System V IPC} è quello della memoria
1132 condivisa. La funzione che permette di ottenerne uno è \func{shmget} ed il suo
1133 prototipo è:
1134 \begin{functions}
1135   \headdecl{sys/types.h} 
1136   \headdecl{sys/ipc.h} 
1137   \headdecl{sys/shm.h}
1138   
1139   \funcdecl{int shmget(key\_t key, int size, int flag)}
1140   
1141   Restituisce l'identificatore di una memoria condivisa.
1142   
1143   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
1144     in caso di errore, nel qual caso \var{errno} viene settato agli stessi
1145     valori visti per \func{msgget}.}
1146 \end{functions}
1147
1148 La funzione, come \func{semget}, è del tutto analoga a \func{msgget}, ed
1149 identico è l'uso degli argomenti \param{key} e \param{flag}. L'argomento
1150
1151
1152
1153 \section{La comunicazione fra processi di POSIX}
1154 \label{sec:ipc_posix}
1155
1156 Lo standard POSIX.1b ha introdotto dei nuovi meccanismi di comunicazione,
1157 rifacendosi a quelli di System V, introducendo una nuova interfaccia che
1158 evitasse i principali problemi evidenziati in coda a
1159 \secref{sec:ipc_sysv_generic}.  
1160
1161
1162
1163 \subsection{Considerazioni generali}
1164 \label{sec:ipc_posix_generic}
1165
1166
1167
1168 \subsection{Code di messaggi}
1169 \label{sec:ipc_posix_mq}
1170
1171
1172 \subsection{Semafori}
1173 \label{sec:ipc_posix_sem}
1174
1175
1176 \subsection{Memoria condivisa}
1177 \label{sec:ipc_sysv_shm}
1178
1179 %%% Local Variables: 
1180 %%% mode: latex
1181 %%% TeX-master: "gapil"
1182 %%% End: