Conception multi-processus Chrome / IE8, est-ce possible dans .NET?

Question

Google Chrome et IE8 (entre autres) visent à améliorer la fiabilité et la stabilité en isolant chaque onglet (page Web) dans un processus distinct (simplifié à l'excès, je sais).

Cela semble être beaucoup plus lourd que de multiples threads, mais présente le principal avantage d'un crash dans un processus ne faisant pas tomber toute l'application.

Il semble que l'architecture à processus multiples soit utilisée depuis longtemps dans les applications côté serveur (par exemple, les serveurs Web), mais il s'agit de processus sans interface graphique dédiée. Il est intéressant de noter qu'il est maintenant utilisé dans les interfaces utilisateur d'applications de bureau.

Comment procéder pour implémenter cela dans une application Windows Forms .NET? Est-ce même possible?

Process.Start () est un premier endroit évident à regarder, mais l'interface graphique du nouveau processus n'est pas étroitement intégrée à l'interface graphique de l'application hôte. C’est une nouvelle application autonome, et non un sous-contrôle / une fenêtre de l’application hôte, comme c’est le cas avec Chrome / IE8.

(Pour les personnes intéressées, Scott Hanselmann a rédigé une bonne introduction au Architecture multi-processus IE8 ici. .)

[Mise à jour]

Plus spécifiquement:

Comment un "sous-processus" distinct peut-il rendre directement à l'interface utilisateur dans le "processus principal"? Est-ce réellement ce qui se passe ou, comme suggéré dans les commentaires, le sous-processus utilise-t-il IPC pour demander au processus principal de le rendre?

Answer 1

Une meilleure option pour utiliser plusieurs processus dans .NET serait d'utiliser plusieurs AppDomains à la place. Cela présente l’avantage de ne créer qu’un seul processus Windows, tout en offrant la stabilité supplémentaire de plusieurs zones (c’est-à-dire qu’un plantage dans un AppDomain ne ferait que supprimer celui-ci, pas l’application entière).

Des coûts sont associés à cette opération, car les objets doivent être sérialisés à travers les limites AppDomain. Il pourrait être plus facile à développer qu'un modèle multi-processus, cependant.

Answer 2

Google Chrome utilise des canaux nommés pour la communication interprocessus.

Il y a quelques documents intéressants ici: http://dev.chromium.org/developers/design-documents

Pour plus d'informations sur les canaux nommés avec ".net" il suffit de google.

@Ash: Les processus enfants s'exécutent dans Windows séparé "Desktops" , ce qui signifie qu'ils n'ont aucun moyen d'afficher quoi que ce soit. (Les ordinateurs de bureau sont une chose délicate ...) Je dois donc supposer que tout ce que les processus enfants rendent doit passer par IPC. Et ensuite, le processus principal (?) L'affiche.

J'ai constaté que cette option Windows distincte du Bureau: http://dev.chromium.org/developers/design-documents/ Architecture multi-processus

Answer 3

btw ... dup

Voir: application Windows Forms telle que Google Chrome avec plusieurs processus (avec la réponse de Jon Skeet: o)

(Je pense que cela répond également à la partie "plus spécifiquement")