Continuations before Fibers

[Alen Vrečko]

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
>
>