coroutine support

[Jin Mingjian]

great news:) I've done some similar helloworld coroutine tests using
Javaflow several months ago. It seems that the scheduling time unit of
native thread is in the level of ms(although I am not very sure this^_^)


2009/11/13 Lukas Stadler <lukas.stadler at jku.at>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091113/3f3c1e39/attachment-0001.html