I'm not specifically interested in the abort machinery, but looks like it's in a good position to handle low of mem/stack.  Our RTOS also doesn't support signals at all.  Are there better places to handle and recover from low mem/stack?<div>

<br></div><div>- Kipp<br><div><br><div class="gmail_quote">On Tue, Jan 31, 2012 at 9:16 AM, Rodrigo Kumpera <span dir="ltr"><<a href="mailto:kumpera@gmail.com">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">

Mono already handles that in the case of stack overflow by using sigaltstack. Why do you want the abort machinery to raise anything but their<div>related abort exceptions? <br><div><div><br><div class="gmail_quote"><div>
<div class="h5">
On Mon, Jan 30, 2012 at 5:08 PM, Miguel Mudge <span dir="ltr"><<a href="mailto:michael.mudge@welchallyn.com" target="_blank">michael.mudge@welchallyn.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">We've got a single-process RTOS running Mono and we've started to tackle what happens when a stack overflow or out of memory condition occurs.<div>


<br></div><div>We're using an AppDomain to load and unload a variety of apps that come off the external flash drive.  When things go very wrong [StackOverflow or OutOfMemory], we terminate Mono entirely so the rest of the device can continue doing its job.</div>




<div><br></div><div>We'd like to be able to more gracefully handle StackOverflow, OutOfMemory so that finally clauses execute and the root AppDomain can continue running.  As I understand it, mono_throw_exception() throws immediately, but since stack/memory runs out unexpectedly, it's best if we have some spare memory/stack so the native code can finish what it was doing before managed exception handling starts cleaning up the mess.  So - we're looking for behavior closer to ThreadAbortException.</div>




<div><br></div><div>I see that in threads.c/mono_thread_execute_interruption(), thread->interruption_requested indicates that the ThreadAbortException should be thrown at the native->managed transition [among maybe some other actions].  I'm proposing that gets changed [or amended] to throw an arbitrary exception, both for future use and for our specific case.  Native code such as signal handlers would be able to cause an exception to be thrown only after execution returns to managed.  Our goal is to have several MB of guard pages (in spare memory and on the stack) available to handle the unwind.</div>




<div><br></div><div>Comments?  Am I on the right track here?  Any forseen gotchas?</div><div><br></div><div>- Kipp</div><div><br></div>
<br></div></div>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>