CWinThread for background processing
-
I have a dilemma over whether I should create a User Interface thread or a Background thread to process my background operations. The docs for the function
SHGetFileInfosay that it should not be called from the application's main thread because it can lock up the UI. So I will use a secondary thread. And I will post messages to the thread to prompt it to process stuff. But should I use the UI thread version ofAfxBeginThreadbecause it includes a message pump, or should I use the background thread version and implement my own message pump? I ask because I do not want the application to terminate when the secondary thread terminates. My understanding of the docs is that that could happen if I use a UI thread. Thank youThe difficult we do right away... ...the impossible takes slightly longer.
-
I have a dilemma over whether I should create a User Interface thread or a Background thread to process my background operations. The docs for the function
SHGetFileInfosay that it should not be called from the application's main thread because it can lock up the UI. So I will use a secondary thread. And I will post messages to the thread to prompt it to process stuff. But should I use the UI thread version ofAfxBeginThreadbecause it includes a message pump, or should I use the background thread version and implement my own message pump? I ask because I do not want the application to terminate when the secondary thread terminates. My understanding of the docs is that that could happen if I use a UI thread. Thank youThe difficult we do right away... ...the impossible takes slightly longer.
I don't have personal experience with this function but Microsoft doc seems pretty specific:
Quote:
You should call this function from a background thread. Failure to do so could cause the UI to stop responding.
So background thread it is! :)
Mircea
-
I have a dilemma over whether I should create a User Interface thread or a Background thread to process my background operations. The docs for the function
SHGetFileInfosay that it should not be called from the application's main thread because it can lock up the UI. So I will use a secondary thread. And I will post messages to the thread to prompt it to process stuff. But should I use the UI thread version ofAfxBeginThreadbecause it includes a message pump, or should I use the background thread version and implement my own message pump? I ask because I do not want the application to terminate when the secondary thread terminates. My understanding of the docs is that that could happen if I use a UI thread. Thank youThe difficult we do right away... ...the impossible takes slightly longer.
Hi,
Richard Andrew x64 wrote:
I ask because I do not want the application to terminate when the secondary thread terminates. My understanding of the docs is that that could happen if I use a UI thread.
Could you show me what you are referring to? The only way that I am aware of... where a CWinThread can terminate the main thread is if you reach across threads to execute code. If a WM_QUIT arrives during that short period I believe it gets posted to the main threads message queue. Don't do this:
ThreadA->ThreadB_DoSomething();
ThreadB->ThreadA_Dosomething();Instead post a message WM_THREAD_A_DOSOMETHING As long as ThreadA never touches ThreadB you shouldn't have any problems. Also don't create any windows or enter any modal modal loops from your CWinThread worker thread... do all window management from your main thread. Follow these rules: 1.) Do all window creation in your main thread. 2.) Don't reach across threads to execute code. 3.) Use PostMessage to communicate between threads. You *can* break these rules but make sure that you fully understand the consequences and how to get around them. Raymond Chen explains how you can get around messages are eaten by modal loops[^] here. Best Wishes, -David Delaune
-
Hi,
Richard Andrew x64 wrote:
I ask because I do not want the application to terminate when the secondary thread terminates. My understanding of the docs is that that could happen if I use a UI thread.
Could you show me what you are referring to? The only way that I am aware of... where a CWinThread can terminate the main thread is if you reach across threads to execute code. If a WM_QUIT arrives during that short period I believe it gets posted to the main threads message queue. Don't do this:
ThreadA->ThreadB_DoSomething();
ThreadB->ThreadA_Dosomething();Instead post a message WM_THREAD_A_DOSOMETHING As long as ThreadA never touches ThreadB you shouldn't have any problems. Also don't create any windows or enter any modal modal loops from your CWinThread worker thread... do all window management from your main thread. Follow these rules: 1.) Do all window creation in your main thread. 2.) Don't reach across threads to execute code. 3.) Use PostMessage to communicate between threads. You *can* break these rules but make sure that you fully understand the consequences and how to get around them. Raymond Chen explains how you can get around messages are eaten by modal loops[^] here. Best Wishes, -David Delaune
Thank you for the detailed response. So you would recommend the UI version of CWinThread because it has a message pump already?
The difficult we do right away... ...the impossible takes slightly longer.
-
I don't have personal experience with this function but Microsoft doc seems pretty specific:
Quote:
You should call this function from a background thread. Failure to do so could cause the UI to stop responding.
So background thread it is! :)
Mircea
Yes, I was taken aback when I first saw that.
The difficult we do right away... ...the impossible takes slightly longer.
-
Thank you for the detailed response. So you would recommend the UI version of CWinThread because it has a message pump already?
The difficult we do right away... ...the impossible takes slightly longer.
Well,
Richard Andrew x64 wrote:
So you would recommend the UI version of CWinThread because it has a message pump already?
Even if you used a non-gui thread.... the Windows kernel auto-promotes a thread via
KiConvertToGuiThreadand increases the thread stack-size and gives it a message queue immediately when it makes a syscall[^] above 0x1000. In other words... as soon as you make your call to SHGetFileInfo[^] your thread will become a UI thread. You could prevent the auto-promotion by setting PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON but that would break your SHGetFileInfo and a myriad of other win32k system calls. You can use CWinThread and just follow the rules I laid out in my previous response. Best Wishes, -David Delaune -
Well,
Richard Andrew x64 wrote:
So you would recommend the UI version of CWinThread because it has a message pump already?
Even if you used a non-gui thread.... the Windows kernel auto-promotes a thread via
KiConvertToGuiThreadand increases the thread stack-size and gives it a message queue immediately when it makes a syscall[^] above 0x1000. In other words... as soon as you make your call to SHGetFileInfo[^] your thread will become a UI thread. You could prevent the auto-promotion by setting PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON but that would break your SHGetFileInfo and a myriad of other win32k system calls. You can use CWinThread and just follow the rules I laid out in my previous response. Best Wishes, -David Delaune
