tags:

views:

36

answers:

1

Hi, I know that once a .NET application is launched, 3 Application Domains are created automatically by the CLR, they are System Domain, Shared Domain and Default Domain.

System Domain:

  • Create the Shared & Default domains
  • Provide the funcitons of loading and unloading application domains
  • Load mscorlib.dll into Shared domain
  • Bookkeeping of all other domains
  • Bookkeeping of interned string literals
  • Pre-creation of certain types of exceptions such as the out-of-memory exception, stack overflow exception, etc.

Shared Domain:

  • Contains domain neutral code.
  • Contains basic types such as String, enum, Int32, etc.

Default Domain:

  • .NET application code runs in it.

Here is a couple of questions about them:

  • What's the relationship of this 3 domains? Is there a hierarchy or something? Based on the responsibilities of System domain, I am thinking that the AppDomains in a process should be organized like a tree logically (or maybe physically in memory), the root of the tree is the System domain, and all the other domains are its children.

  • What does the "interned string" mean? Some example could be better.

  • AppDomain is meant for isolation, and cross-domain communication is not so easy to made. So I am wondering since the basic types are contained in Shared Domain rather than Default domain or any other AppDomain that could run code, so I believe the CLR must have treated the Shared domain uniquely to make an easy cross-domain communication. Is that true?

Thanks.

+3  A: 

I'd add this a a comment rather than an answer, but I'm not allowed to comment yet. Sorry.

Cross-AppDomain memory access (as opposed to remoting) is difficult and was made so by design.

If you want a cross-domain singleton, I found this little gem

smirkingman