It's pretty easy to simulate that with a bit of mutable private state.
No it's not. User-level threads are currently not supported in Java.
Project Loom: Fibers and Continuations for the Java Virtual Machine
41–43 of 43 posts
Re: Project Loom: Fibers and Continuations for the Java Virtual Machine
#42Earlier quoted context omitted.
Once the voting period is complete, in another week, there will be a mailing list for the project. We'll publish binaries from time to time for people to try. In the meantime, you can play with Quasar, to see if you like the model (although as Loom would be implemented in the JVM, we expect it to be more robust, more efficient and even more convenient).
Yeah, I've considered playing with Quasar, but I'm a bit concerned about the "colored functions" that it imposes. In any case, I'm mainly interested in Fibres as a code generation platform (for some toy languages I'm playing with), and obviously there I could avoid having to use Quasar/bytecode rewriting by simply emitting functions as state machines in the first place... My hope for project Loom is to be able to avo…
Quasar doesn't have colored functions, and you can instrument your code at build time, as part of the compilation process. But an implementation in the JVM is indeed more robust and efficient.
Re: Project Loom: Fibers and Continuations for the Java Virtual Machine
#43There are already many different libraries or approaches to concurrency and parallelism on JVM. - http://www.baeldung.com/java-completablefuture Promises - http://vertx.io/ Event Loop - https://akka.io/ and http://www.paralleluniverse.co/quasar/ Actors - https://projectreactor.io/ and https://github.com/ReactiveX/RxJava Reactive, event-based - https://kotlinlang.org/docs/reference/coroutines.html Kotlin coroutines. S…
My understanding of all these projects is that you have to change your style of coding / have more complex APIs, or they're just syntactic sugar over heavyweight threads. What loom seems to offer is the best of both worlds; going back to writing simpler code (e.g. regular "blocking" io code) while scaling much better.
> have more complex APIs, or they're just syntactic sugar over heavyweight threads.
I am pretty sure that's not the case with Kotlin coroutines :)