Temporal coupling in Fibers and Fibers vs State Machines.

[Alan Bateman]

On 24/02/2020 20:52, Cay Horstmann wrote:
> Hi Ron,
>
> when I teach or write about concurrent programming, it seems to me 
> that programmers tend to be confused about threads and tasks. I try to 
> tell them to focus on tasks. Threads and fibers/virtual threads are 
> just a mechanism to run tasks. Most programmers should just defer to 
> some machinery that maps tasks to whatever is required to run them. 
> With fibers/virtual threads, the situation is much brighter than 
> before--one can now map lots of tasks that block a lot.
>
> So, my point is that I am long past "blocking is cheap". It's 
> marvelous that Loom makes it so, and I appreciate that this is quite a 
> feat of engineering.
>
> My hope is that Loom will provide an API for running those tasks in a 
> way that makes sense to application developers. The classic thread API 
> is not exactly developer friendly, and that's what people see now when 
> they investigate Loom.
>
> Perhaps ExecutorService.invokeAll and ExecutorService.invokeAny, when 
> used with fibers, could be sufficient for structured concurrency. But 
> it appears to be an awkward API.
>
> A few iterations ago, you had a more compelling API, and I look 
> forward to seeing more work on that.
>
> There will always be the state machine enthusiasts, but if Loom could 
> nail the equivalent of invokeAll and invokeAny, with cancellations, 
> durations/timeouts, and resource cleanup, that would take care of a 
> lot of use cases.
I assume you are mean the FiberScope prototype that we had last year. 
Here's roughly the same with ExecutorService in the current prototype:

         ThreadFactory factory = Thread.builder().virtual().factory();
         Instant deadline = Instant.now().plusSeconds(20);
         try (var executor = 
Executors.newUnboundedExecutor(factory).withDeadline(deadline)) {
             :
             result = executor.invokeAny(tasks);
         }

invokeAny isn't too bad here as it will cancel any tasks that haven't 
completed when there is result. We hope to have prototypes soon that 
improve on this, also better integration with completable futures and 
streams. So yes, your point that the API surface looks a bit bare if you 
only look at the Thread API. Most of the effort on this project to date 
has been on the foundation work.

-Alan