Continuations before Fibers

[Ron Pressler]

Hi.

How is this use case not even *better* with virtual threads? Seems to me 
that it will require less code (as the necessary scheduling is already in the JDK),
and will be able to run more Java code as it won’t break certain invariants such
as the identity of the current thread remaining the same for the duration of a
method.

I *think* that every use case of continuations that depends on switching threads
is better served by virtual threads. The only time I would consider using another
continuation-based construct is for constructs that are essentially single threaded,
e.g. generators. Am I missing something?

For that reason — virtual threads are easier, less error-prone, and better integrated 
with the JDK — I don’t see us releasing continuations before virtual threads, or even
making continuations public in the first release of virtual threads. Unless, of course,
some very compelling use case arises. Do you think your use case benefits more 
from continuations than from threads? If so, why?

BTW, in your case, as in the implementation of virtual thread, a single static final
continuation scope seems sufficient.

Ron


On 5 March 2020 at 18:53:23, Alen Vrečko (alen.vrecko at gmail.com) wrote:

Hello, everyone.  

On your website you have this:  

Continuations are intended as a low-level API, that application authors are  
not intended to use directly. They will use higher-level constructs built  
on top of continuations, such as fibers or generators.  

I took the current EA build for a spin. There is support for Continuations.  
It solves my use case.  

I've put an example of how I'd use continuations here:  

https://gist.github.com/avrecko/a706484e6d7f4963af75a042006f8a4a  

Basically using Continuations with a SEDA style application. The current EA  
build implementation looks like it works as expected and solves my use case.  

Is this something you would _not_ like the users to do? I can see myself  
using this kind of approach in production very easily without drastic  
changes to the existing code base and without much surprises.  

Briefly looking at the code of Continuation. It looks thread safe. So there  
shouldn't be problems from passing it around and being executing in part  
from different threads.  

I do find the Scope argument a bit annoying. I think you could provide an  
implicit default scope. So unless explicitly specified an implicit -  
default scope is assumed.  

In my view you should consider releasing Continuations before Fibers and  
making Continuations part of public api to be used by developers.  

I find the current API pretty intuitive to use. Minus the scopes. I like  
that #run() is final and that Continuation takes Runnable. Makes sense to  
me.  

Best regards  
Alen