chapters/windows: corrections

chapters/windows_eventloop.tex

@@ -22,7 +22,7 @@ int WSAAPI select(
 );
 \end{code}
 
-Malheureusement celle-ci ne peut être utilisé que sur des sockets venant de
+Malheureusement celle-ci ne peut être utilisée que sur des sockets venant de
 l'API winsock. Il nous sera donc impossible de l'utiliser pour construire la
 boucle événementielle sans changer d'IPC.
 
@@ -37,7 +37,7 @@ int WSAAPI WSAPoll(
 );
 \end{code}
 
-Par conséquent, ces deux choix sont définitivement éliminé pour la construction
+Par conséquent, ces deux choix sont définitivement éliminés pour la construction
 avec les canaux nommés.
 
 \subsection{WaitForMultipleObject}
@@ -56,7 +56,7 @@ DWORD WaitForSingleObject(
 );
 \end{code}
 
-Cependant, cela correspond peu à notre cas d'usage et sera plutôt utiliser pour
+Cependant, cela correspond peu à notre cas d'usage et sera plutôt utilisé pour
 les manipulations de processus. On peut donc s'intéresser à la variante nous
 concernant, qui sans surprise s'appelle \inltype{WaitForMultipleObjects}.
 
@@ -79,9 +79,9 @@ qui en pratique se limite à 64 objets. Loin d'être bloquant pour notre projet,
 on va plutôt s'intéresser aux performances. \inltype{WaitForMultipleObjects}
 fonctionne exactement comme \inltype{select} et fournit donc une complexité
 linéaire en le nombre de \inltype{HANDLE} surveillés. Néanmoins, la valeur de
-retour n'est capable d'indiquer seulement qu'un \inltype{HANDLE} notifié et il
+retour est capable d'indiquer uniquement un seul \inltype{HANDLE} notifié et il
 faut donc parcourir à nouveau le tableau pour trouver les autres
-\inltype{HANDLE}.
+\inltype{HANDLE} notififés avec la même méthode.
 
 \subsection{Overlapped IO}
 
