Question

When we send a message, “if the specified window was created by the calling thread, the window procedure is called immediately as a subroutine“.
But “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.” (taken from MSDN documentation for SendMessage).

Now, I don’t understand how (or, more appropriately, when) the target windows procedure is called. Of course the target thread will not be preempted (the program counter is not changed). I presume that the call will happen during some wait function (like GetMessage or PeekMessage), it is true? That process is documented in detail somewhere?

---

Update: the rationale behind it is explained by the QS_SENDMESSAGE flag of GetQueueStatus() and MsgWaitForMultipleObjects():

QS_SENDMESSAGE
 A message sent by another thread or application is in the queue.

This, along with additional remarks in MSDN documentation, means that a message sent by another thread is actually posted to the queue. Then, as soon as GetMessage or PeekMessage are called, it will be processed before any other posted message by being sent directly to the window procedure.

Answer 1

I see some confusion here.

According to the MSDN docs, when you touch the message queue of the current thread with the intent of message processing (e.g. if you call PeekMessage or GetMessage), all pending sent (i.e. non-queued) messages from other threads are handled – passed to the WndProc – and then the message queue is checked, so:

• sent messages never go through DispatchMessage and are handled as soon as possible:
  • in the current thread, they are simply passed to WndProc
  • in another thread, they are handled before any posted message processing
• to be able to handle sent messages, the target thread still needs a message pump
• PostThreadMessage does just what it states – posts a message in a threads queue – such messages are not directed to any window and must be handled explixitly
• the only messages handled by DispatchMessage are those created by PostMessage or some system facility (timers, events, user input, etc.)
• to avoid deadlocks, use SendNotifyMessage, SendMessageTimeout or SendMessageCallback instead of plain SendMessage between different threads

For further reference, study the Remarks section of the MSDN PeekMessage entry.