Structured concurrency: TaskHandle

[Alan Bateman]

On 12/05/2023 16:01, forax at univ-mlv.fr wrote:
> :
> I would say it in the other way, you need state() to know if the task has competed successfully then you can call get() or use the handle as Supplier.
> Technically, you do not need state() before calling join().

It will take time to get more feedback from real world usages. The 
examples that we published using ShutdownOnXXX don't need to switch on 
the state. For ShutdownOnSuccess you can discard the object returned by 
fork, it's not needed. For ShutdownOnFailure, if join().throwIfFailed() 
doesn't throw then you are guaranteed that all tasks have completed 
successfully so you don't need the state either.


> The non-determinism comes from the way Thread.interrupt() works. If the thread is interrupted during a blocking call or reach a blocking call an InterruptedException will be thrown. If there is no blocking call or Thread.currentThread().interrupt() is called, only the flag is positioned.
> I proposed that if the flag is positioned then the state of the task should be FAILED and if exception() is called, an InterruptException should be thrown (one with no stacktrace so it can be shared).
Calling shutdown means you are done and not interested in the tasks that 
are still running. Yes, they are interrupted (after the state transition 
to shutdown so any result/exceptions from the remaining task will be 
discarded). Are you looking to capture how they reacted to interrupt or 
what do you mean by "the flag is positioned". Maybe you are thinking 
about some side effect?

> :
> Taking a step back, there are two states, there are the task state and the state on the object passed to handleComplete.
> The former can be RUNNING, SUCCESS, FAILED or CANCELLED, the later is only SUCCESS or FAILED.
> Ìf we have two different objects, each one can have a different enum, TaskState and ResultState an everything is fine.
> If we have use TaskHandle for both, switching on the state inside handleComplete has two unreachable states but the compiler does not know that.
>
> So perhaps the solution is to have two different states.
That might be hard to explain so I think we should wait for more 
real-world usage and feedback before seeing if there are any adjustments 
required.


> :
> Another question does the API of TaskHandle should be only available to the owner thread of the scope ?
fork can be called by any subtask in the tree. So while of limited value 
compared to Future in this context, it would surprising if every method 
threw WTE.

-Alan