<br><br><div class="gmail_quote">On Wed, Feb 1, 2012 at 12:22 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">
Yes, it's got machine exceptions.  With the help of the MMU, we are able to detect when the stack is down to the last 64K, so there is no need for an alternate stack.  We can call a function from there, somewhat akin to signals.</blockquote>
<div><br></div><div>On which stack and thread is that function called? You obviously can't call it on the overflown one.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>

<br></div><div>The requirements are that:</div><div>- The native code is allowed to continue execution.</div><div>- The managed code throws a StackOverflowException that executes finally blocks.</div><div>- The root AppDomain continues running.<br>


<div><br></div><div>As I understand it, the stack overflow handling in Mono only works on certain OSes and doesn't satisfy all of our requirements.  It also seems that the ThreadAbortException handling satisfies all of these requirements, so that code would be an architecturally appropriate place to handle both.</div>
</div></blockquote><div><br></div><div>Well, the thread abort machinery was devised to handle async exceptions started from a foreign thread. You can definitely use the low level machinery to implement</div><div>stack overflow on your target. I would be willing to merge changes that improve the low level bits and stack overflow handling to enable such a thing, but there's no</div>
<div>reason to butcher the thread abort specific bits just for a quick hack.</div><div><br></div><div>As I told you before, I can't make an informed comment until you give a better picture of how exactly a stack overflow is handled on your RTOS.</div>
<div><br></div><div>Mono OVF code uses soft guard pages to enable native to continue once we reach a soft limit in stack usage so we can safely finish processing and raise a</div><div>managed exception. But once it hits the hard limit while in native code, the only viable option is to abort.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>

<div><br></div><div>The out-of-memory exception is almost the exact same story... When memory gets low, I want to be able to do something that allows native code to continue, but OutOfMemoryException is thrown when execution returns to managed code.  I assume there is no mechanism in there for this?</div>
</div></blockquote><div><br></div><div>OOM is quite a different beast, it's handled synchronously since we know exactly when we're out of managed memory. Mono doesn't handle native allocation failures</div><div>
well and this is something I would love to see patches for. Managed allocation failures are well handled with sgen.</div><div><br></div><div><br></div></div>