Changes to JEP 453

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Alan Bateman" <Alan.Bateman at oracle.com>
> To: "attila kelemen85" <attila.kelemen85 at gmail.com>, "Remi Forax" <forax at univ-mlv.fr>
> Cc: "loom-dev" <loom-dev at openjdk.org>
> Sent: Friday, May 19, 2023 9:02:07 PM
> Subject: Re: Changes to JEP 453

> On 19/05/2023 19:14, Attila Kelemen wrote:
>>> In the JEP, the state CANCELLED has disappeared from the possible state of
>>> Subtask ?
>>> I'm puzzled by this change.
>>>
>> I'm puzzled that you are puzzled :) Because you said: "I propose to
>> simplify the design and remove the state CANCELLED". With which I
>> wholeheartedly agree.

My idea was to remove the state CANCELLED when you read the state from inside handleComplete() not from outside.

>>
>> In my opinion, this is a much cleaner design, because it leaves more
>> options for the STS policy to decide what is actually meant by being
>> cancelled. Also, conceptually simpler, because now the state of
>> `Subtask` represents what is actually happening rather than what was
>> wished from it (by a shutdown call. Also, it is of little concern to
>> the client of STS, because it shouldn't really based its decision on
>> that (since that decision should be centralized in the STS policy).
> 
> The change proposed in JEP 453 is moving from Future to Subtask. Subtask
> does not define a cancel method, one reason for a cancelled state goes away.
> 
> A second part to this is what happens when you call shutdown to
> short-circuit. With the JDK 19/20 API, shutdown effectively cancelled
> all unfinished subtasks so that Future::isCancelled returned true. It
> didn't storm the handleComplete method with the cancelled Futures as
> that wasn't too useful. With the updated API, Subtask::task reflects the
> state of the forked subtask, not the handle. If there are unfinished
> subtasks then they are interrupted (as before) and their terminal state
> will depend on how they react to the interrupt.
> 
> The final case is forking when shutdown (at around the time that the
> task scope is shutdown). The JDK 19/20 API returned a cancelled Future,
> the updated API returns a Subtask in a "NOT_RUN" state. Same semantics,
> just a different state name.

Okay, I think i understand the proposed change.

The semantics for the JDK 19/20 has the invariant that after a call to join() the state of a Future was stable, i.e. it will never change later.

Here you are breaking that invariant because a subtask with the state NOT_RUN will transition to either SUCCESS or FAILED depending how the subtask callable finished after the call to join().

So I've the follow up questions:
- do we agree that handleComplete() can only be called with a task in state SUCCESS or FAILED, never with a task in state RUNNING or NOT_RUN ? 
- If a STS is used (but not a ShutdownOnXX), after a join(), a task state can return NOT_RUN. As a user how am i suppose to handle that case ? Do a busy loop to wait ?
- If a STS is used (but not a ShutdownOnXX), do you have considered to make join() synchronous to keep the invariant (stable state after join()) ?

> 
> -Alan

Rémi