: Re: StructuredTaskScope and Futures

Ron Pressler ron.pressler at oracle.com
Thu Jan 5 14:31:56 UTC 2023



On 5 Jan 2023, at 13:16, Arnaud Masson <arnaud.masson at fr.ibm.com<mailto:arnaud.masson at fr.ibm.com>> wrote:

I prefer the Supplier approach a lot.
Future usage in StructuredTaskScope looks weird especially since it reintroduces async style “legacy” where we don’t expect it.


The original thinking was that:

1. fork returning Future would feel more familiar to programmers acquainted with ExecutorService.submit
2. We didn’t know how important it would be to match exceptions to particular forks. That’s what we're trying to learn now.

Btw has a safer lambda-oriented API been considered (as an optional static helper)? for example:

    var sum = StructuredTaskScope.execute(
          () -> task1(),
          () -> task2(),
          (result1, result2) -> result1 + result2
     ) // throws if any error in one of the parallel tasks

(It could be defined for 2,3,4… args)


Yes. Pretty much any approach you can imagine has been tried. However, libraries are welcome to build convenience methods for common situations on top of STS as they see fit.

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


More information about the loom-dev mailing list