FiberScope

[Remi Forax]

I've taken a look to the FiberScope API/implementation.

The idea of structured concurrency is a nice idea, use program control flow as a way to define/make explicit fiber/thread interactions.

Let's review the control API, we have for threads first,
The first control API introduce in Java 1.0 is ThreadGroup.
ThreadGroup provides bulk cancellation (via interrupt()) but do not provide bulk completion (no join()).

We also have the executor API of java.util.concurrent, which also manage threads,
providing via the interface ExecutorService, invokeAll(), invokeAny(), awaitTermination(), and more generally submit()
and more recently with CompletableFuture, we have the way to define operations between the computation.

So in my opinion, the FiberScope API as nothing to do with fibers per se, it's about computations, so it should work on a CompletableFuture or a WhateverFuture using an Executor (that schedule computations) backed by a ThreadPool or a FiberPool.

---

In term of semantics,
in the article of Nathaniel J. Smith, the nursery is used explicily with no magic to schedule a computation.
in the article of Roman Elizarov about structured concurrency, he's using the implicit context of kotlin, so there is magic but it's lexically scoped,
in the current semantics of the FiberScope API is weird, it's a mix between explicit calls and dynamic scoping. When you create a fiber it's DETACHED by default so not associated to the dynamic FiberScope but cancellation of the owner (the fiber) of the FiberScope, it cancels all the fibers inside the fiber scope which is clearly a dynamic relation (using current thread -> fiber -> fiber scopeto). You can see the same issue with FiberScope.notCancellable(), given that you subscribe to a fiber scope explicitly, you don't need it, a fiber that doesn't need to be cancelled should just not be registered in the cancellable fiber scope.

---

FiberScope should be an interface, it's not even an abstract class that why you have methods that returns a runtime exception.  
FiberScope.DETACHED should be only avaiablable through a static method, it's far easier to maintain/evolve a static method compared to a static field.

---

Given that the FiberScope API is about computation, it's should be parameterized by the type of the computed values, this will solved the issue of the type of the termination queue.
Having or not a Termination queue should be done using interface from the user POV, FiberScope.provideATerminationQueue returns an interface FiberScope.WithTerminationQueue that inherits from FiberScope
(in term of implementation, obviously it can be the same class that implements both).
And i'm not sure that a FiberScope should expose the Fiber created the same way an Executor doesn't expose its worker threads (but i may be wrong ?).


regards,
Rémi