Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / CLR / June 2005

Tip: Looking for answers? Try searching our database.

general runtime host question

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Stelrad Doulton - 17 Jun 2005 12:43 GMT
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

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.