Re: Relationship between Application.Exit() and AppDomain

See inline.


WIlly.

"Sunny S" <sunny.s@xxxxxxxxxxxxxxxx> wrote in message news:5740021E-1C8F-422F-AF74-E45DE21AF7B6@xxxxxxxxxxxxxxxx
Hi Willi,

I agree that 'not in line with the docs' was, perhaps, an overstatement:).
What I actually wanted to say is that as far as I am concerned the
documentation was not clear about the scope of the Application object and the
relationship between Application, A.E method and AppDomains.

Well, as said before, Windows.Forms was designed to be used from the "default domain" only and not from muttiple AD's running in the same process. The reason is quite simple, the underlying Win32 Windows architecture doesn't know about AD's, it only knows about processes and threads and one thread which is important in the "Windows" context is the UI thread. It's the thread that must run a message pump in order to retrieve Window messages from the application and from the System.


For example, you say ' ... you create a new application (Application.Run(..)
in each of the domains/threads ...' Define 'application'. Surely it's not a
new Application object or is it? BTW, the documentation just says that
calling A.R 'Begins running a standard application message loop on the
current thread'. I am not trying to be argumentative, I'm just trying to
understand what's going on.


A.R creates an ApplicationContext (and a static Application instance ), it's the ApplicationContext who actually defines *the* application in terms of the MSDN docs.


Let's take one of your scenarios: "From AD1/thread1 you create another
thread, and you create a window and run a message pump in this thread." Why
can't I use the same logic as above and say that by 'creating a window and
running a message pump' on a new thread (through Application.Run(Form), I
presume) I create a new application?

You create a new Application in terms of the docs, that's right.


Let's futher modify this scenario so that the second thread is created, as
above, from AD1/thread1, but in a separate AppDomain (AD2), so that AD2 is a
'child' of AD1. In this case, calling A.E on either of the threads doesn't
stop the other (I did test it:).

Ok so you have:
AD1/T1 -> creates T2 -> creates AD2 -> call A.R which creates a new ApplicationContext (a new application as per msdn) which start a pump on T2.
Calling A.E in T2 will stop the pump on T2, destroy the ApplicationContext and as such stop this application.
The fact that you do this is a new AD is irrelevant, an AD != an "application".



You see, this is the sort of questions I was trying to clarify for myself
and I found your comments quite helpful, thank you.

"Willy Denoyette [MVP]" wrote:

"Sunny S" <sunny.s@xxxxxxxxxxxxxxxx> wrote in message
news:67A7646B-4AA9-4B6E-89F6-A4C8CBE9B522@xxxxxxxxxxxxxxxx
> Jon,
>
> I’ve just done some more tests. My understanding of Willy Denoyette’s
> explanation (see at the bottom of this thread) was that > Application.Exit()
> kills the message pumps in the current Appdomain and its ‘child’
> AppDomains.
>
> To verify this I further modified the code with AppDomains so that one > of
> the threads creates yet another ‘child’ AppDomain and starts yet > another
> message loop in it. This test showed that my understanding was > incorrect.
> All
> three message loops in those AppDomains are independent in the sense > that
> killing one of them doesn’t kill the others.
>



I know this is quite confusing, but I'm not sure why you consider this "not
inline with the docs".
Note that the docs talks about applications, and stopping all message pumps
in the application, it doesn't talk about threads running other AD's.

In your last sample you are creating separate AD/thread pairs *and* you
create a new application (Application.Run(..) in each of the
domains/threads, calling A.E in one of the AD/threads only stops the
(single) message pumps in this application, which is inline with the docs,
right?

Now, say the from AD1/thread1 you create another thread, and you create a
window and run a message pump in this thread. That means, you have
AD1/thread1 and thread2, and two separate message pumps. Calling A.E from
one of these threads will stop all (2) pumps, which is inline with the docs,
right?

And, say you have a AD/thread that runs an application
(Application.Run(...)], and this thread creates another AD that shows a
form. Here you have two AD's, one *Application* and only one thread that
pumps the message queue of both the main form and the other AD's form. When
you call A.E from the second form code, you will simply unload the second AD
and it's form, but you won't stop the message pump. Calling A.E from the
main form will stop the message pump and close all forms tear down the AD's
for the whole application, which is again inline with the doc's.

Willy.





.

Relevant Pages

  • Re: Relationship between Application.Exit() and AppDomain
    ... calling A.E on T1 closes Form1, ... > relationship between Application, A.E method and AppDomains. ... It's the thread that must run a message pump in order to retrieve ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Relationship between Application.Exit() and AppDomain
    ... relationship between Application, A.E method and AppDomains. ... running a message pump' on a new thread, ... calling A.E on either of the threads doesn't ... inline with the docs". ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Relationship between Application.Exit() and AppDomain
    ... calling A.R on a different thread in a separate AppDomain is ... It's the thread that must run a message pump in order to retrieve ... Window messages from the application and from the System. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: IMessageFilter and USER DEFINED MESSAGES
    ... This involves some GUI and it does have an internal ... In this situation multi threaded environment -multiple STA calling same ... Inside IMessageFilter::HandleInComingCall, I am getting ...
    (microsoft.public.vc.atl)