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