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
