VC Language - UI Thread : Where's the processing?

Author

UI Thread : Where's the processing?

Roger Garrett

2006-01-24, 7:07 pm

I'm creating a User-Interface thread, derived from CWinThread. I create an
instance of my thread with:

CHostTransactionHandlerThread* pThread =
(CHostTransactionHandlerThread*)AfxBegin
Thread(
RUNTIME_CLASS(CHostTransactionHandlerThr
ead),
THREAD_PRIORITY_NORMAL,
1000, // Stack Size
CREATE_SUSPENDED);

I then set some member variables (which is why I create it with
CREATE_SUSPEND). And then I start up the thread:

pThread->ResumeThread()

I see from CWinThread documentation that my thread's overridden InitInstance
method will get called in order to let me do any necessary initialization.
And I also see that its ExitInstance method will get called when it's all
done.
What I don't see is where (within what method) I should do the main
processing of the thread.
I've come across some examples of UI threads and they all do the main
processing of the thread within the InitInstance method. But that just
doesn't seem right. That's for initialization, not for main processing, I
would assume.
There's also a CWinThread::Run() method that would SEEM to be a reasonable
place to do it, but that's a message pump, and it's also described in the
documentation as "Rarely overridden".
So, where should I do the main processing of my thread?

- Roger Garrett

Igor Tandetnik

2006-01-24, 7:07 pm

Roger Garrett <RogerGarrett@discussions.microsoft.com> wrote:
> I'm creating a User-Interface thread, derived from CWinThread. I
> create an instance of my thread with:
>
> I see from CWinThread documentation that my thread's overridden
> InitInstance method will get called in order to let me do any
> necessary initialization. And I also see that its ExitInstance method
> will get called when it's all done.
> What I don't see is where (within what method) I should do the main
> processing of the thread.

You've created a UI thread. This assumes you are going to create one or
more windows on this thread and do your work in response to window
messages - just as you do on the main thread.

Maybe you want a worker thread instead?
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Roger Garrett

2006-01-24, 7:07 pm

Igor,

I guess you're right. My reading of the documentation on worker and UI
threads left me a bit

. It appeared to me that what it was saying was
that, if you want your main application window to continue to receive UI
messages you had to use UI threads for any of your threading needs. And then
I found some examples on the Internet they seemd to support my mistaken
understanding. [In addition, those examples all did their main processing for
the thread within the InitInstance method and then returned FALSE from
InitInstance to effectively shut the thread down. So I guess I was led
astray, even farther from my initial confusion].

So, thank you for the advice.

Roger Garrett

"Igor Tandetnik" wrote:

> Roger Garrett <RogerGarrett@discussions.microsoft.com> wrote:
>
> You've created a UI thread. This assumes you are going to create one or
> more windows on this thread and do your work in response to window
> messages - just as you do on the main thread.
>
> Maybe you want a worker thread instead?
> --
> With best wishes,
> Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925
>
>
>

William DePalo [MVP VC++]

2006-01-24, 7:07 pm

"Roger Garrett" <RogerGarrett@discussions.microsoft.com> wrote in message
news:70A82DD7-A979-4792-8153-6B524B575B5B@microsoft.com...
> I guess you're right. My reading of the documentation on worker and UI
> threads left me a bit

.

The worker / UI dichotomy is an MFC thing.

It is important to point out that at the level of the operating system, user
threads are user threads. There is no distinction between UI and worker
threads. The message queue which is necessary for a UI thread is created on
demand when a thread first performs an operation that requires a thread.

It is also important to note that windows and threads have a natural
affinity. The thread that creates a window is the one into whose message
queue the window's messages are deposited. Further, it is the only thread
that will receive the messages for the windows that it owns when it calls
GetMessage() or P

Message().

Now, applications which don't drain their message queue appear "stuck" or
"hung" to the user as painting goes undone and clicks and keystrokes have no
effect. For this reason, it is generally considered a good idea to perform
any long running task in a thread which does not have to pump messages.
Similarly, it is a bad idea to perform lengthy tasks in the UI thread unless
you have some way of polling the message queue periodically.
MsgWaitForMultipleObjectsEx() is good at that.

I hope that I have alleviated some confusion. If I have added to it please
post again.

Regards.
Will

William DePalo [MVP VC++]

2006-01-24, 7:07 pm

"William DePalo [MVP VC++]" <willd.no.spam@mvps.org> wrote in message
news:uH8G9fUIGHA.1424@TK2MSFTNGP12.phx.gbl...
>The message queue which is necessary for a UI thread is created on demand
>when a thread first performs an operation that requires a thread.

Oops. Make that

>The message queue which is necessary for a UI thread is created on demand
>when a thread first performs an operation that requires a _queue_.

Regards,
Will

Scott McPhillips [MVP]

2006-01-24, 7:07 pm

Roger Garrett wrote:
> Igor,
>
> I guess you're right. My reading of the documentation on worker and UI
> threads left me a bit

. It appeared to me that what it was saying was
> that, if you want your main application window to continue to receive UI
> messages you had to use UI threads for any of your threading needs. And then
> I found some examples on the Internet they seemd to support my mistaken
> understanding. [In addition, those examples all did their main processing for
> the thread within the InitInstance method and then returned FALSE from
> InitInstance to effectively shut the thread down. So I guess I was led
> astray, even farther from my initial confusion].

The so-called MFC UI thread is designed to be message driven, using its
built in message pump. If you don't want or need a message driven
thread then you can feel free to start a worker thread, which is simply
a function. Such a worker thread function is probably what you are
looking for as the place where a thread does its "main processing." MFC
certainly does not require you to use UI threads - it provides two
prototypes of AfxBeginThread - one for creating UI threads and one for
creating worker threads.

--
Scott McPhillips [VC++ MVP]

Sponsored Links