[Mono-dev] Multiple domains

[Brian Crowell]

Janne Rantala wrote:
> First, could someone specify what root domain exactly means and what is 
> it meant for?

As Zoltan said, it's the first domain created when an application starts up.

Play around with the AppDomain class in the .NET Framework for experience with 
domains.


> Mono project's web site says about mono_jit_init that "That will return 
> a MonoDomain where your code will be executed. You can create multiple 
> domains. Each domain is isolated from the other domains and code in one 
> domain will not interfere with code in other domains."
> But when I tried to initialize mono_jit_init with two different assembly 
> names, I got error saying "**ERROR**: file domain.c:line 517 
> (mono_init_internal):should not be reached aborting..."

You probably shouldn't create domains that way. I think mono_domain_create() 
will give you a new, uninitialized domain. 
ves_icall_System_AppDomain_createDomain() in appdomain.c shows an example of 
using this call, as well as how to add already-loaded assemblies to it.

Please note, though, that Mono does not adhere to the rules of creating new 
domains properly, and as such, you don't really get the guarantees of isolation 
that you should. This is documented as bug #76757.

   <http://bugzilla.ximian.com/show_bug.cgi?id=76757>


> But if I use mono_domain_get to get current domain (is that also root 
> domain?)  I can create objects from different assemblies just fine.

mono_domain_get() doesn't necessarily return the root domain, but it certainly 
will if it's the only domain. mono_get_root_domain() always gets the root.


> Is there some other way to initialize multiple domains?

There are several ways. Again, look through the AppDomain documentation for more 
help on this.

One way, if the same assemblies will be loaded in your root domain as your new 
one, is to use AppDomain.DoCallBack, which invokes a delegate in another domain. 
The corresponding code for this is duplicated in both AppDomain.cs, and (less 
accurately) in marshal.c (see mono_marshal_get_xappdomain_invoke for a low-level 
way of crossing between domains).

You can also do it in a way to avoid loading the target assembly in your new 
domain. Of course, you always need some common ground, so at least one common 
assembly needs to be loaded in both domains, but after that you can vary on 
which assembly you load and call into.

In my case, for example, I would create a new AppDomain with a different 
directory. I would create an instance of a MarshalByRefObject on the other side 
through a call to AppDomain.CreateInstanceAndUnwrap(), which avoids loading the 
target assembly in the root domain. (This is very important, as the target 
assembly doesn't exist in the root domain's path, and therefore the root domain 
can't load it anyways.) I cast the return value to an interface that is present 
in both domains, and I make calls on it.

The directory structure, for example, looks like this:

/app1
    Interface.dll
    Host.exe
/app2
    Interface.dll
    Hostee.dll

This allows me to create two domains, the first (my root) with the corlib, 
Interface.dll, and Host.exe assemblies, and the second with the corlib, 
Interace.dll, and Hostee.dll assemblies. With cross-domain calls, I can contact 
the second domain and have it do my bidding, and any objects it creates or 
assemblies it loads won't interfere with my first. When I'm done with my second 
domain, I can unload it and the assemblies will disappear. In effect, this is 
the only way to "unload" an assembly, and that's the main reason I use multiple 
domains.

Of course, I don't know what you're looking for in domains. They can be very 
complex at times, but they offer some interesting ways around some of the deeper 
restrictions of the CLI.

--Brian



> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list