Forum Discussion
NullReference
Nov 08, 2021Copper Contributor
What is the standard COM and SendMessage pumping in Doc?
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 metho...
- Nov 08, 2021This 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.
IFYates
Nov 08, 2021Copper Contributor
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.
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.
NullReference
Nov 09, 2021Copper Contributor
Clear explanation!
I will use task-base pattern for my code with threadpool.
Thanks a lot.