Многопроцессное проектирование Chrome / IE8, возможно ли это в .NET?

Question

Google Chrome и IE8 (среди прочих) стремятся обеспечить большую надежность / стабильность, изолируя каждую вкладку (веб-страницу) в отдельном процессе (слишком упрощенно, я знаю).

Это может показаться гораздо более тяжелым, чем многопоточность, но имеет главное преимущество - сбой в одном процессе, не приводящий к сбою всего приложения.

Кажется, архитектура с несколькими процессами уже давно используется в серверных приложениях (например, веб-серверах), но это процессы без выделенного графического интерфейса пользователя. Интересно, что теперь он используется в пользовательских интерфейсах настольных приложений.

Как бы я реализовал это, скажем, в приложении Windows Forms .NET? Это вообще возможно?

Process.Start () - это очевидное первое место для поиска, но графический интерфейс нового процесса тесно не интегрирован с графическим интерфейсом хост-приложения. Это новое отдельное приложение, а не вспомогательный элемент управления / окно хост-приложения, как в Chrome / IE8.

(Для всех, кто заинтересован, Скотт Хансельманн написал хорошее введение в многопроцессную архитектуру IE8 здесь .)

[Update]

Более конкретно:

Как отдельный «подпроцесс» может отображаться непосредственно в пользовательском интерфейсе в «основном процессе»? Это на самом деле то, что происходит, или, как было предложено в комментариях, подпроцесс использует IPC, чтобы запросить основной процесс для этого?

Answer 1

Google Chrome использует именованные каналы для межпроцессного взаимодействия.

Здесь есть несколько интересных документов: http://dev.chromium.org/developers/design-documents

Для получения дополнительной информации по именованным каналам с ".net" просто введите его в Google.

@ Ash: Дочерние процессы выполняются в отдельных Windows «Рабочих столах» , что означает, что они не могут ничего отображать. (Рабочие столы - сложная вещь ...) Поэтому я должен предположить, что все, что рендерит дочерние процессы, должно проходить через IPC. И тогда основной (?) Процесс отображает его.

Я обнаружил, что отдельная Windows "Desktop" вещь здесь: http://dev.chromium.org/developers/design-documents/multi-process-architecture

Answer 2

Лучшим вариантом использования нескольких процессов в .NET будет использование нескольких доменов приложений. Преимущество этого состоит в том, что создается только один фактический процесс Windows, но при этом обеспечивается дополнительная стабильность нескольких областей (т. Е. Сбой в одном домене приложений приведет к срыву только одной, а не всего приложения).

С этим связаны издержки, поскольку объекты необходимо сериализовать через границы AppDomain. Это может быть легче разработать, чем модель с несколькими процессами.

Answer 3

кстати ... dup

См .: Приложение Windows Forms, такое как Google Chrome, с несколькими процессами (с ответом Джона Скита: o)

(я думаю, что это также отвечает на "более конкретно")