Re: SendMessage() will block if message queue is not empty?
On Wed, 16 Jul 2008 08:59:15 +0800, asm23 <asmwarrior@gmail.com> wrote:
hi, every one, my question seems to be very simple. When I call
SendMessage() to send a message to a window, the OS will call the window
procedure directly and wait until it's return.
If the window was created by the thread calling SendMessage (intrathread
SendMessage), then SendMessage amounts to a normal function call of the
window procedure. Things get a lot more interesting when a thread calls
SendMessage on a window it didn't create (interthread SendMessage).
But, now, if the window
procedure is running or processing some message( which means the message
queue is not empty). Does it means the call will delayed until all other
message is processed?
For the intrathread case, it doesn't matter, because SendMessage amounts to
a normal function call.
For the interthread case, the sending thread will block until the target
thread enters a receptive state, which includes calling GetMessage,
PeekMessage, WaitMessage, etc, and perhaps surprisingly, SendMessage.
Windows will then switch to the target thread and allow it to process the
message. The sending thread remains blocked until the target thread returns
from the window procedure or calls ReplyMessage. This blocking behavior and
thread context switching can lead to deadlock if you aren't careful, but
the danger is often exaggerated since most people don't seem to know that a
thread stuck waiting on an interthread SendMessage call can still process
messages sent to it; IOW, it's not totally dead like it would be if it had
called WaitForSingleObject.
I haven't said anything about the message queue so far. Sent messages are
never queued, at least not in the normal sense, but Windows does (has to)
maintain a separate queue for interthread sent messages. This is more a
"thread queue" than a message queue, though; that is, it's a queue of
threads waiting to execute their interthread SendMessage calls.
--
Doug Harrison
Visual C++ MVP