Structured Concurrency yet again

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Alan Bateman" <Alan.Bateman at oracle.com>
> To: "Holo The Sage Wolf" <holo3146 at gmail.com>, "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Ron Pressler" <ron.pressler at oracle.com>, "loom-dev" <loom-dev at openjdk.java.net>
> Sent: Wednesday, May 10, 2023 3:03:11 PM
> Subject: Re: Structured Concurrency yet again

> On 10/05/2023 07:47, Holo The Sage Wolf wrote:
>> The way to handle these cases is to put the logic after the task ends
>> into the scope itself.
> 
> Yes, extend STS and implement the policy in the subclass. The subclass
> can define APIs to consume the outcome after join. Remi's example calls
> for short circuiting after 3 tasks complete successfully or any task
> fails with UnknownHostException, so easy to do.

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.

By example, the implementation provided by Holo may not work because
- it requires the implementations of FanLogic and the ShutdownStrategy to be thread safe given that they are created and used by different threads.
- ConcurrentLinkedQueue.size() is O(n), not O(1) !
- results() can not be protected by ensureOwnerAndJoined given it is accessed by the implementation of the ShutdownStrategy
- you can have more than 3 results because a thread can be de-scheduled after the call to strategy.testResult() and before the call to results.add().

Concurrency is really hard, harder than most people think. 

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.

> 
> -Alan.

Rémi