Structured concurrency: TaskHandle

[Robert Engels]

Expecting or using a result after calling shutdown seems invalid. The UI example seems especially incorrect. If I am a user and attempt to cancel an operation and the system says “hey here’s your answer anyway” that does not match the user intent - which is a bad UX. 

What a developers wants is that if an operation is cancelled the end result is deterministic - or inspectable. This is old XA transaction argument all over again. If you don’t you a two-phase commit protocol you need other means to understand the state of the system. 

> On May 13, 2023, at 6:44 AM, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
> 
>> 
>> The STS API tries to keep things simple. Calling shutdown means you are
>> done and not interested in the results/outcome of the subtasks that have
>> not finished. They will be interrupted, and the close method will block
>> until the stragglers have finished.
>> 
> 
> Calling shutdown could also mean that I would care about the result,
> but I lack faith that the task will complete in a reasonable time.
> However, the process might be waiting on something that it cannot
> cancel (for whatever reason), and at that point - since it will be
> computed anyway - I want to see the result. Consider a UI, it would be
> rude for the UI, that even though it computed the result I requested,
> refuses to show the result to me.
> 
>> In your 1-4 cases, all will cancelled. If this were API for a thread
>> pool with a task queue then more insight into the state of the system at
>> shutdown might be interesting, as might collecting results/outcome after
>> shutdown, but I think that is beyond where this API should be at this point.
>> 
> 
> If the goal is to be minimal, then I think the API shouldn't concern
> itself with cancellation at all (it is kinda a false promise), and
> should do what Rémi proposed: Fail on cancellation with a specific
> exception (it is a little bit awkward that we have both
> `InterruptedException` and `CancellationException`, but something must
> be chosen anyway). Completely skipped tasks should not be passed to
> `handleCompleted`.
> 
> I know that there is the potential worry that if `shutdown` was
> called, then the threads were interrupted, which might have changed
> their behaviour even though they returned normally. However - if this
> is a worry (and I would say it rarely is) - then it is trivial to
> handle by the caller, since the caller knows that it called
> `shutdown`.