Structured concurrency: TaskHandle

[Alan Bateman]

On 12/05/2023 21:05, Attila Kelemen wrote:
> :
>
> ### Cancellation
>
> Cancellation is important enough to have very special care in my
> opinion. In fact - to me - it was so important that I wrote a brand
> new executor framework for my usage and happily using that instead of
> the built-in for 10+ years now.
>
> The question that should be asked is what are the important cases for
> cancellation?
>
> 1. The task did not even start. This is important to know, because it
> is very easy to argue about the consequences of this case. Though not
> completely free
> 2. The task did not complete before `shutdown`, but failed with a
> specially interpreted type of exception.
> 3. The task did not complete before `shutdown` was called, but started
> execution, and threw an unexpected exception.
> 4. The task did not complete before `shutdown` was called, but started
> execution, and returned without an exception.
>
> I think only (1) and (2) should be marked as cancelled, and this also
> implies that - in Rémi's sealed interface proposal - the `Canceled`
> result should have an nullable `Throwable` field.
>
> Case 3 should be considered to be an error, as that means that
> something unexpected happened (or at least someone was sloppy).
>
> Case 4 should be considered a success. Maybe, if we really want to
> preserve this information, then the success record could have a flag
> for this (though I believe it would be widely unused).
>
> As for Alan's comment about "storming handleComplete" on cancellation:
> `handleComplete` must not be called for case (1). If the STS needs to
> count them for whatever reason, then maybe a new
> `handleNonExecuted(long)` method can be implemented. Storming would be
> quite problematic for case (1), but not so much for the rest (since
> they were in the process of doing something anyway).
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.

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.

-Alan.