Continuations before Fibers

[Ron Pressler]

You can control the carrier thread choice (or thread-pool choice) by writing
your own scheduler. Every time a virtual thread becomes runnable (i.e. when
started or when unparked), its continuation is submitted as a task to the 
scheduler. Just run it on whatever (non-virtual) thread you like (e.g. you can
write and Executor that chooses and delegates to multiple thread pools).

So dynamically setting the scheduler and just writing a custom scheduler
are equivalent with one difference: currently the scheduler cannot know
which virtual thread the submitted task corresponds to. Seeing that custom 
scheduling is a very advanced usage, I see no reason to expose a public setter 
for the scheduler, especially as the same effect can be achieved without it. 
Whether we’ll add a mechanism to determine the virtual-thread from the task 
is TBD.


- Ron


On 8 March 2020 at 11:56:40, Alen Vrečko (alen.vrecko at gmail.com) wrote:

I saw the virtual(Executor) method. I just don't see how it helps in my  
case.  

I'd like for my VThread to be first run on one thread pool, park it, then  
unpark it and run it on another thread pool.  

With Continuations I can do this. With VThread I don't see how. Except if I  
use reflection to change the scheduler field.  

From:  

https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html  

There are a few capabilities unique to fibers: we want a fiber to be  
scheduled by a pluggable scheduler (either fixed at the fiber's  
construction, or changeable when it is paused, e.g. with an unpark method  
that takes a scheduler as a parameter), and we'd like fibers to be  
serializable (discussed in a separate section).  

Did you change your views on this?  

I'd really like to see something like LockSupport.unpark(virtualThread,  
newScheduler) or setScheduler or both.  

Alen  

V V sob., 7. mar. 2020 ob 17:28 je oseba Alan Bateman <  
Alan.Bateman at oracle.com> napisala:  
>  
> On 07/03/2020 15:34, Alen Vrečko wrote:  
> > :  
> >  
> > I'd still like to be able to have control over scheduling. I think a  
> > simple API addition such as:  
> >  
> > // able to do this while the VThread already did some work but is not  
> > yet finished  
> > VirtualThread.setScheduler(vt, useThisSchedulerInstread);  
> > virtualThread.get/setScheduler.  
> >  
> > Would do the trick. You are probably rolling your eyes. But looking at  
> > the code it doesn't look like a big deal to add API like this. If it  
> > would make it easier, could allow for change of scheduler only from  
> > within the executing VThread?  
> Maybe not easy to find either but Thread.Builder has a virtual(Executor)  
> method so you can specify your own scheduler for the advanced cases that  
> need it.  
>  
> >  
> > Another note. I think it would make sense to make VirtualThread class  
> > public. I find something like:  
> >  
> > vt = new VirtualThread(myRunnable);  
> > vt.start();  
> >  
> > more natural than Thread.builder().virtual().task(myRunnable).start();  
> We've trying to avoid exposing a sub-type in the API at this time. We do  
> need to improve the factory methods, that work stalled a bit due to  
> legacy ThreadGroup. For now you can do this:  
> var thread = Thread.newThread(Thread.VIRTUAL, task);  
> but expect it to change once there is something better.  
>  
> -Alan