[External] : Re: StructuredTaskScope and Futures

[forax at univ-mlv.fr]

> From: "Ron Pressler" <ron.pressler at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "loom-dev" <loom-dev at openjdk.org>
> Sent: Wednesday, January 4, 2023 5:17:24 PM
> Subject: Re: [External] : Re: StructuredTaskScope and Futures

>> On 4 Jan 2023, at 15:54, [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] wrote:

>> ----- Original Message -----

>>> From: "Ron Pressler" < [ mailto:ron.pressler at oracle.com |
>>> ron.pressler at oracle.com ] >
>>> To: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "loom-dev" < [ mailto:loom-dev at openjdk.org | loom-dev at openjdk.org ] >
>>> Sent: Tuesday, January 3, 2023 12:00:45 PM
>>> Subject: Re: [External] : Re: StructuredTaskScope and Futures

>>> When do you need to know the state or exception on an individual task rather
>>> than rely on the policy to handle errors collectively before processing
>>> successful results? If you have a code example that would be helpful.

>> because you may want to log the suppressed exceptions.

>> Let say you use a ShutdownOnSuccess, even if you get a result, you still want to
>> log all the exceptions that occurs before the result because some exceptions
>> are triggered by an issue that should be fixed (an invalid auth key, an expired
>> token, etc) which shows that even if it works, something had gone wrong.

>> Conceptually, we are looking at abstracting a loop over async calls, a shutdown
>> on success is equivalent to a short-circuit of the loop.

>> Each call returns Result | Exception.
>> So all calls are a (Result1 | Exception1) x (Result2 | Exception2) x ...
>> If you reduce it, you get a Result x Exception.

> Then let me give you a hard time and ask you two follow ups:

> 1. In the case where no real failures are encountered, when ShutdownOnSuccess
> completes, you’d expect to see one successful result and (say) nine cancelled
> forks (or, equivalently, forks that throw InterruptedException). Even when some
> forks could have actually failed, whether you’ll see a real failure or a
> cancellation (/InterruptedException) is entirely up to chance. So how useful is
> it to see the exceptions?

I think we are starting to drift from the original question here but yes, some task failures are hidden by the fact that the chosen semantics is ShutdownOnSuccess or if you have a timeout. 
Anyway, that does not make the exceptions that happen before less valuable. 

> 2. If the purpose is just logging, wouldn’t it be more helpful if, upon failure,
> the policy would add all the exceptions as suppressed exceptions to the one it
> throws? Moreover, if you want to log an exception associated with each specific
> fork, the forks could log it themselves.

Those suppressed exceptions are interesting, independently of the success of the computation. 
If each fork logs itself, you make the monitoring work harder because you are loosing the information that the errors are part of the same computation. 

> The reason I’m asking this question in the first place is that I’d like to
> consider having fork return a Supplier<T> rather than a Future<T>, as that API
> is not only significantly simpler, but more clearly directs the user toward the
> right thing to do (as there’s only one thing they *can* do). If getting
> specific exceptions is useful in a *small* number of cases, this can be solved
> with a simple indirection: have the task itself be a Callable<Future<T>> that
> returns a completed Future, and so fork would return Supplier<Future<T>>. If,
> on the other hand, having access to a richer Future object is useful in *many*
> situations, then we’ll keep things as they are, but that’s what I’m trying to
> ascertain.

I do not see how the indirection can work given that the Future object returned by fork() is specific to a StructuredTaskScope ? 

I see how this can be done by inheriting from StructuredTaskScope, but you have to be a concurrency expert to do that given that the callback (handleComplete) is called by each virtual threads. 

> — Ron

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230104/e37afff7/attachment-0001.htm>