Does the managed UI main thread support the same (unmanaged) operating system thread?

Question

I am creating a WPF managed interface for an outdated Win32 application. The WPF interface is executable; as part of its startup routines, I run the legacy application as a DLL in the second thread. Any UI operation (including CreateWindowsEx , etc.) by the outdated application is returned to the main user interface thread.

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

After this background knowledge, to my question:
In the EnumWindows enumeration procedure, 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 creator. I can compare the process id with Process.GetCurrentProcess().Id to check if my application is created.

For added security, I also want to see if my main user interface has created a window. However, the returned thread identifier is OS ThreadId (which is different from the managed thread identifier). As explained in this question , the CLR reserves the right to redistribute the managed thread to different OS threads. Can I rely on the CLR to be “smart enough” to never do this for the main user interface thread (due to the proximity of the thread to the user interface)? Then I could call GetCurrentThreadId to get the main thread identifier of the UI thread for comparison.

Answer 1

The ability to map a managed thread to a custom threading scheme was introduced in .NET 2.0 for user CLR hosts. In particular, SQL Server. They wanted to use fiber, a SQL Server proprietary feature. They could not do this, the project was postponed. There are no CLR hosts that I know about right now that really use this feature.

This will never be a problem in the default CLR host that you get in a WPF application. A managed thread is always mapped to a single OS thread and does it sequentially. You can rely on the value returned by GetCurrentThreadId (). I seriously doubt that this will ever change, it will be a major change. This hardly applies to some future host like Silverlight, but your code will never come close to that.