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 <[email protected]> > 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 >
_______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
