|
|
@@ -17,7 +17,16 @@ utilisables.
|
|
|
fonction \inltype{pipe}, soit être nommés via la fonction
|
|
|
\inltype{mknode} ou \inltype{mkfifo}.
|
|
|
|
|
|
- \item Les mémoires partagés fournissent un moyen de communication
|
|
|
+ \item Les files de message POSIX, ou message queues sont assez proches des
|
|
|
+ tubes unix, mais sont forcément nommées et permettent d'ajouter des
|
|
|
+ priorités tout en segmentant les messages. Ici la propriété de
|
|
|
+ segmentation est très intéressante pour pouvoir déboguer et parser les
|
|
|
+ messages envoyés d'une partie de l'application à l'autre. Néanmoins,
|
|
|
+ aucun mécanisme ne permet d'envoyer des ressources sur une file de
|
|
|
+ message. Il faut donc également réaliser une passerelle et un contrôle
|
|
|
+ d'identité pour pouvoir l'utiliser dans notre cas.
|
|
|
+
|
|
|
+ \item Les mémoires partagés POSIX fournissent un moyen de communication
|
|
|
extrêmement performants pour dialoguer. Elles ont besoin d'un mécanisme
|
|
|
de synchronisation mais n'ont absolument pas besoin de passer par des
|
|
|
appels systèmes hormi pour leur création. C'est donc un candidat de
|
|
|
@@ -29,17 +38,29 @@ utilisables.
|
|
|
%TODO: expliquer redirection au dessus en citant la partie général: qqun
|
|
|
% fait les IO et redirige le résultat sur la shared memory
|
|
|
|
|
|
- \item Les files de message, ou message queues
|
|
|
- %TODO
|
|
|
-
|
|
|
- \item Les sockets unix
|
|
|
- %TODO
|
|
|
+ \item Les alternatives Sys V des méthodes citées ci-dessus. Malheureusement,
|
|
|
+ les primitives de Sys V fonctionnent avec leur propre API et ne se
|
|
|
+ rapproche pas de la philosophie unix du tout. Ces API fournissent un
|
|
|
+ objet Sys V au lieu d'un descripteur de fichier et bien qu'étant
|
|
|
+ compatible plus facilement avec d'autres systèmes de part son
|
|
|
+ ancienneté, nous allons voir que les alternatives apportent bien plus
|
|
|
+ d'avantages.
|
|
|
+
|
|
|
+ \item Les sockets unix permettent d'envoyer des messages, soit de façon
|
|
|
+ segmentée avec les mécanismes de «end of record», soit par l'envoi de
|
|
|
+ datagrammes. Les performances en tant qu'IPC sont les mêmes que les deux
|
|
|
+ premières méthodes, mais les sockets Unix disposent d'une
|
|
|
+ caractéristique unique qui correspondent très exactement à notre
|
|
|
+ problème. Ils disposent d'un moyen de transmettre des descripteurs de
|
|
|
+ fichiers d'un processus à l'autre, en y joignant le message qui permet
|
|
|
+ d'interpréter la ressource. Cette interface est néanmoins difficile à
|
|
|
+ manipuler comme on va le voir dans la suite.
|
|
|
\end{itemize}
|
|
|
|
|
|
La solution qui s'applique le plus simplement à notre solution tout en
|
|
|
conservant des performances correctes apparait clairement comme étant les
|
|
|
sockets unix. Ils fournissent unes permettant d'apporter la gestion des accès.
|
|
|
-Ils fournissent également un moyem de transférer des descripteurs de fichiers
|
|
|
+Ils fournissent également un moyen de transférer des descripteurs de fichiers
|
|
|
entre processus.
|
|
|
|
|
|
\section{Partage de ressources entre processus}
|
