How to determine if win32 thread is in standby or connection or sleep mode in C ++

Question

What I'm actually looking for is equivalent to the C ++ / win32 equivalent for .net ThreadState Enumeration .

Any suggestions?

Answer 1

There are very few differences between them, everyone is waiting for different kernel objects.

In the "Wait" section, I assume that you mean "Waiting for I / O." "Join" is just "wait for a thread / process." And "Sleep" - "wait for the timer."

To complicate matters, a thread may expect some combination of kernel objects.

You can find out what objects the thread expects and the type of these objects using the kernel debugger. I do not think there is an easier way.

Answer 2

Direct equivalent - managed and uncontrolled flows should not be considered the same. See here .

The ThreadId operating system does not have a fixed relationship with a managed thread, because an unmanaged host can control the relationship between managed and unmanaged threads. In particular, a complex host can use the Fiber API to schedule many managed threads against the same operating system thread, or move a managed thread between different operating system threads.

Answer 3

The only state of the native thread that is easily accessible with winapi is to know if the thread has completed its execution. Just use the WaitForSingleObject() function with a stream descriptor and a timeout of 0:

 DWORD res = WaitForSingleObject(handleThread, 0); switch (res) { case WAIT_OBJECT_0: printf("The thread has finished\n"); break; case WAIT_TIMEOUT: printf("The thread is still running\n"); break; default: printf("Unknown error (shouldn't happen)\n"); break; } 

Answer 4

The "problem" is that the .NET runtime has ownership of your .NET thread. Therefore, when you call Abort, for example, the internal runtime throws a ThreadAbortException in the .NET context of your .NET thread and that you can catch it in your thread with catch (ThreadAbortException).

The same is true with ThreadState, since it has the basic ownership of your thread, it knows exactly what it is doing, and therefore can create a valid thread state.

Since there is no way for non-hackins to officially request a thread for its internal state, you can wrap this in a class. But then again, you would be completely dependent on the thread method to stick to any .Abort () requests.