[Mono-dev] Multiple domains
mono-devel at fluggo.com
Thu Jun 29 13:10:55 EDT 2006
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
> 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.
> 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:
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
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.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list