Interleaved ...
At 10:20 AM 7/19/2006, Peter Ritchie wrote
>I've changed subjects, I don't want Michael's thread to get hijacked...
>
>J., define what you mean by "can"... If you mean "it will compile"; that's
>not an indicator of correctness.
When I wrote "can" I meant "Windows, the CLR, and the .Net Framework permit" --
and I just don't see why MS would have built them to permit this if there were
an inviolable Windows rule about multiple UI threads in a process. I'm not
saying that you're definitely wrong; I'm saying that there's a lot of evidence
that no "only one UI thread per process" rule exist.
>[removed many examples of things that you "can" do that work only accidentally]
>
>What I'm trying get to the bottom of is, recommended UI thread (aka window
>message pump or window message loop) count restrictions. Nobody really seems
>to know for sure, one way or another. It's pretty clear that one UI thread is
>supported, what's not clear is whether multiple UI threads per process are
>supported.
.Net includes AppDomains in order to allow multiple logical processes to be
hosted in a single Windows process. The reason that Windows processes have
rather high overhead is to support the near-total isolation of each process, so
that misbehaved code in other processes (accidental or intentional) does not
impact a well-behaved process. That advantage of "process isolation" is
(theoretically at least) not needed with managed code. (Source: Jeffrey
Richter, "CLR via C#", pages 17 and 526 [among many].)
I don't think MS would have gone to the trouble of (in essence) re-implementing
the notion of "process" if there were an existing Windows restriction that you
can't have more than one UI thread in the same Windows process. Or, if they
had done so, they would have enforced the "only one UI thread" rule by having
violations of the policy result in failed API calls.
A restriction that I know exists is "the thread that creates a window must be
the thread that handles all messages sent to that window." That means that any
thread that creates GUI objects (=windows) must have a "message pump" so that
it can receive the messages. It doesn't say anything about how many threads in
a process are allowed to create GUI objects (and have message pumps etc).
>[snip]
>Yes, many people have written applications with more than one UI thread ...
>but [that] doesn't mean it's supported.
If Windows didn't support it, wouldn't it fail calls to CreateWindow from
subsequent threads? ("subsequent threads" meaning "threads other than the one
that made the first CreateWindow call in the process, if there are any existing
windows still owned by that thread.")
>For the moment, I'm airing [sic] on the side of caution: restricting my UI
>threads to one per application--I know that is supported.
You won't cause any problems doing that, but I don't think that you're
justified in being afraid to do otherwise.
>On Wed, 19 Jul 2006 09:20:02 -0400, J. Merrill <[EMAIL PROTECTED]> wrote:
>
>>At 01:08 AM 7/19/2006, Peter Ritchie wrote (in part)
>>>I'm of the opinion that Windows only supports one UI thread per process.
>>
>>If multiple AppDomains can exist within a single process, and each can be
>hosting an app with a UI, doesn't that suggest the opposite?
>>
>>I'm not saying that's a definitive answer, but it certainly points the
>>other way -- or am I missing something?
J. Merrill / Analytical Software Corp
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
