SOLVED

What is the standard COM and SendMessage pumping in Doc?

Copper Contributor

I am learning the Thread class to control the Thread manually in my application.

The doc is here .

There is an most important method while using it.

 

 

Thread.Join()

 

 

 In the Join method, this is a fragment of description.

 

while continuing to perform standard COM and SendMessage pumping.

 

I have searched a lot, but I can't find any exact explanation of these two item.

2 Replies
best response confirmed by NullReference (Copper Contributor)
Solution
This is all about the low-level internals of the Windows system (Win32 API).

The OS deals with applications using a message queue, where applications cycle between asking the OS for new messages and dealing with them.
For example, mouse movement/clicks, key events, window changes, external events.

If your application stops consuming messages from the queue, the OS will assume that the application has hung and will eventually suggest to the user to kill it.

The doc is saying that, although you are holding up the current thread when you call "Join", the framework will continue to deal with COM and OS messages, so that your application doesn't appear to hang. So, it's not something that you have to worry about too much - but that doesn't mean you can completely ignore where you're calling Join.

As an aside, Thread is still important in some places, but it's definitely more of a lower level concept nowadays. In production code, I would more expect to see people using the Async pattern for typical concurrent code usage.

Clear explanation!
I will use task-base pattern for my code with threadpool.
Thanks a lot.

1 best response

Accepted Solutions
best response confirmed by NullReference (Copper Contributor)
Solution
This is all about the low-level internals of the Windows system (Win32 API).

The OS deals with applications using a message queue, where applications cycle between asking the OS for new messages and dealing with them.
For example, mouse movement/clicks, key events, window changes, external events.

If your application stops consuming messages from the queue, the OS will assume that the application has hung and will eventually suggest to the user to kill it.

The doc is saying that, although you are holding up the current thread when you call "Join", the framework will continue to deal with COM and OS messages, so that your application doesn't appear to hang. So, it's not something that you have to worry about too much - but that doesn't mean you can completely ignore where you're calling Join.

As an aside, Thread is still important in some places, but it's definitely more of a lower level concept nowadays. In production code, I would more expect to see people using the Async pattern for typical concurrent code usage.

View solution in original post