<br><br><div class="gmail_quote">On Wed, Feb 8, 2012 at 1:43 PM, Miguel Mudge <span dir="ltr"><<a href="mailto:michael.mudge@welchallyn.com">michael.mudge@welchallyn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">On Wed, Feb 8, 2012 at 9:36 AM, Rodrigo Kumpera <span dir="ltr"><<a href="mailto:kumpera@gmail.com" target="_blank">kumpera@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="gmail_quote"><div>The idea is to switch away from raising the exception directly in native code to set the pending field and let the transition code do it.</div></div></blockquote><div><br></div></div><div>I love this idea, and it's tremendously useful to me.  I'll see if I can finish it.</div>
<div class="im">

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>It looks like it's partially implemented for AMD64 only - I propose stripping the related calls from exceptions-amd64.c, and have mono_thread_execute_interruption return mono_thread_get_and_clear_pending_exception() somewhere near the end.</div>



</blockquote><div><br></div></div><div>If you are willing to finish the work for amd64, it would be much welcome.</div></div></blockquote><div><br></div></div><div>The AMD64-specific work looks like it is part of the AMD64 JIT.  I don't have the ability to follow this model and I don't think it's necessary.  I will instead simplify the existing partially-implemented framework, and strip the AMD-specific code because:</div>
<div class="im">

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><div>The async exception machinery needs some cleanup, I take that as granted. So any change must be in the direction of simplifying it and not adding extra complexity.</div>


</div></div></blockquote><div><br></div></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>I rather go with a model where setting a pending exception and kick unwinding at the transition. It's safer and allow us to use stack/return address patching to make it</div>


<div>efficient - transition must be as fast as possible since it's quite frequent.</div></div></blockquote><div><br></div></div><div>No problem - emit_thread_interrupt_checkpoint emits a call to mono_thread_interruption_checkpoint, which calls mono_thread_interruption_checkpoint_request.  This checks the thread->interruption flag.  I'll use this flag to indicate there is a general pending exception (in addition to its existing purpose of indicating there is a pending Abort/Suspend/Interrupt).  So there will be no performance impact there.</div>
<div class="im">

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>It would be very nice if you're willing to do this work and post it on a public branch so we can later merge it. This can't be merged in the next couple month as we're stabilizing trunk to get ready for 2.12, but I doubt it will be ready in a shorter time than this.</div>


</div></blockquote><div><br></div></div><div>I'm stuck working on the 2.10.2 branch for now.  I would be happy to post a patch.</div><div><br></div><div></div></div></blockquote></div><br><div>Nice, keep us posted.</div>