Changes to JEP 453

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Alan Bateman" <Alan.Bateman at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "loom-dev" <loom-dev at openjdk.org>
> Sent: Saturday, May 20, 2023 10:57:31 AM
> Subject: Re: Changes to JEP 453

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

The interface Subtask is used differently inside handleComplete() and outside handleComplete().

                     inside handleComplete()         | outside handleComplete()
   state()  RUNNING, SUCCESS, FAILED, NOT_RUN        | SUCESS, FAILED

   get()    ISE thrown should wrap failure exception | ISE thrown should not wrap

   exception() yes                                   | No, should not be called

and i've no idea when using task().

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

ok, thanks, i think i'm starting to slowly understand how it works.

i was thinking that the transitions
  NOT_RUN -> SUCCESS,
  NOT_RUN -> FAILED
were possible.

So NOT_RUN is when a task was not run *and* never will.

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

To me, reporting the state of the task instead of the state of the handle is a better API from the user POV.
So it's going in the right direction :)

> 
> -Alan.

Rémi