Chrome / IE8 multi-process design, is it possible in .NET?

Question

Google Chrome and IE8 (among others) aim to provide greater reliability/stability by isolating each tab (web page) in a separate process (over-simplified, I know).

This would seem to be much more heavyweight then multiple threads, but has the major benefit of a crash in one process not bringing down the whole application.

It seems the multiple process architecture has long been used in server side applications (eg. web servers), but these are processes without a dedicated GUI. It's interesting that it is now being employed in the user interfaces of desktop applications.

How would I go about implementing this in say a Windows Forms .NET application? Is it even possible?

Process.Start() is an obvious first place to look, but the GUI of the new process is not tightly integrated with the GUI of the host application. It's a new standalone application, not a sub control/window of the host application, as it is with Chrome/IE8.

(For anyone interested Scott Hanselmann wrote a good intro. to the IE8 multi-process architecture here.)

[Update]

More specifically:

How can a separate "sub-process" render directly to the UI within the "main process"? Is this actually what is happening, or as was suggested in comments, does the sub-process use IPC to ask the main process to render for it?

Answer 1

Google Chrome is using named pipes for inter-process communication.

There are some interesting documents here: http://dev.chromium.org/developers/design-documents

For more information on named pipes with ".net" just google it.

@Ash: The child processes are running in separate Windows "Desktops" which means that they have no way of displaying anything. (Desktops are a tricky thing...) So I must assume that everything the child processes renders must go through IPC. And then the main(?) process displays it.

I found that separate Windows "Desktop" thing here: http://dev.chromium.org/developers/design-documents/multi-process-architecture

Answer 2

A better option to using multiple processes in .NET would be to use multiple AppDomains instead. This has the advantage of only creating one actual Windows process, yet still giving the added stability of multiple areas (i.e. a crash in one AppDomain would only take that one down, not the whole app).

There are costs associated with this, since objects need to be serialized across AppDomain-boundaries. It might be easier to develop than a multi-process model, though.