@@ -229,10 +229,10 @@ BOOL WINAPI PostQueuedCompletionStatus(
 
 \section{Implémentation et conclusions pour la boucle événementielle}
 
-Ayant déjà décrit \inltype{vlc_msg_poller_t} pour la partie Linux et
-extensivement expliqué le fonctionnement de l'API d'IOCP, il reste
-principalement à décrire l'implémentation du modèle par complétion dans la
-situation d'attente de message.
+Ayant déjà décrit \inltype{vlc_msg_poller_t} pour la partie Linux et expliqué en
+détails le fonctionnement de l'API d'IOCP, il reste principalement à décrire
+l'implémentation du modèle par complétion dans la situation d'attente de
+message.
 
 Contrairement à Linux, les IOCP ne vont pas signaler quand un des
 \inltype{HANDLE} sera prêt à être lu mais plutôt quand les données auront
@@ -247,4 +247,4 @@ l'opération de lecture.
 En résumé, la gestion des entrées sorties et des erreurs proposées par Windows
 ne respecte absolument pas le principe de moindre surprise, mais les différentes
 alternatives proposées par le système permettent de construire le modèle par
-complétion que nous avons besoin de façon performante.
+complétion dont nous avons besoin de façon performante.

chapters/windows_ipc.tex

@@ -1,15 +1,18 @@
 % TODO: remplacer confiant
-Après les présentations des objectifs liés aux communications inter-processus et
-de l'implémentation Linux, nous pouvons être assez confiant sur l'implémentation
-Windows. Malheureusement celle-ci vient nous rappeler qu'un changement de
-système implique parfois un changement de paradigme. La documentation quelque
-peu hasardeuse va néanmoins nous permettre de mettre en place une architecture
-similaire.
+Après la présentation des objectifs liés aux communications inter-processus et à
+l'implémentation Linux, nous pouvons essayer de reprendre le même modèle pour
+l'implémentation Windows. Malheureusement celle-ci vient nous rappeler qu'un
+changement de système implique parfois un changement de paradigme. La
+documentation quelque peu hasardeuse va néanmoins nous permettre de mettre en
+place une architecture similaire.
 
 \section{Communication inter-processus}
 
-Windows dispose de beaucoup de moyen de communication inter-processus. Parmi
-ceux là, aucun ne va avoir les mêmes propriétés que les sockets Unix. 
+Windows dispose de beaucoup de moyens de communication inter-processus. Parmi
+ceux là, aucun ne va avoir les mêmes propriétés que les sockets Unix. Nous
+allons même de base éliminer tous les moyens «haut niveau» comme les ports COM
+résolvant plutôt des problèmes d'interopérabilité et se concentrer sur les
+moyens plus bas niveau.
 
 \subsection{Les sockets Windows}
 
@@ -18,14 +21,17 @@ mais ne fournissent pas de sockets locaux ou anonymes.  Ceux-ci passent par la
 pile réseau pour l'envoi de message. On notera cependant l'implémentation de
 «TCP Loopback Fast Path» depuis Windows Server 2012. Cette fonctionnalité
 conserve la sémantique du protocole TCP tout en désactivant des fonctionnalités
-comme l'algorithme de Nagle. C'est donc ce qui ressemble le plus aux sockets
-Unix, excepté l'accès au réseau et le passage de descripteur de fichiers.
-https://blogs.technet.microsoft.com/wincat/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path/
+comme l'algorithme de Nagle.
+\footnote{https://blogs.technet.microsoft.com/wincat/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path/}
+C'est donc ce qui ressemble le plus aux sockets Unix, excepté l'accès au réseau
+et le passage de descripteur de fichiers.
+
+
 
 \subsection{Les canaux anonymes}
 
 Les canaux anonymes donnent un moyen de communication unidirectionnel avec un
-écrivain et un lecteur. Il faut donc utiliser une paire de canaux anonyme pour
+écrivain et un lecteur. Il faut donc utiliser une paire de canaux anonymes pour
 pouvoir discuter en full-duplex, mais également utiliser un mécanisme pour
 transmettre le \inltype{HANDLE} d'un processus à l'autre. À noter que la plupart
 des fonctions sur les canaux nommés fonctionnent avec les canaux anonymes, ces
@@ -56,13 +62,13 @@ HANDLE CreateNamedPipeA(
 );
 \end{code}
 
-\section{Transfert de ressource entre processus}
+\section{Transfert de ressources entre processus}
 
-Windows disposent de trois mécanismes pour partager des ressources entre
+Windows dispose de trois mécanismes pour partager des ressources entre
 processus. Les ressources sont représentées par des objets \inltype{HANDLE}.
 
 La première méthode est l'héritage, qui a lieu lors de la création d'un nouveau
-processus. Les descripteurs de fichiers marqués comme héritable, ou bien aucun
+processus. Les descripteurs de fichiers marqués comme héritables, ou bien aucun
 si \inltype{bInheritHandles} est précisé à \inltype{FALSE} lors de l'appel de
 \inltype{CreateProcess}, seront récupérés dans le nouveau processus avec la même
 valeur. Lorsqu'un \inltype{HANDLE} est hérité, il garde la même valeur dans le
@@ -95,7 +101,7 @@ droit \inltype{PROCESS_DUP_HANDLE}. Étant donné que la fonction peut être
 utilisée de la source vers la destination ou depuis la destination récupérant un
 \inltype{HANDLE} appartenant à la source, le processus ayant accès à l'autre
 processus est capable de copier tout accès existant et dispose donc des mêmes
-droits que l'autre processus.
+droits que ce dernier.
 
 Cette remarque est importante pour se rendre compte que l'utilisation de cette
 méthode implique nécessairement un broker, qui sera suffisamment privilégié pour
@@ -104,8 +110,8 @@ cette fonction directement dans les workers impliquerait que chacun des workers
 auraient les mêmes droits que ses voisin et, de façon transitive, aurait accès à
 toutes les zones de privilèges connexes dans le graphe d'IPC.
 
-Enfin, la troisième méthode consiste à utiliser les objets nommées qui sont
-créés d'un côté par le processus parent, puis ouvert par les processus enfants
+Enfin, la troisième méthode consiste à utiliser les objets nommés qui sont
+créés d'un côté par le processus parent, puis ouverts par les processus enfants
 en les référençant par leur nom.
 
 Dans le prototype, j'ai utilisé des canaux nommés pour faciliter la mise en place