What I want to know is; do all shell executed .NET app run in the same
process? For that matter do all runtime-hosts run all of their app-domains
in the same process?
In the case of a shell executed application here's my understanding: Double
clicking a .NET executable file invokes a runtime host specifically for
running user space apps (by which I mean services, exe's etc - not hosted by
IIS, SQL Server or anything else).
This runtime-host creates an app domain, loads the application's primary
assembly and kicks it off at the entry point. Referenced assemblies are
loaded at the point at which they are first needed. So is this runtime host
an ever present process on my machine? Is there a limit to the number of add
domains it can support in one process?
Here's another thing, I also read:
"There is not a one-to-one correlation between application domains and
threads. Several threads can be executing in a single application domain at
any given time"
OK
"and a particular thread is not confined to a single application domain. "
eh?
"That is, threads are free to cross application domain boundaries; a new
thread is not created for each application domain."
So is the run-time host playing scheduler for a predefined number of threads
switching them between app domains?
Thanks to anyone who can shed some light
Willy Denoyette [MVP] - 17 Jun 2005 13:07 GMT
See inline
Willy.
> What I want to know is; do all shell executed .NET app run in the same
> process? For that matter do all runtime-hosts run all of their app-domains
> in the same process?
No each "shell'd process" is separate from the other (check this with
taskman), there is not such a thing you call a global "runtime host", each
managed application runs in it's own process that hosts the CLR, just like
any other native Win32 application.
> In the case of a shell executed application here's my understanding:
> Double
> clicking a .NET executable file invokes a runtime host specifically for
> running user space apps (by which I mean services, exe's etc - not hosted
> by
> IIS, SQL Server or anything else).
Again, each run it's own Win32 process that hosts the CLR.
> This runtime-host creates an app domain, loads the application's primary
> assembly and kicks it off at the entry point. Referenced assemblies are
[quoted text clipped - 3 lines]
> add
> domains it can support in one process?
Each process hosts the CLR, there is no such thing like a common runtime
host.
> Here's another thing, I also read:
>
[quoted text clipped - 15 lines]
> threads
> switching them between app domains?
There is no "the runtime host", each process loads the CLR, the process is
obviously just a normal Win32 process, that it hosts the CLR (a bunch of
DLL's that gets loaded when a .NET PE executable is being loaded) is a
byproduct and is in no way different from a Win32 process that hosts the C
runtime.
> Thanks to anyone who can shed some light
Stelrad Doulton - 17 Jun 2005 13:45 GMT
Thanks Willy, that clears a lot up for me. Perhaps the scenario I was
describing is more like what goes on in IIS.
Anyway, I am still a bit confused by the assertioan that Threads are free to
cross App Domain boundaries. Surely this can only refer to the CLR threads,
otherwise where's the isolation?
> See inline
>
[quoted text clipped - 58 lines]
>
>> Thanks to anyone who can shed some light
Stelrad Doulton - 17 Jun 2005 13:50 GMT
Sorry I re-posted before I had a chance to read Sean's answer.
All cleared up now.
Thanks Gents
> Thanks Willy, that clears a lot up for me. Perhaps the scenario I was
> describing is more like what goes on in IIS.
[quoted text clipped - 65 lines]
>>
>>> Thanks to anyone who can shed some light
Willy Denoyette [MVP] - 17 Jun 2005 18:32 GMT
> Thanks Willy, that clears a lot up for me. Perhaps the scenario I was
> describing is more like what goes on in IIS.
>
> Anyway, I am still a bit confused by the assertioan that Threads are free
> to cross App Domain boundaries. Surely this can only refer to the CLR
> threads, otherwise where's the isolation?
Yes, this refers to logical threads only, however, OS threads are free to
cross application domain boundaries, this is the case in remoting
(in-process) scenarios like Sean very well explained.
The number of application domain is not limitted other than by process
memory, this limits the number to several thousand AD, of course it makes
little sense to create that number of AD.
Willy.
Sean Hederman - 17 Jun 2005 13:31 GMT
> What I want to know is; do all shell executed .NET app run in the same
> process?
No, each application will exist in it's own process.
> For that matter do all runtime-hosts run all of their app-domains
> in the same process?
Yes, the app-domains created for an application will all exist in that
application's process.
> In the case of a shell executed application here's my understanding:
> Double
> clicking a .NET executable file invokes a runtime host specifically for
> running user space apps (by which I mean services, exe's etc - not hosted
> by
> IIS, SQL Server or anything else).
Not entirely. Running a .NET EXE loads a startup shim which then creates a
runtime host for that application. There isn't one overall runtime host, but
one for each app.
> This runtime-host creates an app domain, loads the application's primary
> assembly and kicks it off at the entry point. Referenced assemblies are
[quoted text clipped - 3 lines]
> add
> domains it can support in one process?
The runtime hosts are present for the duration of your .NET application. As
for the number of app-domains in a process, I have no idea.
> Here's another thing, I also read:
>
[quoted text clipped - 15 lines]
> threads
> switching them between app domains?
Not really. If you kick off a synchronous operation to another app-domain
merely means that your thread enters that new app-domain. When it completes
there it will return to the originating app-domain. Think of a method call
where the caller and callee are in different app-domains. There is only one
thread, but two app-domains. That said, the most common means of
communicating between app-domains involve Remoting, and this muddies the
waters a little, since the caller's thread is suspended, whilst the callee
executes on a ThreadPool thread.
Also, the ThreadPool threads themselves are shared amongst all the
app-domains.
> Thanks to anyone who can shed some light