[External] : Re: StructuredTaskScope and Futures

[Ron Pressler]

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



----- Original Message -----
From: "Ron Pressler" <ron.pressler at oracle.com<mailto:ron.pressler at oracle.com>>
To: "Remi Forax" <forax at univ-mlv.fr<mailto:forax at univ-mlv.fr>>
Cc: "loom-dev" <loom-dev at openjdk.org<mailto: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?

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.

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.

— Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230104/7da22b48/attachment-0001.htm>