Structured Concurrency yet again

[Alan Bateman]

On 10/05/2023 16:01, forax at univ-mlv.fr wrote:
> :
> The problem is that unlike any other classes in java.util.concurrent, STS is not thread safe by default, it requires to carefully implement any subclasses in a thread safe way.

STS is thread safe, as are the ShutdownOnXXX subclasses for the common 
cases. When you go down the more advanced route, in this case to have a 
policy to short circuit when there are 3 results or a task fails with 
UHE, then it means extending STS and being careful. I think we will need 
to get real world usage to see if this is really a problem or whether 
additional support is required to make it easier to implement policy in 
a thread safe way.


> :
>
> - results() can not be protected by ensureOwnerAndJoined given it is accessed by the implementation of the ShutdownStrategy
The intention is that methods for processing the outcome after join use 
ensureOwnerAndJoined so they are restricted to the main task/owner.


> :
>
> I would prefer to provide an API easier to use. I believe that having a method join() that takes a function that takes a stream is easier to use correctly.
We were down that road before when the prototype was based on ES. It's a 
different style of API, also it involves the main task doing O(N) 
wakeups rather than one.

-Alan