I totally agree as well, naturally :-) And I do plan on spending more time on the coroutine patch again, I didn't do much coding in the last months because I was occupied at university. The result of this is my thesis on coroutines: http://ssw.jku.at/Research/Papers/Stadler11Master/
The coroutines in the current state actually provide full stack reification and can simulate continuations, albeit with suboptimal performance. But this is confined to two concrete methods (serialize/deserialize), and can thus easily be restricted with permissions. I would be really interested to hear what you guys think are the most important characteristics for coroutines... since an implementation is always a tradeoff: * fast creation * fast 1st activation (the first time a coroutine gets to run) * fast switching * fast migration from thread to thread * many coroutines (~100) * lots of coroutines (~ 10000) * lots and lots of coroutines (~ 1000000) I'll soon fork of a version that only supports lots of coroutines, because this makes a lot of things much easier (it doesn't require the whole copy to/from stack logic). And I also think that a jsr as a rallying point would help a lot - I'll see what it will take to create one. cheers, Lukas Am 2011-04-27 20:33, schrieb Charles Oliver Nutter: > I think it's time to start talking about what we'd need to do to get > coroutines in Java 8. > > In the absence of forking, lightweight processes, or M:N threading, > there's no efficient way to implement a large set of problems that > demand fiber/coroutine-like behavior. Add to that the fact that > languages like Ruby and Erlang already want for "fibers", and in JRuby > and Erjang we have to hack around the JVM to support them. > > With the narrowing of Lucas's patch to downstream coroutines (rather > than unbounded continuations) I believe most of the concerns about > security have been addressed. Or at least, enough of those concerns > have been addressed that we need to get this patch in front of more > people to find new concerns. > > So, I guess what's needed would be at least a JSR, which then needs > someone to lead it (I don't think we'd have much trouble getting > people to participate). > > Any thoughts on trying to push coro through to Java 8 as an official > feature? I'm convinced it needs to happen. > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
