"Denis Adamchuk" <DenisAdamchuk@discussions.microsoft.com> wrote in
message
news:F28BCA97-1237-4CE8-9BB0-2EB94E8D8235@microsoft.com...
Joseph,
I completely understand advantages of the single UI thread.
Ok, probably there is no reason to do so.
But why there are no "DON'T DO IT" neither in MSDN nor in OldNewThing?
Seems strange!
I cannot tell to the project architect that multithreaded UI is risky
because there are no facts at all...
Some facts demonstrating why multithreaded UI is risky:
- It is documented that most actions performed on windows are done with a
SendMessage call.
- It is documented that SendMessage blocks the calling thread until the
target thread handles it.
- Parent/Child windows, and Owner/Owned windows, have
implementation-defined
communication between them that is hidden within the OS and undocumented.
- Therefore in a multithreaded UI with these window interrelationships we
have hidden, undocumented blocking calls and we don't even know what
actions
trigger them.
- There's a big risk: Potentially blocking calls in your thread that you
cannot predict. That leaves you with unknown effect on performance, and
of
course it introduces the possibility of deadlocks under unknown
conditions.
Displaying a top level window in a secondary thread is not affected by
this
line of reasoning, and indeed I've done it and it has worked OK for me.
But
displaying windows with interrelationships in different threads has
caused
many newsgroup posts, including yours, demonstrating that it has many
problems.
--
Scott McPhillips [VC++ MVP]