Very cool. We could use this in Jython to support the greenlet model, which would also allow us to implement Stackless Python. Given this, I'm principally interested in the capability of a given coroutine being able to yield to another specified coroutine, as well as being able to describe tree relationships of coroutines (a child's exception should go to its parent). Naively, it would seem like this would be doable through the subclassing you describe.
Re being tied to a thread: Standard Python coroutines are not restricted to being run in one thread, however, they cannot be nested either. They are also reasonably performant now, and could be readily made more inline-able with some more engineering. In contrast, the existing implementation of greenlets does require being tied to a thread. If relaxing this in your new work imposes greater overhead, it's probably not worth doing. - Jim On Thu, Nov 12, 2009 at 10:08 AM, Lukas Stadler <[email protected]>wrote: > Hi everybody! > > I've just checked in the first prototype of a coroutine implementation. > It's implemented using the continuations framework, so it's not very > speedy (~1µs per context switch in a simple example) but it allows me to > experiment on how the API for coroutines could look like. > This is how it currently works: > > public class CoroutineTest extends Coroutine { > public CoroutineTest(CoroutineContext context) { > super(context); > } > > public static void main(String[] args) { > CoroutineContext context = new CoroutineContext(); > new CoroutineTest(context); > new CoroutineTest(context); > context.start(null); > } > > @Continuable > protected Object run(Object value) { > for (int i = 0; i < 10; i++) { > System.out.println(i); > yield(null); > } > return null; > } > } > > The Coroutine class is very similar to the thread class, it can either > be subclassed or provided with a CoRunnable object. > The main concept is that every coroutine is associated with a > CoroutineContext when it is created. The coroutines will start to > execute as soon as CoroutineContext.start is called and this method will > not return unless all coroutines have finished. The coroutines are kept > in a doubly-linked ring and the default scheduling (which can be changed > by subclassing CoroutineContext) always just yields to the next > coroutine in the ring. > The main drawback of using a coroutine context in this way is of course > that coroutines are tied to a specific thread - is this a problem? A > notion of "moving" a coroutine from one context (and thread) to another > could be introduced, but a coroutine will always need to be associated > with a context so that we can make sure it will end properly. > I'd be glad to hear what you guys think of this! > > cheers > Lukas > _______________________________________________ > mlvm-dev mailing list > [email protected] > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Jim Baker [email protected]
_______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
