Hi James,<br><br><div class="gmail_quote">On Wed, Apr 15, 2009 at 4:17 PM, James Mansion <span dir="ltr">&lt;<a href="mailto:james@mansionfamily.plus.com">james@mansionfamily.plus.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Tomi Valkeinen wrote:<br>
&gt; I think you mean OS thread. The coroutines are nothing special, they<br>
&gt; are similar to any other jitted code that mono produces.<br>
</div>Well, except that the core has some knowledge of them now, right?<br>
<div class="im">&gt; And thus the stack has to be the normal continuous OS stack.<br>
</div>Thus?  Why? You probably need to pin stack areas, but why can&#39;t you<br>
malloc (or mmap) some new space<br>
and place a stack in it?  I think you&#39;ll find that Steve Dekorte&#39;s<br>
libcoro does that. If you are prepared to<br>
forgo guard pages and the like (or roll your own handler) then I don&#39;t<br>
see why the stack pointer absolutely<br>
has to be where you expect.  And in fact the gubbins that normally gets<br>
pushed to the main CPU stack<br>
can get pushed to a fully software stack anyway, just as you do on RISC<br>
systems with no push/pop<br>
abstraction.  The stack pointer is just a pointer, after all.<br>
<font color="#888888"><br>
James<br>
</font></blockquote></div><br>Such stackless[1] design is quite more complicated as doing stack attach/detach<br>
isn&#39;t trivial. Spaghetti stacks have their issues that this design avoids.<span id="query" class="query"><br>
</span><br>
The good news is that such change would not require messing with the API, so if this feature<br>
gets enough traction and someone from the community decides to sponsor such optimization<br>
it would be doable without breaking existing users.<br>
<br>[1]stackless in the sense that it doesn&#39;t strictly use the C stack<br><br>