Structured Concurrency Feedback

[Alan Bateman]

On 20/10/2025 19:03, Josiah Noel wrote
>
> I assume there are good reasons to not make it like 
> CompletableFuture's unchecked join method, so if nothing can be done 
> I'll just leave it at that.

CF::join is not interruptible and will wait indefinitely when 
interrupted.  That may be okay in a top-level usage but would be 
problematic if executed in a subtask when the scope is cancelled (as the 
scope owner would block indefinitely in close waiting for the subtask).

An uninterruptible-join can be built on an interruptible-join of course 
and that may be an option for a usage that you know will never be cancelled.

>
> The application itself is nothing but an orchestration api where we 
> make downstream calls to other services to get and combine data. I 
> didn't test anything other than the default joiner because if any of 
> the calls fail we want to terminate the request immediately (they were 
> also all different types). I didn't need to check the state of the 
> individual tasks, so I used a supplier for the wrapper.
>
This is useful on two points. One is that the default policy that we 
think is right for a high percentage of cases. The second is whether it 
will be more common to fork subtasks that return results of the same 
type or different types. So your comments are very useful, as is your 
"works for me" comment in the introduction - thank you for taking the 
time to send mail on your experiences.

-Alan