+Usando la stessa chiave due processi diversi possono ricavare l'identificatore
+associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è
+come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi
+sono \textsl{parenti} la soluzione è relativamente semplice, in tal caso
+infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un
+nuovo oggetto nel processo padre, l'idenficatore così ottenuto sarà
+disponibile in tutti i figli, e potrà essere passato come parametro attraverso
+una \func{exec}.
+
+Però quando i processi non sono \textsl{parenti} (come capita tutte le volte
+che si ha a che fare con un sistema client-server) tutto questo non è
+possibile; si potebbe comunque salvare l'identificatore su un file noto, ma
+questo ovviamente comporta lo svantaggio di doverselo andare a rileggere. Una
+alternativa più efficace è quella che i programmi usino un valore comune per
+la chiave (che ad esempio può essere dichiarato in un header comune), ma c'è
+sempre il rischio che questa chiave possa essere stata già utilizzata da
+qualcun altro. Dato che non esiste una convenzione su come assegnare queste
+chiavi in maniera univoca l'interfaccia mette a disposizione una funzione,
+\func{ftok}, che permette di ottenere una chiave specificando il nome di un
+file ed un numero di versione; il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/ipc.h}
+
+ \funcdecl{key\_t ftok(const char *pathname, int proj\_id)}
+
+ Restituisce una chiave per identificare un oggetto del System V IPC.
+
+ \bodydesc{La funzione restituisce la chiave in caso di successo e -1
+ altrimenti, nel qual caso \var{errno} viene settata ad uno dei possibili
+ codici di errore di \func{stat}.}
+\end{functions}
+
+La funzione determina un valore della chiave sulla base di \param{pathname},
+che deve specificare il pathname di un file effettivamente esistente e di un
+numero di progetto \param{proj\_id)}, che di norma viene specificato come
+carattere, dato che ne vengono utilizzati solo gli 8 bit meno
+significativi.\footnote{nelle libc4 e libc5, come avviene in SunOS,
+ l'argomento \param{proj\_id)} è dichiarato tipo \ctyp{char}, le \acr{glibc}
+ han modificato il prototipo, ma vengono lo stesso utilizzati gli 8 bit meno
+ significativi.}
+
+Il problema è che anche così non c'è la sicurezza che il valore della chiave
+sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
+con i 16 bit meno significativi dell'inode del file \param{pathname} (che
+vengono ottenuti attraverso \func{stat}, da cui derivano i possibili errori),
+e gli 8 bit meno significativi del numero del device su cui è il file. Diventa
+perciò relativamente facile ottenere delle collisioni, specie se i file sono
+su dispositivi con lo stesso \textit{minor number}, come \file{/dev/hda1} e
+\file{/dev/sda1}.
+
+In genere quello che si fa è utilizzare un file comune usato dai programmi che
+devono comunicare (ad esempio un haeder, o uno dei programmi che devono usare
+l'oggetto in questione), utilizzando il numero di progetto per ottere le
+chiavi che interessano. In ogni caso occorre sempre controllare, prima di
+creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
+bene in fase di creazione, le cose possono complicarsi per i programmi che
+devono solo accedere, in quanto, a parte gli eventuali controlli sugli altri
+attributi di \var{ipc\_perm}, non esiste una modalità semplice per essere
+sicuri della validità di una certa chiave.
+
+Questo è, insieme al fatto che gli oggetti sono permanenti e devono essere
+cancellati esplicitamente, il principale problema del sistema di IPC di System
+V. Non esiste infatti una modalità chiara per identificare un oggetto, come
+sarebbe stato se lo si fosse associato ad in file, e tutta l'interfaccia è
+inutilmente complessa. Per questo ne è stata effettuata una revisione
+completa nello standard POSIX.1b, che tratteremo in \secref{sec:ipc_posix}.
projects / gapil.git / commitdiff