New candidate JEP: 462: Structured Concurrency (Second Preview)

[David Alayachew]

> The current situation seems kinda clunky with
> using one stream to collect futures, and yet
> another stream to collect results. Maybe one
> of the Java architects hates such boilerplate,
> and will come up with an elegant way to
> reduce/remove such boilerplate.

I can sympathize, but I think it is clearer this way. It's obvious from a
glance that all the work of scope forking occurs before performing a join.
And a join occurs before any of the tasks have get called on them.

I struggle to see a way to join that into one stream while maintaining that
clarity.


On Fri, Oct 27, 2023 at 12:37 PM Eric Kolotyluk <eric at kolotyluk.net> wrote:

> Looks good... thanks.
>
> One slight area of confusion for me was,
>
> <T> List<Future<T>> executeAll(List<Callable<T>> tasks)
>         throws InterruptedException {
>     try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
>     	  List<? extends Supplier<Future<T>>> futures = tasks.stream()
>     	      .map(task -> asFuture(task))
>      	      .map(scope::fork)
>      	      .toList();
>     	  scope.join();
>     	  return futures.stream().map(Supplier::get).toList();
>     }
> }
>
> static <T> Callable<Future<T>> asFuture(Callable<T> task) {
>    return () -> {
>        try {
>            return CompletableFuture.completedFuture(task.call());
>        } catch (Exception ex) {
>            return CompletableFuture.failedFuture(ex);
>        }
>    };
> }
>
> And what happens if ShutdownOnSuccess is called instead. Eventually I
> reasoned that the right thing should happen, but there should only ever be
> one element in the list. Does the scope guarantee only one result?
>
>    1. It would be slightly helpful to point this out in a note so that it
>    is more obvious.
>    2. What is less obvious is that with ShutdownOnSuccess what happens if
>    one or more of the siblings throw an exception?
>       - I would hope that so long at least one task succeeds, this should
>       not cause the overall success of the scope to fail.
>       - It would be nice to see this explained more clearly.
>       -  Maybe ShutdownOnSuccess deserves its own example, discussing
>       possible edge cases.
>
> Somehow I am remembering Scala 'for comprehensions' with concurrent tasks
> that 'yield' a result... 😉
>
> The current situation seems kinda clunky with using one stream to collect
> futures, and yet another stream to collect results. Maybe one of the Java
> architects hates such boilerplate, and will come up with an elegant way to
> reduce/remove such boilerplate.
>
> Sincerely, Eric
> On 2023-10-27 7:39 a.m., Mark Reinhold wrote:
>
> https://openjdk.org/jeps/462
>
>   Summary: Simplify concurrent programming by introducing an API for
>   structured concurrency. Structured concurrency treats groups of related
>   tasks running in different threads as a single unit of work, thereby
>   streamlining error handling and cancellation, improving reliability,
>   and enhancing observability. This is a preview API.
>
> - Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20231027/621ffeca/attachment-0001.htm>