Structured Concurrency yet again

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Alan Bateman" <Alan.Bateman at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "loom-dev" <loom-dev at openjdk.java.net>
> Sent: Tuesday, May 9, 2023 7:27:23 PM
> Subject: Re: Structured Concurrency yet again

> On 09/05/2023 17:33, Remi Forax wrote:
>> I think we should restart the work on the structured concurrency API
> There is updated JEP for the SC API [1] that we hope will become a
> candidate soon.


It is interesting to note that we seem to agree that fork() should not return a Future. I can identify two logical consequences.

Firstly, as mentioned in the JEP, get() or state() should only be called after joinAll(). Calling task.state() on a running computation would throw an IllegalStateException, making State.RUNNING unnecessary. Furthermore, when scope.shutdown() is invoked, a cancelled task can be in state FAILED or CANCELLED, as explained in the documentation, which is a pain to deal with as a user. I propose to simplify the design and remove the state CANCELLED (perhaps making it a sub-state of FAILED with a method isCancelled() if we want to keep it). This way, users will have only to deal with two states SUCCESS or FAILED. It is worth noting that existing reactive APIs do not differentiate between CANCELLED and FAILED too.

The second consequence concerns the TaskHandle.exception() method. It should not return a Throwable, since Callable throws an Exception and storing an Error in a field is not a good practice. Exception handling is a significant concern in Java, and we have the opportunity to provide a transparent way to address it without being constrained by the design of Future. A TaskHandle can be parameterized by both the result type and the exception type. When calling get(), exceptions are transparently re-spawned. However, this means that TaskHandle cannot be a Supplier.

Then I prefer to use a Stream to deal with the different semantics of a scope instead of asking to subclass it and hoping that users will correctly manage the concurrency when overriding handleComplete().

> 
> -Alan.
> 
> [1] https://openjdk.org/jeps/8306641

regards,
Rémi