Continuations before Fibers
Alen Vrečko
alen.vrecko at gmail.com
Sat Mar 7 15:34:01 UTC 2020
Awesome work. I really like where you are going with Loom.
I got off on the wrong foot with expecting to see Fiber class. Not seeing
it I just went with Continuation. Having played now with both VThread and
Continuation. I find working with VThread much more natural. Now I don't
see any reason to use Continuation directly except for:
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?
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();
in the app code I'd prefer to see VirtualThread over Thread. Just like I
prefer to see ArrayList, LinkedList, ImmutableList etc over just List in my
code. Gives me a better understanding of the underlying characteristics of
the data structure and avoid any surprises.
Thank you for your time
Alen
V V pet., 6. mar. 2020 ob 08:43 je oseba Alan Bateman <
Alan.Bateman at oracle.com> napisala:
>
> On 06/03/2020 07:24, Alen Vrečko wrote:
> > :
> >
> > For disk IO. How do you intend to do it? Io_uring?
> Yes, eventually, once it is available in all the main stream
> distributions. In the mean time it works with FJ managed blocker support
> to extend the parallelism for the duration of file I/O operations.
>
> -Alan.
More information about the loom-dev
mailing list