<div class="gmail_quote">On 20 July 2011 17:41, Robert Jordan <span dir="ltr">&lt;<a href="mailto:robertj@gmx.net">robertj@gmx.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Tom!<div><div class="h5">
</div></div></blockquote><div><br></div><div>Hey!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">On 20.07.2011 18:02, Tom Spink wrote:<br>

&gt; Hi guys,<br>
&gt;<br>
&gt; Since it&#39;s only 3.5k tarred up, I&#39;ve attached it to this email - I hope<br>
&gt; that&#39;s not too rude!<br>
&gt;<br>
&gt; Let me know what you think!  And don&#39;t give me a hard time for some of the<br>
&gt; hacks ;)<br>
<br>
</div></div>I&#39;m quoting from the TODO:<br>
<br>
&gt; * Automate DLL_NAME to pull it from somewhere.<br>
<br>
We could store the necessary runtime version and the assembly<br>
name in the generated C++ stub, then use mono_jit_init_version<br>
for initialization.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

&gt; * Rewrite each stub after first call to call the function pointer<br>
&gt;   proper, and hence bypass the NULL test.<br>
<br>
I&#39;m biased whether this is necessary altogether.<br>
<br>
Is it a burden for the SO user if we&#39;d require a first call<br>
of an provided initialization function?<br>
<br>
This function could be even called automatically, unless<br>
we really want to postpone mono&#39;s initialization.<br></blockquote><div><br></div><div>Well, I went ahead and did it before I got your reply... Let me know what you think.  It&#39;s most certainly non-portable, which is a /bad thing/.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
&gt; * Think about multiple loaded assemblies, and the impact that will have<br>
&gt;   on loading the runtime/appdomain twice.<br>
<br>
Maybe we should propose a mono_jit_is_initialized() for libmono,<br>
unless there is already a way to detect this, that we&#39;re not aware of.<br></blockquote><div> </div><div>Yes - this is a good idea.  I&#39;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.</div>
<div><br></div><div>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.</div><div><br></div><div>I think I remember seeing a discussion about multiple invocations of mono_jit_init() somewhere - was there ever a resolution to that?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
&gt; * Think about multi-threading, and how to invoke mono_thread_attach.<br>
<br>
IIRC, when I wrote the thunk support, I&#39;ve reused a method<br>
wrapper type that already performs mono_thread_attach()<br>
on managed/unmanaged boundaries. I even wanted to introduce a<br>
new wrapper type to get rid of mono_thread_attach() for performance<br>
reasons, but never did it.</blockquote><div><br></div><div>Interesting!  That&#39;s quite clever actually - calling attach when actually calling into the runtime via a thunk, from a thread that hasn&#39;t been attached.  Let me know your thoughts on getting rid of mono_thread_attach().</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">
Robert<br></div></div></blockquote></div><div><br></div>-- Tom<br>