[Mono-dev] [PATCH] Allows mono_jit_init to be called multiple times without crashing.

[Tom Hindle]

On Fri, 2009-01-30 at 16:51 -0200, Rodrigo Kumpera wrote:
> Still, why can't your code do the mono_get_root_domain () check?

yes, good point thanks! (I think I must have assumed it wasn't exposed)

> 
> The Moonlight folks requested this as well and it turned out that what
> they
> needed was support for creating AppDomains from the unmanaged API.
> This
> has been included and will be part of the the upcoming 2.4 release.
> 
> 
> 
> 2009/1/30 Tom Hindle <tom_hindle at sil.org>
>         Hi,
>         
>         Attached for review is a patch that allows multiple calls to
>         mono_jit_init.
>         
>         I appreciate that the first response to this request may be,
>         'why would
>         you want to do that?' Given that, I will attempt to give a
>         justification.
>         
>         The reason I need to be able to do this is because:
>         
>         I have an existing C# application that uses native COM
>         objects, with
>         marshaling iterops automatically generated from the COM IDL
>         files, as
>         part of the build process.
>         
>         However as part of the Linux port I sometimes need to replace
>         select COM
>         objects with C# ones. I inform the application of this by
>         changing the
>         registry. (COM definition file on linux)
>         
>         Which I can do because previously I have created a
>         managed-Com-bridge (a
>         special native COM object that embeds mono and loads managed
>         COM
>         objects, before retuning a native ptr back through the COM
>         framework).
>         
>         However, since the managed-Com-bridge embeds mono, I need to
>         call
>         mono_jit_init to return the domain. However since mono is
>         already
>         running, a call to mono_jit_init asserts!
>         
>         Furthermore, COM objects are sometimes created indirectly by
>         other
>         native COM objects, meaning re-factoring C# code is not an
>         option. For
>         example, C# creates native COM object COM1 which itself
>         creates COM2,
>         which has now been replaced by a managed COM object.
>         
>         
>         Thanks,
>         Tom
>         
>         _______________________________________________
>         Mono-devel-list mailing list
>         Mono-devel-list at lists.ximian.com
>         http://lists.ximian.com/mailman/listinfo/mono-devel-list
>         
>