[LLVMdev] [RFC] Coroutines

[Toralf Niebuhr]

Am 04.08.2011 um 22:06 schrieb Rafael Ávila de Espíndola:

> On 07/28/2011 05:31 PM, Sanjoy Das wrote:
>> Hi llvmdev!
>> 
>> I've been working on adding coroutines to LLVM. Mentioned below is the
>> implementation plan I'm following, for suggestions, flames and other
>> input. Using segmented stacks is a prerequisite.
> 
> 
> I think my only comment is that, while this would probably work, 
> implementing it in C with a bit of assembly for saving/restoring 
> registers also does.
> 
> What are the benefits of doing it in llvm itself?
Hi,

The benefits are quite simple. 

When you do it with setjmp/longjmp or context (which is deprecated in OS X Lion) your program uses lots of memory because each coroutine need its own stack (I believe for context its 32k per thread).
As ucontext is a kernel call, this uses a lot of time as well. The setjmp/longjmp implementations usually invalidate pointers to objects on other coroutines calling stacks.
Also, the debugging with gdb isn't really nice.
Implementing coroutines with C macros is not really an option either.

Doing everything with llvm would allow the compiler to do everything without stack switching. You could turn each coroutine into a state machine. If a context change occurs, llvm would return from one coroutine to the "llvm scheduler" without unwinding the state machines calling stack (this should be possible because of the usage of segmented stacks). Then it would execute the other coroutine from its current state.
This can also be imagined as splitting each coroutines into small tasks ( the program between two context switches would become one task). And then the "llvm scheduler" would execute a full task and after it is done it executes the next task (the one that the coroutine wanted to switch to).

Also, there are lots of optimization opportunities if llvm knows what a coroutine is. For example, quite often it is possible that you don't need to switch to the other coroutine but can just inline some simple code.


Toralf Niebuhr


(sorry for double post….I used the wrong mail address)