[External] : Re: StructuredTaskScope and Futures

[Ron Pressler]

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

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.

Logging a fork’s failure in its scope is not an effective mechanism for observing context because it’s only one level deep — the parent scope’s own context is lost, not to mention that it doesn’t provide context for any logging events that aren’t task failures. Rather, the solution we have in mind for logging is to provide an API that allows observing the full context hierarchy for logging and monitoring purposes (i.e. you’ll be able to observe a stack of the hierarchy up to the root).



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


Since we only care about completed futures anyway, what I had in mind is something like:

    Supplier<Future<T>> sf = sts.fork(asCompletedFuture(() -> foo()));

where,

    static <T> Callable<Future<T>> toCompletedFuture(Callable<T> task) {
        return () -> {
            try {
                return CompletableFuture.completedFuture(task.call());
            } catch (Exception ex) {
                return CompletableFuture.failedFuture(ex);
            }
        });
    }

This could be used when an association between exceptions and particular tasks is needed for uses other than logging. What I’m trying to ascertain is how frequently this is  needed, where my hypothesis is not very frequently at all.

Now, in addition to making the right thing more obvious, the Supplier approach directs the user into the right frame of mind when working with STS, i.e. to think of the forks as a unit rather than individual tasks, and anything that belongs to the individual task should be done in the fork.

— Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230105/17cbb579/attachment.htm>