Changes to JEP 453

[Alan Bateman]

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

-Alan