FiberScope

[Alan Bateman]

Thanks for going this area, it's an area that is work in progress and 
doesn't have any write-up yet.

On 03/02/2019 12:35, Remi Forax wrote:
> :
>
> 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.
We are exploring the concepts with fibers for now so I think TBD on 
whether it would be generalization to allow for threads too.


>
> ---
>
> 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.
The mix is temporary until we decide if the Fiber.schedule methods 
should be removed. So assuming they are removed then it will always be 
explicit, the temporary DETACHED default goes away (there's a naming 
discussion in there too, this is the reason why it doesn't have a method 
yet).

I'm not sure that I understand your last sentence. Fibers executing in a 
non cancellable scope execute in that they scope, they aren't registered 
in any (enclosing) cancellable scope.

>
> 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 ?).
>
TBD on paramatrization and the right way to expose the termination 
queue. Some the prototypes use builders to avoid exploding the number of 
methods that enter a scope. I'm sure there will be several iterations 
before it settles down.

The "fibers" method to expose the fibers executing in the scope is 
mostly to support cancellation (as per the examples in the javadoc) but 
you may be right that there may not be other compelling uses.

-Alan