Continuations before Fibers

[Ron Pressler]

Do you have a use case and an example where setScheduler would be
beneficial and easier than a custom scheduler?

Also, in general, the goal is not to restrict certain capabilities but provide
a minimal set that will be useful. Secondary needs can always be addressed
later, once we understand real-world usage better. But if you have a
compelling use-case now, I’d be happy to see it.

Serialization is, indeed, an orthogonal concern, and something we wish
and plan to do, but isn’t a top priority at the moment.

- Ron


On 8 March 2020 at 17:27:49, Alen Vrečko (alen.vrecko at gmail.com) wrote:

The thought of having a delegating scheduler did cross my mind. But it would be very awkward code. With unpark(vt, pool)/setScheduler the code is much simpler.

I just don't see why you would artificially limit the capabilities of VThreads. Being able to set scheduler is also orthogonal to serialization.

If I serialize a VThread and send it to another server. I'd expect to be able to pair it with another scheduler and resume it.

I tried to serialize a Continuation and got not implemented. While not my use case. I imagine you will implement this in the future.

Alen

V V ned., 8. mar. 2020 ob 16:20 je oseba Ron Pressler <ron.pressler at oracle.com> napisala:
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