Re: Relationship between Application.Exit() and AppDomain

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.

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.

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
    ... 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: Cant Move Overlapped Window to Front
    ... I know that my message pump is working -- when I ... my OnPaint() handler executes and I ... can see the updates in the portion of my window not obscured by other ...
    (microsoft.public.vc.mfc)
  • Re: Where da message pump?
    ... I guess a better question is: Why is there a message pump at all? ... > a window of that class, add a few controls to that window, set the ... I do not need a message pump loop. ... > creates the window of custom class, it falls through to a message pump ...
    (microsoft.public.vb.winapi)
  • Re: Yet another timers-and-threads question
    ... SetTimer with callback function is not generally useful, ... sufficient that there's a message pump somewhere in the *application*, ... I can hook into an existing window somewhere and get it to process ... WM_TIMER, or I can set up a separate thread to do a waitable timer and the ...
    (microsoft.public.vc.mfc)
  • Re: problems with message order and GetCallInfo
    ... > runnin in parallel? ... The thing with the message pump is a little bit to high for me :-); ... > So you are using the hiddem window mechanism. ... > WNDPROC in TAPI. ...
    (microsoft.public.win32.programmer.tapi)
Loading