#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 интегрирует все это, делает его еще интереснее. Если всегда существует один процесс, который координирует работу других, и если ему также принадлежит поток пользовательского интерфейса и т.д. И т.п. Отсюда вопрос.