Subtask states

[Alan Bateman]

On 26/09/2025 18:41, Remi Forax wrote:
> Currently,
> the interface Subtask defines 3 different states, but while the implementation needs 3 states, I believe the interface only need 2.
>
> Currently, having 3 states punished people that are using the API correctly, i.e accessing the state when all the computations are done,
> after join() is called, because for them, only two states are visible, but they still need to write a code that takes can of the state
> UNINITIALIZED.
>
> I propose that state() can only return SUCCESS or FAILURE and throw an ISE if the internal state is UNINITIALIZED given it means
> that the API is not used correctly.
>
> In the past, with the previous iteration of the design using inheritance instead of delegation, the Subtask was not sealed,
> so the internal state had to be exposed, but now that only the implementation of STS can create a Subtask, the internal state UNINITIALIZED does not have to be visible.
>
Subtask has always been sealed. It has always had 3 states, nothing has 
changed, and nothing from the implementation has leaked into the API. So 
I'm a bit puzzled by your message. There is no outcome to report when a 
subtask is executing, was cancelled, or was forked after the scope was 
cancelled. The Subtask::state returns "UNAVAILABLE" for all these cases. 
It's easy to come up with examples where join returns a stream of 
subtasks in each of these states.

Is your gripe with the onComplete method when writing a custom Joiner? 
That will only be called when the Subtask has completed and so is 
guaranteed to be in the SUCCESS or FAILED state?

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20250927/deafd8b1/attachment-0001.htm>