Re: Relationship between Application.Exit() and AppDomain

"Sunny S" <sunny.s@xxxxxxxxxxxxxxxx> wrote in message news:C30ACC37-E41C-4546-8739-7F04FAE1070E@xxxxxxxxxxxxxxxx
Hi Willi,

We are almost there:):):)

To recap, we have: AD1/T1 -> calls A.R(Form1); creates T2 -> creates AD2 ->
call A.R(Form2). Here calling A.E on T2 does close Form2, but doesn't close
Form1. The reverse is also true: calling A.E on T1 closes Form1, but doesn't
close Form2.


Yep.

I accept your explanation that A.R(Form2) creates a new 'application' that
is independent of the application running Form1, so exiting one of them
doesn't affect the other.

Why then things are different for the following scenario: AD1/T1 -> calls
A.R(Form1); creates T2 -> calls A.R(Form2), where we don't create a separate
AppDomain for T2? As you pointed out erlier, closing either Form1 or Form2
closes the other Form and shuts down the application.

Here you create one AD, 2 threads, 2 applications (ApplicationContexts, ApplicationThreadContexts, etc... ) , 2 message pumps (one per thread).
When you call A.E in one of the threads, you get rid of all of the ApllicationContexts in the containing AD and it's AD children.
Note that what's happening is quite more complex, but that's the big picture.

Why are you so interested in A.E's behavior, which is not the most appropriate way to stop an application anyway, just currious.


Apparently, calling A.R on a different thread in a separate AppDomain is
somehow different from calling it in the same AppDomain. Would it be correct
to assume that the scope of Application.Exit() is limited to the current
AppDomain only?


"Willy Denoyette [MVP]" wrote:

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
    ... relationship between Application, A.E method and AppDomains. ... It's the thread that must run a message pump in order to retrieve Window messages from the application and from the System. ... 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
    ... 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)