Continuations before Fibers

[Alen Vrečko]

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