Поддерживает ли управляемый основной поток пользовательского интерфейса ту же самую (неуправляемую) рабочую системную нить?

Question

Я создаю управляемый интерфейс интерфейса WPF для устаревшего Win32-приложения. Интерфейс WPF является исполняемым; как часть его подпрограмм запуска, я запускаю устаревшее приложение как DLL во втором потоке. Любая UI-операция (включая CreateWindowsEx и т. Д.) Устаревшим приложением возвращается в основной поток пользовательского интерфейса.

Как часть процесса завершения работы приложения, я хочу правильно очистить его. Среди прочего, я хочу позвонить DestroyWindow во все неуправляемые окна, чтобы они могли правильно очистить себя. Таким образом, во время отключения я использую EnumWindows, чтобы попытаться найти все мои неуправляемые окна. Затем я вызываю DestroyWindow один из списка, который я генерирую. Они запускаются на основном UI-потоке.

После этого фонового знания, на мой актуальный вопрос:
В процедуре перечисления EnumWindows, я должен проверить, если один из возвращенных окон верхнего уровня является один из моих неуправляемых окон. Я делаю это, вызывая GetWindowThreadProcessId, чтобы получить идентификатор процесса и идентификатор потока создателя окна. Я могу сравнить идентификатор процесса с Process.GetCurrentProcess().Id, чтобы проверить, создано ли его приложение.

Для дополнительной безопасности я также хочу посмотреть, создал ли мой основной пользовательский интерфейс окно. Однако возвращаемый идентификатор потока - это ThreadId (который отличается от идентификатора управляемого потока). Как поясняется в this question, CLR оставляет за собой право перераспределить управляемый поток на разные потоки ОС. Могу ли я полагаться на CLR, чтобы быть «достаточно умным», чтобы никогда не делать этого для основного потока пользовательского интерфейса (из-за близости потока к пользовательскому интерфейсу)? Тогда я мог бы позвонить GetCurrentThreadId, чтобы получить основной неуправляемый идентификатор потока UI-потока для сравнения.

Answer 1

Возможность сопоставления управляемого потока с пользовательской схемой потоков была внедрена в .NET 2.0 для пользовательских хостов CLR. В частности, SQL Server. Они хотели использовать волокна, собственную особенность SQL Server. Они не могли этого сделать, проект был отложен. Нет хостов CLR, о которых я знаю прямо сейчас, которые фактически используют эту функцию.

Это никогда не будет проблемой на хосте CLR по умолчанию, который вы получите в приложении WPF. Управляемый поток всегда сопоставляется с одним потоком ОС и делает это последовательно. Вы можете положиться на значение, возвращаемое GetCurrentThreadId(). Я серьезно сомневаюсь, что это когда-нибудь изменится, это будет серьезное изменение. Это вряд ли относится к какому-то будущему хосту, подобному Silverlight, но ваш код никогда не приблизится к этому.