Threads and Messages
-
If I have a worker thread (let's call it thread B) and I have a control on my main window whose WndProc() is in the main application thread (thread A), and I use SendMessage() to the control from thread B, is the message processed in thread A or in thread B? What about with PostMessage()? Jeff Sand jsand at interaccess dot com
-
If I have a worker thread (let's call it thread B) and I have a control on my main window whose WndProc() is in the main application thread (thread A), and I use SendMessage() to the control from thread B, is the message processed in thread A or in thread B? What about with PostMessage()? Jeff Sand jsand at interaccess dot com
The message is processed in A in both cases. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
If I have a worker thread (let's call it thread B) and I have a control on my main window whose WndProc() is in the main application thread (thread A), and I use SendMessage() to the control from thread B, is the message processed in thread A or in thread B? What about with PostMessage()? Jeff Sand jsand at interaccess dot com
I suggest an excellent article "Using Worker Threads" [^] on this subject to your attention. Zdenek
-
If I have a worker thread (let's call it thread B) and I have a control on my main window whose WndProc() is in the main application thread (thread A), and I use SendMessage() to the control from thread B, is the message processed in thread A or in thread B? What about with PostMessage()? Jeff Sand jsand at interaccess dot com
In A as the others have said. It is not a good idea to use SendMessage between threads as you are asking for a deadlock to come knocking on your door. Neville Franks, Author of ED for Windows. www.getsoft.com
-
The message is processed in A in both cases. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Are you sure about that? When you SendMessage you call the WndProc directly, bypassing the pump. So SendMessage would be in the context of the worker thread, while PostMessage would be in the context of the main thread (which runs the message pump). This is also the way COM handles a call to a STA component (by posting messages instead of calling the components interfaces directly). Of course, I may be wrong ;-) Cheers Steen. "To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
-
Are you sure about that? When you SendMessage you call the WndProc directly, bypassing the pump. So SendMessage would be in the context of the worker thread, while PostMessage would be in the context of the main thread (which runs the message pump). This is also the way COM handles a call to a STA component (by posting messages instead of calling the components interfaces directly). Of course, I may be wrong ;-) Cheers Steen. "To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
Are you sure about that? I'm 100% sure, if you pardon my arrogance.
SendMessageonly bypasses the message pump if issued from the same thread that attends the message. Otherwise, the message is queued as usual and the caller thread blocks until the target thread processes the message. As a side note, usingSendMessagefrom worker threads is likely, if no care is taken, to result in deadlocks. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo -
Are you sure about that? I'm 100% sure, if you pardon my arrogance.
SendMessageonly bypasses the message pump if issued from the same thread that attends the message. Otherwise, the message is queued as usual and the caller thread blocks until the target thread processes the message. As a side note, usingSendMessagefrom worker threads is likely, if no care is taken, to result in deadlocks. Joaquín M López Muñoz Telefónica, Investigación y DesarrolloRelaying facts is not arrogance! I should have read the MSDN entry on SendMessage more carefully: If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine. If the specified window was created by a different thread, the system switches to that thread and calls the appropriate window procedure. Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message. No doubt here. I stand corrected :-O . But at least I was right on the "I could be wrong"-part :) Cheers Steen. "To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
-
Relaying facts is not arrogance! I should have read the MSDN entry on SendMessage more carefully: If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine. If the specified window was created by a different thread, the system switches to that thread and calls the appropriate window procedure. Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message. No doubt here. I stand corrected :-O . But at least I was right on the "I could be wrong"-part :) Cheers Steen. "To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
Well, as happens so often, 100% sureness is a hard position to maintain :) As for the thread context switch, there's still no doubt about it. What I'm not so sure is whether the message sent gets queued or not. My hunch, after re-reading the docs, is that it is not, so it surpasses all other messages currently queued in the target thread. Most of the time this is of little relevance, I guess. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
Well, as happens so often, 100% sureness is a hard position to maintain :) As for the thread context switch, there's still no doubt about it. What I'm not so sure is whether the message sent gets queued or not. My hunch, after re-reading the docs, is that it is not, so it surpasses all other messages currently queued in the target thread. Most of the time this is of little relevance, I guess. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
Joaquín M López Muñoz wrote: I'm not so sure is whether the message sent gets queued or not It doesn't (checked and 100% sure :)). rechi
Thanx for the info! How did you do the test (just curious)? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
Thanx for the info! How did you do the test (just curious)? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
I've created a SDI application with a menu item used to start the worker. The code:
void CMainFrame::OnFileThread() // menu item
{
DWORD *th=new DWORD;
HANDLE h=::CreateThread(NULL, 0, ThreadProc_, m_hWnd,
0, th);Sleep(3000);
delete th;
}DWORD WINAPI ThreadProc_(
LPVOID lpParameter // thread data
)
{
MSG msg;TRACE("in thread proc\n");
::PostMessage((HWND)lpParameter, WM_DUMMY3, 0, 0); // queued
::SendMessage((HWND)lpParameter, WM_DUMMY2, 0, 0); // calls Func2, a handlerreturn 0;
}LRESULT CMainFrame::Func2(WPARAM, LPARAM) // treating WM_DUMMY2
{
MSG msg;TRACE("in dummy2\n");
while (::GetMessage(&msg, NULL, 0, 0))
if (msg.message==WM_DUMMY3)
{
TRACE("found dummy3\n");
return 0;
}return 0;
}And the debug output:
in thread proc
in dummy 2
found dummy 3Due to your obvious programming skills, it should be enough :-O. rechi
-
Well, as happens so often, 100% sureness is a hard position to maintain :) As for the thread context switch, there's still no doubt about it. What I'm not so sure is whether the message sent gets queued or not. My hunch, after re-reading the docs, is that it is not, so it surpasses all other messages currently queued in the target thread. Most of the time this is of little relevance, I guess. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Hmmm. The docs suggest that the message goes through the queue ("Messages sent between threads are processed only when the receiving thread executes message retrieval code."), but doesn't specify if it gets in front of the line or has to wait until the messages in front is processed. Where's Jeff Richter or Mike Blaszczak when you need them ;P? Anyway, it's probably of little consequence. Cheers Steen. "To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"