FiberScope

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "loom-dev" <loom-dev at openjdk.java.net>
> Envoyé: Dimanche 3 Février 2019 15:35:11
> Objet: Re: FiberScope

> 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).

ok

> 
> 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.

you can have only one kind of scope and if you want a fiber no to be cancelled, you register it in another 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.


method cancel on FiberScope will avoid to expose the fibers, but it depends if people inherits from fibers or not.

> 
> -Alan

Rémi