与受管主UI线程保持不变（非托管）操作系统线程？ [英] Does the managed main UI thread stay on the same (unmanaged) Operation System thread?

问题描述

我创建一个托管WPF UI前端到传统的Win32应用程序。在WPF前端是可执行文件;作为其启动程序的一部分，我开始继承应用程序在第二个线程的DLL。所有UI操作（包括 CreateWindowsEx 等）通过继承应用程序调用回主UI线程上。

I am creating a managed WPF UI front-end to a legacy Win32-application. The WPF front-end is the executable; as part of its startup routines I start the legacy app as a DLL in a second thread. Any UI-operation (including CreateWindowsEx, etc.) by the legacy app is invoked back on the main UI-thread.

随着应用程序的关闭过程的一部分，我想收拾妥当。别的不说，我要打电话的DestroyWindow 上的所有非托管的窗口，使他们能够正确地清理自己了。因此，在关闭过程中我使用 EnumWindows的来试图找到我的所有的非托管窗口。然后，我调用DestroyWindow一个列表我产生。这些主UI线程上运行。

As part of the shutdown process of the app I want to clean up properly. Among other things, I want to call DestroyWindow on all unmanaged windows, so they can properly clean themselves up. Thus, during shutdown I use EnumWindows to try to find all my unmanaged windows. Then I call DestroyWindow one the list I generate. These run on the main UI-thread.

在此背景知识，对我的实际问题：
在EnumWindows的枚举过程，我要检查，如果返回的顶层窗口之一，是我的非托管的窗口之一。我这样做是通过调用 GetWindowThreadProcessId 来获取窗口的创建者的进程ID和线程ID。我可以比较的进程id与 Process.GetCurrentProcess（）（出处同上）来检查我的应用程序创建它。

After this background knowledge, on to my actual question:
In the enumeration procedure of EnumWindows, I have to check if one of the returned top-level windows is one of my unmanaged windows. I do this by calling GetWindowThreadProcessId to get the process id and thread id of the window's creator. I can compare the process id with Process.GetCurrentProcess().Id to check if my app created it.

有关额外的安全性，我也想看看我的主UI线程创建的窗口。但是，返回的线程ID是操作系统的的ThreadId（比托管线程ID不同）。作为<一个解释href="http://stackoverflow.com/questions/1279950/relationship-between-managedthreadid-and-operating-system-threadid">this问题，CLR将保留重新安排托管线程不同的操作系统线程的权利。我可以依靠CLR是足够聪明从来没有做到这一点的主UI线程（由于UI线程关联性）？然后，我可以叫 GetCurrentThreadId 让主UI线程的非托管线程ID进行比较。

For additional security, I also want to see if my main UI-thread created the window. However, the returned thread id is the OS's ThreadId (which is different than the managed thread id). As explained in this question, the CLR reserves the right to re-schedule the managed thread to different OS threads. Can I rely on the CLR to be "smart enough" to never do this for the main UI thread (due to thread-affinity of the UI)? Then I could call GetCurrentThreadId to get the main UI-thread's unmanaged thread id for comparison.

推荐答案

到托管线程映射到一个自定义的线程方案的能力引入定制CLR主机的.NET 2.0。具体而言，SQL Server中。他们想用纤维，SQL Server的本机功能。他们不能做它一展身手，该项目被搁置。有迹象表明，我所知道的，现在是采取实际的功能优势，没有CLR主机。

The ability to map a managed thread to a custom threading scheme was introduced in .NET 2.0 for custom CLR hosts. Specifically, SQL Server. They wanted to use fibers, a native feature of SQL Server. They couldn't make a go of it, the project was shelved. There are no CLR hosts that I'm aware of right now that actually take advantage of the feature.

这绝不会是一个问题，在默认的CLR主机，你在一个WPF应用程序获得的。托管线程始终映射到一个操作系统线程这样做一致。你可以依靠（）所GetCurrentThreadId返回的值。我严重怀疑这将不会改变，这将是一个重大的重大更改。这不可能是真实的某种未来的东道国，类似的Silverlight，但你的code将永远不会接近。

It will never be an issue in the default CLR host, the one you get in a WPF app. A managed thread always maps to one OS thread and does so consistently. You can rely on the value returned by GetCurrentThreadId(). I seriously doubt that will ever change, it would be a major breaking change. This isn't likely to be true to some kind of future host, similar to Silverlight, but your code will never get close to that.

这篇关于与受管主UI线程保持不变（非托管）操作系统线程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！