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.

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.

sorry, it means-
Sleep(0) called

Correct.

Messages are stored in a queue. Once the thread resumes, it will continue processing the next message.

Kuphryn

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 ?

Quote:

---

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.

Quote:

---

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.)

---

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?