[Mono-dev] Mixed Mode Assemblies

[Robert Jordan]

Hi Tom!

On 20.07.2011 23:41, Tom Spink wrote:

>>> * Rewrite each stub after first call to call the function pointer
>>>   proper, and hence bypass the NULL test.

> 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/.

So GCC lets you take the address of a... label? :)

https://github.com/tspink/sogen/blob/master/test.dll.c#L23

>>> * 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.

That would work, too.

>
> 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?

I believe it was about non-interleaved mono_jit_init() and 
mono_jit_cleanup() sequences. The latter is still unable to clean
up properly. An interleaved mono_jit_init() is something that will
probably never work, apart from a trivial implementation that
does nothing when interleaved.

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

Do you mean getting rid of mono_thread_attach() from the current
thunk implementation? I'm afraid it's too late for this, because
the thunks became a public API.

Robert