Re: MFC and threads
On Wed, 04 Apr 2007 15:25:17 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
I find the use of SendMessage to be based largely on luck, and I don't like to build
systems that depend on incidental timings to work correctly. If the main GUI thread is
blocked (and it might be by some DLL that is being used), the SendMessage locks up. Given
how little code it takes to do the PostMessage solution, and it not only works under all
conditions but can be generalized to allow clean thread shutdown, I find it a preferred
solution. (I don't actually WFSO, I WFMO and the first one is the shutdown event).
The thing is, if you don't use WFMO but instead use PostMessage/WFSO as
presented, you might as well use SendMessage, because the methods are
almost exactly equivalent. One difference lies in the reentrancy
possibility I described in my reply to David. Another is the behavior of
the race condition with target window destruction; if anything, SendMessage
is better behaved should the target window be destroyed at an inopportune
time, say, just before the SendMessage call or just after the PostMessage
call, before the message is retrieved. The sending thread should not be
creating an event to be used by the target window, because without some
sort of escape valve, it requires the message to be received and handled so
the event can be set. So, as I see it, either you can use SendMessage or
you can't. If you can't, then you need to use PostMessage/WFMO and deal
with the variety of subtleties that made using SendMessage impossible; this
will impact the design of both threads.
--
Doug Harrison
Visual C++ MVP