[Mono-dev] Mixed Mode Assemblies
tspink at gmail.com
Wed Jul 20 17:41:23 EDT 2011
On 20 July 2011 17:41, Robert Jordan <robertj at gmx.net> wrote:
> Hi Tom!
> On 20.07.2011 18:02, Tom Spink wrote:
> > Hi guys,
> > Since it's only 3.5k tarred up, I've attached it to this email - I hope
> > that's not too rude!
> > Let me know what you think! And don't give me a hard time for some of
> > hacks ;)
> I'm quoting from the TODO:
> > * Automate DLL_NAME to pull it from somewhere.
> We could store the necessary runtime version and the assembly
> name in the generated C++ stub, then use mono_jit_init_version
> for initialization.
Brilliant! Just an entry in the string table, and a symbol pointing to it
should do. Bit of linker script magic will probably help here.
> > * Rewrite each stub after first call to call the function pointer
> > proper, and hence bypass the NULL test.
> I'm biased whether this is necessary altogether.
> Is it a burden for the SO user if we'd require a first call
> of an provided initialization function?
> This function could be even called automatically, unless
> we really want to postpone mono's initialization.
Well, I went ahead and did it before I got your reply... Let me know what
you think. It's most certainly non-portable, which is a /bad thing/.
> > * Think about multiple loaded assemblies, and the impact that will have
> > on loading the runtime/appdomain twice.
> Maybe we should propose a mono_jit_is_initialized() for libmono,
> unless there is already a way to detect this, that we're not aware of.
Yes - this is a good idea. I'm also wondering if the support library should
actually be linked in as a shared library, in which case it can simply hold
a flag about whether or not the JIT has been loaded.
Looking at mono_jit_init(), it would be very easy to add a
mono_jit_is_initialized() function, by simply setting a flag in mono itself.
I think I remember seeing a discussion about multiple invocations of
mono_jit_init() somewhere - was there ever a resolution to that?
> > * Think about multi-threading, and how to invoke mono_thread_attach.
> IIRC, when I wrote the thunk support, I've reused a method
> wrapper type that already performs mono_thread_attach()
> on managed/unmanaged boundaries. I even wanted to introduce a
> new wrapper type to get rid of mono_thread_attach() for performance
> reasons, but never did it.
Interesting! That's quite clever actually - calling attach when actually
calling into the runtime via a thunk, from a thread that hasn't been
attached. Let me know your thoughts on getting rid of mono_thread_attach().
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list