Re: Some queries of User Interface Thread

From: Scott McPhillips [MVP] (org-dot-mvps-at-scottmcp)
Date: 10/07/04 

Date: Thu, 07 Oct 2004 07:16:08 -0500

Roland wrote:
> "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message news:<#Ev$6LBrEHA.3940@tk2msftngp13.phx.gbl>...
>
>>Roland wrote:
>>
>>
>>>Hello All
>>>Recently I started working on User Interface thread , But certain
>>>things are quite confusing. Hope I will get some clarification from
>>>all of you.
>>>
>>>1: The thread does not receive user message sent by PostThreadMessage
>>>when I am doing some lengthy operation in Run() method (overrided
>>>Run() function ) , Can you tell me why it is so ? I have written a
>>>handler for user defined message, But it's of no use when I am doing
>>>lengthy operation in Run().
>>>
>>>2: I read that the Run() function provides a default message loop for
>>>user interface thread. How Run() function works internally ? How it
>>>dispatches the messages ? Does it work asynchronously and dispatch
>>>messages ?
>>>
>>>3: Is it needed to write PeekMessage in Run() to handle my user
>>>defined messages ? Or Should I call CWinThread::Run() before to
>>>continue in Run() ?
>>>
>>>4: What Should I do in Run() when there are many user messages to
>>>process ? I mean to say that Should I use PeekMessage for each user
>>>defined message ?
>>
>>Hello Roland,
>>
>>1: If you are doing some lengthy operation in a thread then that is
>>where the thread is executing. A thread cannot execute in two places at
>>the same time, so it does not process waiting messages until you return
>>to the thread's message pump. This is exactly the same way that the
>>main thread in a GUI works: It processes one message at a time, and all
>>other messages wait until the code returns to MFC.
>>
>>2: You can look at the MFC source code to see how Run works internally.
>> It dequeues the next waiting message and dispatches it to the message
>>map system. It does not work asynchronously. But: You don't care how
>>Run works.
>>
>>3: 4: You should not call Run and you should not override Run. Forget
>>about Run and write message handler functions, very much like you would
>>do in the main GUI thread.
>>
>>If you need asynchronous notifications that will stop your lengthy
>>operation then you can detect events with WaitForMultipleObjects within
>>your lengthy loop, or you can detect messages in the queue with
>>MsgWaitForMultipleObjects.
>
>
>
>
> Hello Scott
> 1: I understood that a single thread can't work in two places at the
> same time.
> But I didn't get why did you tell me not to override Run() method.
> Infact I also read same thing in MSDN. Can you please elaborate the
> reason behind this ?
>
> 2: If I don't override the Run() , Where should I write the main
> functionality of Thread ? Does it require to post a message to thread
> and write my functionality in handler ?
>
> 3: How can I actually terminate the thread ? Can I do somewhat like
> this ...Post a message to a thread and call PostQuitMessage in its
> handler to terminate thread.
>
> 4: You suggested me to use WaitForMultipleObject and
> MsgWaitForMultipleObjects , But I saw PeekMessage in some articles .
> Which one will be more efficient ?

A UI thread is a complete, message-driven subsystem that contains its
own message pump. Typically all you need to do in such a thread is
write message handlers. When you use a message-driven thread it makes
sense to post a message to the thread when you want it to do something.

You haven't said anything about what your thread does or why you wanted
to override Run, so I can't comment on how you should arrange it. It's
not even clear whether you should be using a UI thread or a worker
thread. Does the "main functionality" of your thread ever complete an
operation, or does it just keep running forever? When it is not busy
what should it wair for?

3: Yes, that is how to terminate it.

4: UI threads are message-driven and suspend when their message queue is
empty. (Run uses PeekMessage to do this.) Worker threads are typically
driven by signaling events and suspend using WaitForMultipleObjects to
wait for the next event. Which method to use depends on which signaling
method you are using. MsgWaitForMultipleObject lets you do a bit of both. 

-- 
Scott McPhillips [VC++ MVP]

Relevant Pages