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?
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…