coroutine support

[Jim Baker]

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 <lukas.stadler at jku.at>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
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>



-- 
Jim Baker
jbaker at zyasoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091112/f9aa61bd/attachment.html