[External] : Re: A new build and a new structured concurrency API

[Alan Bateman]

On 18/11/2021 10:02, Alex Otenko wrote:
> I see why break may be an analogue, but don't see why it is the right one.
>
> Right now the tasks finish in one of four ways:
>
> Success with a value
> Failure with Exception
> Someone aborted, a subclass of Failure
> Shutdown
>
> And it is ok to use onComplete for three cases, but not the last? So now
> really all handling is spread across two sites, predictably requiring more
> code and more complexity in interactions with the other three termination
> conditions.
A task completes with a result, an exception, or it is cancelled. This 
will be familiar to everyone that uses Future::get. This project has not 
introduced any new states or ways for a task to complete. When using the 
2-arg fork method then the onComplete operation is invoked when the task 
completes, irrespective of whether it completed with a result, 
exception, or was cancelled.

The shutdown method is on StructuredExecutor, not Future. The javadoc 
tries to be clear that it is for cases where you've got an interesting 
result and are no longer interested in the results of other tasks. The 
shutdown method closes the front door to prevent new threads from 
starting. It also interrupts the threads that are running the tasks that 
haven't completed yet. It also tries to make it clear that when shutdown 
completes that are tasks are "done" (it links to Future::isDone). You 
shouldn't need to use Future::get with this API but if you were then you 
should see that Future::get wakes up when SE::shutdown is called.

-Alan