Hi Dimitris,<div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"></div>I am aware of these techniques - this is how I worked around the problem.<br>

Make a separate (mmap allocated) frame for the C stack, and trampoline<br>through a scheme procedure that handles the i/o pumping and then ffi<br>re-enters.<br>It is not generally portable (some assembly  --<br>setjmp/longjmp/getcontext/setcontext can't return pointer-sized values<br>

and don't provide any usable mechanism for storing the context for<br>multiple threads, and there is also the issue of redzoning the stack<br>to catch overflows), but it works for now.<br></blockquote><div><br></div>
Neat! Are you aware of any good example code for this anywhere?</div>
<div><br><div class="gmail_quote">2013/2/25 Dimitris Vyzovitis <span dir="ltr"><<a href="mailto:vyzo@hackzen.org" target="_blank">vyzo@hackzen.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Sun, Feb 24, 2013 at 2:25 PM, Patrick Li <<a href="mailto:patrickli.2001@gmail.com">patrickli.2001@gmail.com</a>> wrote:<br>
> I am writing a compiler for a coroutine-based language and have the<br>
> exact same limitation with regards to the FFI.<br>
><br>
> I am curious, Dimitris, whether you know of any other language with<br>
> first-class coroutines or coroutines that have your desired feature. I<br>
> myself do not. Perhaps it's still an open research problem.<br>
><br>
<br>
</div>I am not aware of any strictly coroutine-based solution, but it is not<br>
such a severe limitation if you are maintaining separate stacks for<br>
each thread.<br>
<br>
The main problem there is dealing with stack growth, since C stacks<br>
are not generally movable -- if your allocated stack is too small you<br>
will overflow and if your stack is too large you are wasting too much<br>
memory.  Still, the kernel doesn't back it by physical memory until it<br>
gets used, so you can jumbo-size them with the real limitation being<br>
your address space size (not too big of an issue in 64bit<br>
architectures).<br>
<br>
It is also possible in some situations to grow the stacks as needed.<br>
When allocating with MAP_GROWSDOWN, the kernel may leave some space<br>
for growth, so when you catch the segfault in the redzone you can<br>
remap it. But it is not guaranteed how much room you will have (if<br>
any), and the address space quickly gets tight in 32bit.<br>
<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Perhaps the best way around it is to use segmented (split) stacks.<br>
With recent gcc you can get compiler support at C-level (still not<br>
trivial to integrate with your language kernel, but doable). You may<br>
have to compile your entire C-library with segmented stack support for<br>
this to work transparently however.<br>
<br>
You can also try to implement dynamic segmented stacks by stepping at<br>
your redzone handler until you catch a call instruction, at which<br>
point you can make a new stack and stitch the execution contexts. Not<br>
exactly a walk in the park though.<br>
<br>
-- vyzo<br>
</blockquote></div><br></div><div>Same here - are you aware of particularly good documentation or use examples on it?</div><div><br>Regards,</div><div>Mikael</div><div><br></div>