On 19/12/2025 19:31, Attila Kelemen wrote:
:
3. `State.UNAVAILABLE`: Maybe a bit off-topic, but let me put it here:
It is kinda evil in my opinion, because most of the time I would fetch
the result after a `join` where that is an impossibility, yet its
presence makes switch expressions awkward. It would be nice to have a
`ResultState` with only two states `SUCCESS` or `FAILED`. Then of
course, the old `State` is not necessary, because it could become just
a `boolean isAvailable()` instead.
Cancellation and short circuiting means the scope may be cancelled
during the "forking phase" or while subtasks are running. There may even
be a few stragglers that are slow to respond to the request to finish
and continue concurrently with the code that executes after join. So
several cases where is no result or exception. Mapping "did not run",
"cancelled" and other states to FAILED is problematic, as is introducing
further states.
(If I read your example correctly then it just wants to cancel when any
subtask fails but it doesn't want the scope (or join) to fail. In that
case, `Joiner.allUntil(s -> s.state() == Subtask.State.FAILED)` should
reduce it down. No need to keep a reference to the subtasks, no need for
the results list, and the handling of FailException goes away to). The
result from join will be the list of subtasks that can be filtered to
exclude the UNAVAILABLE then partitioned into the success + failed buckets.)
-Alan.
