-
September 24th, 2003, 09:32 AM
#1
What happens if thread is Slept() and WM_MESSAGE received?
What happens if thread is Slept() and WM_MESSAGE received?
the old place of execution is lost?
if message processing occurs in that thread?
Or thread execution continues, and than only message is proceed?
thanks.
-
September 24th, 2003, 09:38 AM
#2
What do you mean with thread is Slept()? I know about Sleep () which holds the threads for a given time and execution continues normally after that period.
Only UI threads can receive messages and these are stored in a queue. Whenever the thread gets processor time those messages are handled one after the other. So the execution point is not lost. Instead execution continues normally and the message is handled at its time.
-
September 24th, 2003, 09:42 AM
#3
sorry, it means-
Sleep(0) called
-
September 24th, 2003, 02:06 PM
#4
Correct.
Messages are stored in a queue. Once the thread resumes, it will continue processing the next message.
Kuphryn
-
September 24th, 2003, 02:22 PM
#5
That's interesting.
What would happen if one does a SendMessage to a window whose thread is suspended for some reason ? Does windows let the windowproc be called and put the thread back to suspended state ?
-
September 24th, 2003, 02:41 PM
#6
Originally posted by kirants
That's interesting.
What would happen if one does a SendMessage to a window whose thread is suspended for some reason ? Does windows let the windowproc be called and put the thread back to suspended state ?
highly doubtful, but I'm sure it can be found in documentation...and why you get into message deadlocks...the thread should be responsible for taking the message off the queue..I would imagine there is a call at the kernel level to determine if the thread is suspended and if it is, not to call the windows proc for the thread, that's speculation though without looking at it in the debugger.
Message Deadlocks
A thread that calls the SendMessage function to send a message to another thread cannot continue executing until the window procedure that receives the message returns. If the receiving thread yields control while processing the message, the sending thread cannot continue executing, because it is waiting for SendMessage to return. If the receiving thread is attached to the same queue as the sender, it can cause an application deadlock to occur. (Note that journal hooks attach threads to the same queue.)
-
September 25th, 2003, 01:49 AM
#7
Yes, it is correct.
I sometimes can not precisely identify where and how reenterancy happen
(If you know what call SendMessage to same thread and wait is happened,
it is obvious deadlock)
But for the situation some more complex?
Here is MFC involved - and if proceed some message
in main thread ion respond to device message and press some button that really calls some message handler...
but question is some else - will execution continue
from place where Sleep(0) called,
or will process message ?
I do following
Code:
Message handler - is blocking? (it looks so)
while( ::g_pMainFrame->m_PostMsg_Reseived != 1 )
{
ProceesMessages(0);
::Sleep(0);
// Process else PostMessage 's to this thread
//but not Process -in a result until this handler finishes
}
--------------------------------------
ProceesMessages{
while (PeekMessage((LPMSG) &msg, 0/*(HWND) hwnd*/, 0, 0, PM_REMOVE)) //0-for all windows in this thread
{
// Process any messages
TranslateMessage((LPMSG) &msg);
DispatchMessage((LPMSG) &msg);
}
}
I still can not resolve this situarion- does here can reenterancy occur?
Last edited by vgrigor3; September 25th, 2003 at 02:53 AM.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|