Re: Relationship between Application.Exit() and AppDomain

Tech-Archive recommends: Fix windows errors by optimizing your registry

"Ben Voigt [C++ MVP]" <rbv@xxxxxxxxxxxxx> wrote in message news:unTjdFipIHA.3960@xxxxxxxxxxxxxxxxxxxxxxx
Sunny S wrote:
Hi Ben,

1. The Threads property of a Process instance should give you the set
of threads that are running in a given process or you can just use
Process.GetCurrentProcess.Threads.

2. Then for each thread in the ProcessThreadCollection returned by the
Threads property in (1) you can use the GetDomainID property to find
which AppDomains currently contain running threads and to map those
threads to individual AppDomains.

3. I am not sure if my speculations about your 3rd question are
correct, but I think that given the fact that AppDomains could be
unloaded and then recreated, even reused, I suspect, which is
certainly true for threads provided by the ThreadPool, associating an
AppDomain that started a particular thread with this thread or, the
other way round, associating a thread with an AppDomain that started
this thread might lead to confusion and/or could be costly. I doubt
that the runtime supports this. The only valid information would be
provided by an instant snapshot of which threads are running in which
AppDomains (see 2 above).

I was just trying to highlight the possibility that just because a thread is currently running code in one AppDomain, doesn't mean it doesn't have other AppDomains on the call stack and aborting the thread will interfere with those other AppDomains. Or are cross-AppDomain calls always marshalled to a thread dedicated to that AppDomain?

Consider for example the case where the plugin subscribed to an event in the main program. When the main program fires the event handlers, the plugin handler runs and hangs.


What exactly do you mean with hangs? Does it mean that the thread has stack in unmanaged land or what?



Willy.

.