[...]
Actually, there's no reason for an unmanaged (native) GUI program to
have more than one thread, assuming _only_ a dependency on the plain
Win32 GUI API. A GUI does not in and of itself imply an additional
thread; typically, the GUI executes in the same thread that the
process's initial entry point used.
Hi Pete,
Thanks for your response.
I had tried compiling it using the simplest code below, but Windows Task
Manager shows it as having two threads.
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lcCmdLine, int nCmdShow)
{
MessageBox(NULL, "Hi!", "Say Hi", MB_OK);
return 0;
}
I'm no expert in Windows programming using Win32 API and I had already
forgot how to coding it in C, but from the code above, clearly the
MessageBox is called from the main thread which means that this program
should have one thread only. But what the Task Manager reports make me
think that there is something that cause the program to spawn another
thread. Is it because MessageBox function call the COM component behind
the scene? (I'm not familiar at all with COM object).
Do you have an example that show a single threaded GUI program?
[I'm sorry in advance as the above is not related to .Net at all - I'm
just curious...]
A GUI application that uses COM components, especially those that are
free-threaded (i.e. use the multi-threaded apartment) may result in a
new thread started up by COM, because typically COM is initialized in
the main GUI thread as an STA thread. But even that will vary according
to the exact program.
You _might_ also see one or more extra threads if running the process
under a debugger. But that's just an artifact of debugging.
The first thing to understand is that a native thread may or may not be
the same as a managed thread. So when counting threads, it's important
to make sure one is specific about which kind of thread one is talking
about.
For example, in the above list, the "primary AppDomain main thread" is a
managed thread, while the "native Win32 thread hosting the CLR" is by
definition unmanaged.
Beyond that, I would not expect the above list to be accurate even on
..NET implementations where a managed thread corresponds exactly to an
unmanaged thread. In particular, the main thread for the managed process
is as far as I know the same as the main thread for the process. There's
certainly no obvious reason for it not to be, and even running under the
debugger (*), a .NET console app has only one non-worker thread.
(*) where at least one additional thread is created as part of the
hosting mechanism…I did a test with a simple WPF application, which when
debugging had 6 threads without the debugger's host process and 13 with;
running standalone, it had only 5 threads
I'm checking the thread count using the Process class by enumerating the
Threads property. So, it is probably a total of unmanaged and managed
threads. Coupled with the info from Task Manager, and since current
implementation of managed thread in .Net maps directly to unmanaged
thread, I assume the figure I get is correct. When I run a simple WPF
application, initially I got 10 threads, but over the time it reduced to
7 threads and then up back to 8 threads and then down again but never
below than 7. So, I think as you said the 3 threads probably comes from
the thread pool. But that leaves the other two mysterious.
The GC can be run concurrently or not, depending on .NET implementation
and configuration.
Ok, I will check on how to configure that and observe whether the thread
count will be effected or not.
[...]
I don't actually know what all the different threads .NET and its
various components may create on the behalf of the process actually do.
The fact is, it's not something I worry about very much. The exact
thread count for a managed process is even more of an "implementation
detail" than for an unmanaged process, and even the unmanaged process
has some specific scenarios where you might get a thread or two in your
process you didn't explicitly create.
Yes, I agree. I'm just exploring it simply for my own curiosity.
Regards.
