Changes to JEP 453

[Alan Bateman]

On 19/05/2023 20:51, forax at univ-mlv.fr wrote:
> :
> My idea was to remove the state CANCELLED when you read the state from inside handleComplete() not from outside.
I'm not sure that I understand this, it sounds like you are proposing 
there should be different views of the state, is that right?

The intention with this API is that shutdown means you are done, the 
results from the unfinished subtasks is not interesting so cancel and 
get me out of here! Cancel means the unfinished subtasks are interrupted 
of course. Whether they complete with a result or fail will depend on 
timing and how they react to interrupt. It doesn't matter to the policy 
or the processing of results after join as that consumes the outcome of 
the subtasks that completed before the shutdown.  The close method has 
to block waiting for the stragglers so the only interesting thing may be 
diagnosability when stragglers are slow to finish. I don't quite see how 
having different views of the state help this but I may not understand 
what you are suggesting.

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

The state transitions we had with Future were:

RUNNING -> SUCCESS
RUNNING -> FAILED
RUNNING -> CANCELLED
CANCELLED

With Subtask right now it is:

RUNNING -> SUCCESS
RUNNING -> FAILED
NOT_RUN

so three terminal states as before.

The outcome of unfinished subtasks after shutdown isn't interesting when 
using the API as intended. This means their state isn't going to 
examined, except maybe for troubleshooting purposes. If we've created an 
attractive nuisance then we can of course revert to reporting the state 
of the handle, which amounts to not revealing the internal state of the 
stragglers in the time between shutdown and when they finally finish.


> 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 ?
handleComplete is only called for subtasks in the terminal state. It's a 
coin toss as to whether it's interesting to invoke handleComplete for 
the NOT_RUN case but having handleComplete called for every fork is not 
an unreachable property to have.

-Alan.