[Mono-dev] Mixed Mode Assemblies

[Tom Spink]

On 20 July 2011 17:41, Robert Jordan <robertj at gmx.net> wrote:

> Hi Tom!
>

Hey!


> 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
> the
> > 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().


> Robert
>

-- Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20110720/e4c9348c/attachment.html