Re: MFC and threads
On Thu, 05 Apr 2007 16:21:26 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
But a GetMessage wait allows other asynchronous events (such as PostMessage calls) to be
handled, allowing the thread to deal with other events it might have to deal with.
Such as? Typically, there are only two events my threads need to handle in
such situations, the response or a quit request. For that, I can use WFMO
right there on the spot, and I don't have to convert my worker thread into
an UI thread by adding a superfluous message loop. The main point of a
worker thread is to do a lengthy, sequential operation that can proceed
(more or less, with the emphasis on "more") independently from the main UI
thread without having to service a message loop to maintain responsiveness,
so I'm wondering why we're talking about GetMessage anyway.
I have learned over the years that the key to doing good thread design is to think
completely asynchronously, and keep state and control as completely orthogonal. What I
see far too many programmers doing is forcing weird implementations because they want
sequential operations to be written syntactically sequentially, and keeping a lot of state
implicit in the call stack and local variables. That's where a lot of threading projects
fail, and I make a lot of money rewriting them to be viable.
Certainly, if you try to program something sequentially that needs to be
asynchronous, you'll have problems. On the other hand, if you try to turn
an inherently sequential process into an event-driven state machine, you'll
just introduce complexity reminiscent of Win16 PeekMessage (AKA
cooperative) multitasking. What I think you're describing is worth the
trouble only if the thread can do something else pending the result, and
this does not apply to the OP's problem. To put all this into concrete
terms, transform the following worker thread pseudocode into your
asynchronous model and explain the benefits:
X x;
a(x);
Y y;
if (!get_info_from_other_thread(y))
return;
b(x, y);
The function get_info_from_other_thread uses PostMessage/WMFO to cause the
other thread to (say) display a dialog box (though it doesn't have to), and
it returns false if the thread should exit. The thread cannot proceed until
it gets its answer, and when I say that, I mean to imply that it cannot do
anything else. You can assume a() and b() are purely sequential and take a
long time, so it did make sense to break this out into a worker thread.
--
Doug Harrison
Visual C++ MVP