>if a continuation gets into an infinite loop, we can ask it to preempt itself, and forcefully remove it from the CPU.
This is interesting, any idea of how they can do it?
Why Continuations Are Coming to Java
51–60 of 185 posts
Re: Why Continuations Are Coming to Java
#52Ron Pressler!? Isn't that our very own 'pron'?
Re: Why Continuations Are Coming to Java
#53Here's a decent video with some code included: https://www.youtube.com/watch?v=vbGbXUjlRyQ.
The intro music's a little weird for a dev con.
Re: Why Continuations Are Coming to Java
#54What is called continuations in Java is available as "coroutines" in Kotlin, today. Both terms means more or less the same, from a programmers point of view, actually Continuations are part of Kotlins coroutines. https://kotlinlang.org/docs/reference/coroutines-overview.ht...
Interesting that, AFAIK, computer science considers continuations a more generic mechanism than coroutines. Continuations allow continuation-passing style, creating from scratch other control flow mechanisms (like return from a subroutine), exceptions and coroutines (and maybe something else which can't be reduced to items from this list, I'm not sure). Wonder if all of that can be done with coroutines?
Continuations can be reused many times. With delimited continuations you capture the continuation as a function that works basically like any other function. With unlimited continuation you capture the continuation as a weird function that never returns but can still be kept as a closure-like thing and called repeatedly. The classic use of multiple continuation calls is “logic programming” or “nondeterminism” where for example you say “let x = choose [1,2,3]” and choose then arranges to have the continuation called three times (perhaps even concurrently).
Re: Why Continuations Are Coming to Java
#55> I serve as a technical lead for Project Loon. That is the project that's intended to add continuations and fibers to the JDK. > However, actually, Project Loom, the goal of the project is to add continuations, fibers, and tail call elimination. I'm guessing that the project is called either Loom or Loon (and i believe it's the former), but i like the idea that there are actually two cooperating projects, each of wh…
It's probably Loom. It's thematically connected to "fibers" and doesn't make the immediate statement that you think your own project is doomed. Neither of those is true of Loon.
Doesn't seem to have slowed the Canadians down much:
Re: Why Continuations Are Coming to Java
#56Earlier quoted context omitted.
Assembly and C have plenty of magic to go around, don't worry.
C yes, assembly--where? Its mapping to machine code is relatively straightforward, and as is the mapping from machine code to ELF. Or do you mean all the magic the CPU does to make it go fast?
Yeah, in the best case.
In the worst case it is more like this: https://news.ycombinator.com/item?id=5261598 which is pretty magic.
Re: Why Continuations Are Coming to Java
#57Ron Pressler!? Isn't that our very own 'pron'?
You should see him go on /r/java!
I'm kidding, his posts are awesome :)
Re: Why Continuations Are Coming to Java
#58What is called continuations in Java is available as "coroutines" in Kotlin, today. Both terms means more or less the same, from a programmers point of view, actually Continuations are part of Kotlins coroutines. https://kotlinlang.org/docs/reference/coroutines-overview.ht...
While continuations and coroutines are often used interchangeably (continuations are usually one-shot delimited continuations), Loom's continuations are very different from Kotlin's coroutines, which are more similar to C#'s async/await (they are stackless), while the fibers built on top of Loom continuations are more like Erlang's processes or Go's goroutines.
The difference is very big from the programmer's perspective. Kotlin's coroutines are a syntactic concept; i.e. a piece of code is either a subroutine or a coroutine, and you can use one or the other in different syntactic contexts. Loom's continuations, however, are a purely dynamic construct, like a thread. You can run any piece of code inside a continuation. The implication is that no language change is required for continuations and the fibers that are based on them -- they are just a different implementation of threads -- and no API changes. In fact, even though this talk provides some background, developers don't need to learn about continuations at all to use them. All they need to know is that they can use a light-weight implementation of threads.
Re: Why Continuations Are Coming to Java
#59The question is not why, but when. When?
Our server has long waiting http handlers, which occupy java threads while waiting, thus limiting the server throughput to the number of threads java can maintain, and I'm holding off a rewrite on async servlets for several years already to avoid complicating the code, because I hope cheap threads (fibers) will become available, but there is no timeline for Loom. When can we hope it will be released?
Re: Why Continuations Are Coming to Java
#60So it’s like python’s yield statement aka generators?
It's more general than generators. You can create generators using it, and also other control flow constructs.
Yup, I did exactly that in Scheme