"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
From the MSDN:
"A thread that calls the SendMessage function to send a message to another
thread cannot
continue executing until the window procedure that recevies the message
returns. If the
receiving thread yields control while processing the message, the sending
thread cannot
continue executing, because it is waiting for the SendMessage to return.
If the receiving
thread is attached to the same queue as the sender, it can cause an
application deadlock
to occur."
joe
On Wed, 9 Jan 2008 21:11:02 -0800, "Alexander Grigoriev"
<alegr@earthlink.net> wrote:
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:t44bo3dnh0ot7rec9mntg6qj8168tnfn9o@4ax.com...
****
It serializes access, and it also means that if there is any kind of
deadlock potential,
this will find it. I've had this happen. Suppose you SendMessage to
the
main GUI thread,
and the main GUI thread does a SendMessage to your UI thread. Your main
thread and the UI
thread are mutually deadlocked and your app is effectively dead, dead,
dead. You keep the
This example is wrong. SendMessage is a valid point for dispatching sent
messages, provided precisely to avoid this kind of deadlock.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm