в Google Chrome работает несколько процессов, как насчет потоков пользовательского интерфейса?

#multithreading #user-interface

#многопоточность #пользовательский интерфейс

Вопрос:

Я всегда читал и отрабатывал один поток пользовательского интерфейса, поскольку наличие более одного приведет к сбою в отправке сообщений и т.д. И т.п.

Я отвечаю на свой собственный вопрос здесь, но хочу подтвердить свое понимание браузера Chrome, который, как известно, имеет несколько процессов (по одному на вкладку) — ускоряет ли это часть рендеринга за счет использования нескольких потоков пользовательского интерфейса?

Я предполагаю, что это НЕ так, но если это так, было бы очень интересно узнать или посмотреть на какой-нибудь пример кода c #, чтобы продемонстрировать то же самое (не обязательно демонстрационный веб-браузер).

Любые указатели в направлении нескольких потоков пользовательского интерфейса помогли бы! Спасибо.

Ответ №1:

Я не могу точно сказать, как Chrome обрабатывает потоки рендеринга, но я бы предположил, что у каждой вкладки есть свой собственный поток рендеринга. Я бы не видел смысла прилагать все усилия для изоляции процесса от вкладок, только для того, чтобы связать их все вместе в общем потоке рендеринга. У всех них была бы возможность вмешиваться друг в друга.

Я внедрил браузер в стиле Chrome, используя WPF — оболочка приложения представляла собой единый процесс, затем каждая «вкладка» была надстройкой MAF, запущенной в отдельном процессе. Весь рендеринг выполнялся в дочерних процессах — не было ничего общего. Каждое добавление возвращало INativeHandleContract (элемент управления WPF), который был передан через границу процесса.

Результатом этого было то, что исключение В ЛЮБОМ месте дочерней вкладки приводило только к закрытию вкладки и могло быть обнаружено родительским процессом, что давало ему возможность предоставить некоторую обратную связь / перезагрузить вкладку и т.д.

Этого документа не было, когда я его создавал, но после быстрого просмотра я думаю, что в нем есть несколько указаний:http://msdn.microsoft.com/en-us/library/bb909794.aspx

Кент Бугарт также оказал помощьhttp://kentb.blogspot.com/2008/06/maf-gymnastics-service-provider.html

Вам также может понадобиться этот QFE от Microsoft, чтобы исправить ошибку в сериализации, с которой вы можете столкнуться при передаче элемента управления WPF через границу процесса: http://archive.msdn.microsoft.com/KB982638 Что касается ошибки MS Connect: https://connect.microsoft.com/VisualStudio/feedback/details/467381/wpf-controls-cannot-be-passed-across-process-boundaries

Комментарии:

1. Потоки не обеспечивают никакой изоляции. Вы не можете перехватить исключение из одного потока и возобновить процесс.

2. Это правильно — вот почему в моем коде «каждая ‘вкладка’ была надстройкой MAF, запущенной в отдельном процессе», что обеспечивает устойчивость chrome к необработанным исключениям.

Ответ №2:

Не путайте потоки и процессы. У каждого процесса будет свой собственный поток пользовательского интерфейса, но, вероятно, также и собственный поток сообщений.

Комментарии:

1. да, я согласен концептуально. То, как Google Chrome интегрирует все это, делает его еще интереснее. Если всегда существует один процесс, который координирует работу других, и если ему также принадлежит поток пользовательского интерфейса и т.д. И т.п. Отсюда вопрос.