| Groups | Blog | Home |
dotnet clr : general runtime host question
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
See inline
Willy. [quoted text, click to view] "Stelrad Doulton" <___@____.com> wrote in message No each "shell'd process" is separate from the other (check this with news:OfGm8IzcFHA.2124@TK2MSFTNGP14.phx.gbl... > 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? > 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. [quoted text, click to view] > In the case of a shell executed application here's my understanding: Again, each run it's own Win32 process that hosts the CLR.> 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). > [quoted text, click to view] > This runtime-host creates an app domain, loads the application's primary Each process hosts the CLR, there is no such thing like a common runtime > 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? > host. [quoted text, click to view] > Here's another thing, I also read: There is no "the runtime host", each process loads the CLR, the process is > > "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? > 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. [quoted text, click to view] > Thanks to anyone who can shed some light > > > >
[quoted text, click to view]
"Stelrad Doulton" <___@____.com> wrote in message news:OfGm8IzcFHA.2124@TK2MSFTNGP14.phx.gbl... > 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. [quoted text, click to view] > 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. [quoted text, click to view] > 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. [quoted text, click to view] > 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? 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. [quoted text, click to view] > 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? 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. [quoted text, click to view] > Thanks to anyone who can shed some light
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? [quoted text, click to view] "Willy Denoyette [MVP]" <willy.denoyette@telenet.be> wrote in message news:uaZ8wUzcFHA.1384@TK2MSFTNGP09.phx.gbl... > See inline > > Willy. > > "Stelrad Doulton" <___@____.com> wrote in message > news:OfGm8IzcFHA.2124@TK2MSFTNGP14.phx.gbl... >> 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 >> 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? >> > Each process hosts the CLR, there is no such thing like a common runtime > host. > >> 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? >> > 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 >> >> >> >> > >
Sorry I re-posted before I had a chance to read Sean's answer.
All cleared up now. Thanks Gents [quoted text, click to view] "Stelrad Doulton" <___@____.com> wrote in message news:eJFxOrzcFHA.3504@TK2MSFTNGP12.phx.gbl... > 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? > > "Willy Denoyette [MVP]" <willy.denoyette@telenet.be> wrote in message > news:uaZ8wUzcFHA.1384@TK2MSFTNGP09.phx.gbl... >> See inline >> >> Willy. >> >> "Stelrad Doulton" <___@____.com> wrote in message >> news:OfGm8IzcFHA.2124@TK2MSFTNGP14.phx.gbl... >>> 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 >>> 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? >>> >> Each process hosts the CLR, there is no such thing like a common runtime >> host. >> >>> 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? >>> >> 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 >>> >>> >>> >>> >> >> > >
[quoted text, click to view] "Stelrad Doulton" <___@____.com> wrote in message news:eJFxOrzcFHA.3504@TK2MSFTNGP12.phx.gbl... > 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.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |