6 ms·

Pretty disappointed that continuations won't be able to yield a value(s). That was one of the most powerful things about Lua's coroutines. Back in games we'd u

Pretty disappointed that continuations won't be able to yield a value(s). That was one of the most powerful things about Lua's coroutines. Back in games we'd use the yield value as the number of frames to skip before rescheduling giving a really nice coarse grained control over coroutine execution. It also opens up lazy sequences and all sort of other really useful things.

tomp 9y ago
Are you sure? One of their examples includes code like this: produce 1 fiber sleep 100ms suggesting that at least they're aware of its usefulness. In any case, it's pretty easy to simulate that with a bit of mutable private state.
- pron 9y ago
  That's correct (I wrote the proposal). There will be two-way communication between the entry (reset) and yield (shift) site, but this may be implemented in Java in the JDK libraries on top of a lower-level construct in the JVM, if not in the JVM itself.
  - tomp 9y ago
    You wrote the proposal? Amazing! Any clue when it might get implemented, or how might I experiment with it before it's part of the official HotSpot release? I think fibers would really bring JVM to the next level...
    - pron 9y ago
      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).
      - tomp 9y ago
        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 avoid this, i.e. to have it taken care of automagically by JVM.
        pron 9y ago
        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.

tomp 9y ago

Are you sure? One of their examples includes code like this: produce 1 fiber sleep 100ms suggesting that at least they're aware of its usefulness. In any case, it's pretty easy to simulate that with a bit of mutable private state.

pron 9y ago
That's correct (I wrote the proposal). There will be two-way communication between the entry (reset) and yield (shift) site, but this may be implemented in Java in the JDK libraries on top of a lower-level construct in the JVM, if not in the JVM itself.
- tomp 9y ago
  You wrote the proposal? Amazing! Any clue when it might get implemented, or how might I experiment with it before it's part of the official HotSpot release? I think fibers would really bring JVM to the next level...
  - pron 9y ago
    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).
    - tomp 9y ago
      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 avoid this, i.e. to have it taken care of automagically by JVM.
      - pron 9y ago
        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.