chapters/sandbox_architecture: précision sur les processus et corrections

chapters/sandbox_architecture.tex

@@ -32,15 +32,18 @@ transmettre les ressources et faire la vérification d'accès. Il est également
 utile pour vérifier que les processus workers sont encore en vie et signaler les
 erreurs.
 
-% TODO: expliauer IPC
+% TODO: expliquer IPC
 Les avantages du modèle broker sont qu'il est généralement le modèle le plus
 simple à implémenter, et n'a pas besoin de fonctionnalité particulière du point
-de vue du système, à part pour créer les IPC. Il est également bien plus simple
-à comprendre, à développer, à isoler et à suivre étant donné que tous les
-échanges passent par le broker avant d'être transmis au bon processus. Ce
-modèle constitue ainsi un cadre privilégié pour développer la sandbox et
-l'amener sur tous les systèmes, à condition de garder en tête les contraintes
-des autres modèles.
+de vue du système, à part pour créer les communications inter-processus (IPC).
+Nous pouvons même simuler toutes les problématiques d'accès par des jetons
+d'accès représenté par une certaine IPC, que le broker associera à un accès réel
+et reproduira les actions demandées par le worker.  Il est également bien plus
+simple à comprendre, à développer, à isoler et à suivre étant donné que tous les
+échanges passent par le broker avant d'être transmis au bon processus. Ce modèle
+constitue ainsi un cadre privilégié pour développer la sandbox et l'amener sur
+tous les systèmes, à condition de garder en tête les contraintes des autres
+modèles.
 
 Le processus broker sera initialisé dans le processus principal et sera donc
 père de tous les autres processus de la sandbox. Cela permettra d'utiliser des
@@ -59,11 +62,36 @@ donné qu'on diminue les changements de contexte et appels systèmes. On garde c
 fonctionner indépendamment après, du moment que tous les éléments qui
 sont liés à l'étage ont été créés.
 
+Ce modèle nécessite la possibilité d'initialiser une IPC entre deux workers qui
+doivent communiquer, mais potentiellement aussi mettre en place une autre IPC
+plus efficace pour les transferts de données du pipeline, commme des mémoire
+partagées. Il faut également que dans ce modèle, les workers ne puissent pas
+récupérer les droits des autres workers.
+
+C'est grâce à ce modèle qu'on peut mettre en valeur la puissance d'expression et
+de contrôle des jetons d'accès, car aucun contrôle de l'orchestrateur n'est
+nécessaire pour appliquer une réduction des privilèges et définir précisément
+les accès disponibles dans chaque partie du pipeline par conception plutôt que
+par des règles et contrôles d'accès.
+
 %TODO: schéma orchestrateur-worker
 
 \section{Les processus worker}
 
 %TODO: décrire rôle du processus worker
+Dans les deux modèles précédents, on a utilisé des processus workers qui vont
+avoir le même rôle, mais éventuellement des implémentations différentes.
+
+Chaque worker est équipé d'un thread jouant le rôle de boucle événementielle et
+récupérant les messages soit de tous les autres modules connectés, soit depuis
+le broker uniquement selon le modèle utilisé. La boucle événementielle sera
+décrite plus tard.
+
+Les workers peuvent démarrer de plusieurs façons. Soit un nouveau processus est
+créé en étant configuré comme un worker, avec des IPC correctes déjà attribuées.
+Soit le processus est créé depuis un fork et le thread worker peut démarrer tout
+de suite en ayant connaissance de son IPC vers l'orchestrateur ou le broker. La
+seconde option peut notamment apparaître lorsqu'un processus Zygote est utilisé.
 
 \section{La notion de processus Zygote}
 
@@ -88,7 +116,7 @@ systématique de libération de tous les descripteurs associés au processus si
 l'on ne souhaite pas utiliser ce processus pour des raisons de performances
 également.
 
-Néanmoins, la partie la plus intéressante du Zygote concerne le débogage de la
+Néanmoins, l'autre partie très intéressante du Zygote concerne le débogage de la
 sandbox. Sous Linux, \texttt{gdb} n'est capable de s'accrocher qu'à un seul
 processus à la fois. Il faut alors choisir avec \texttt{set follow-fork-mode} si
 l'on veut déboguer le processus parent ou bien le processus enfant lors d'un