[External] : Re: StructuredTaskScope and Futures

[Remi Forax]

----- Original Message -----
> From: "Alan Bateman" <Alan.Bateman at oracle.com>
> To: "Florian Schmaus" <flow at cs.fau.de>, "loom-dev" <loom-dev at openjdk.org>
> Sent: Wednesday, January 4, 2023 6:03:36 PM
> Subject: Re: [External] : Re: StructuredTaskScope and Futures

> On 04/01/2023 16:48, Florian Schmaus wrote:
>>
>> I always wondered if it would be helpful if StructuredTaskScope had
>>
>> List<V> results()
>> List<Throwable> exceptions()
>>
>> As Remi wrote, it is sometimes useful to inspect the failure cases,
>> e.g., to check if it was a sporadic or persistent failure. Similar, it
>> is sometimes good to have access to all results. For example to fall
>> back to other results in case a result is not usable.
> 
> The intention with StructuredTaskScope is that the API defines a small
> number of subclasses that implement common policies and for it to be
> easy to extend to implement whatever collection or policy is
> appropriate. The subclass is meant to define the methods that make
> available the results or other outcome. The "Extending
> StructuredTaskScope" section in the class description has an example
> that collects all results, and a method to get the results as a stream.
> Once we get more experience and feedback in this area then it might be
> that the two "built-in" policies that aren't the best but for now I
> think it should be easy to implement other policies.
> 
> Just to put more context on this discussion - the issue with fork
> returning Future is the temptation to call Future::get and wait for the
> result whereas the intention with this API is to wait in
> StructuredTaskScope::join and then process the results or outcome.

so Future has too many methods, but a Supplier has too few.

It looks like we want either a supertype of Future or a Future that throws an ISE if get() is called.

> 
> -Alan.

Rémi