Ash*_*Ash 5 .net user-interface google-chrome process internet-explorer-8
谷歌Chrome和IE8(以及其他)旨在通过在单独的过程中隔离每个标签(网页)来提供更高的可靠性/稳定性(过度简化,我知道).
这似乎比多线程更重量级,但在一个进程中崩溃的主要好处是不会导致整个应用程序崩溃.
似乎多进程架构长期以来一直用于服务器端应用程序(例如Web服务器),但这些是没有专用GUI的进程.有趣的是,它现在被用在桌面应用程序的用户界面中.
如何在Windows Forms .NET应用程序中实现这一点？它甚至可能吗？
Process.Start()显然是第一个看的地方,但新进程的GUI没有与主机应用程序的GUI紧密集成.它是一个新的独立应用程序,而不是主机应用程序的子控件/窗口,就像Chrome/IE8一样.
(对于任何感兴趣的人,Scott Hanselmann 在这里为IE8多进程架构写了一篇很好的介绍.)
[更新]
进一步来说:
一个单独的"子流程"如何直接呈现给"主流程"中的UI？这实际上是发生了什么,或者正如评论中所建议的那样,子流程是否使用IPC来请求主流程为其呈现？
谷歌浏览器使用命名管道进行进程间通信.
这里有一些有趣的文件:http: //dev.chromium.org/developers/design-documents
有关使用".net"命名管道的更多信息,请点击谷歌.
@Ash:子进程在单独的Windows"桌面"中运行,这意味着它们无法显示任何内容.(桌面是一件棘手的事情......)所以我必须假设孩子处理渲染的所有内容都必须通过IPC.然后主(？)进程显示它.
我在这里找到了单独的Windows"桌面"东西:http: //dev.chromium.org/developers/design-documents/multi-process-architecture
在 .NET 中使用多个进程的更好选择是使用多个 AppDomain。这样做的优点是只创建一个实际的 Windows 进程，但仍然可以提高多个区域的稳定性（即一个 AppDomain 中的崩溃只会导致该应用程序域崩溃，而不是整个应用程序崩溃）。
由于对象需要跨 AppDomain 边界进行序列化，因此存在与此相关的成本。不过，它可能比多进程模型更容易开发。
| 归档时间： |
|
| 查看次数： |
3312 次 |
| 最近记录： |