On Tue, 15 Apr 2025 06:36:20 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> Changes for [JEP 505: Structured Concurrency (Fifth >> Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview >> the API with some changes, specifically: >> >> - A >> [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) >> is now opened with a static factory method instead of a constructor. Once >> opened, the API usage is unchanged: fork subtasks individually, join them as >> a unit, process outcome, and close. >> - In conjunction with moving to using a static open method, policy and >> desired outcome is now selected by specifying a Joiner to the open method >> rather than extending STS. A Joiner handles subtask completion and produces >> the result for join to return. Joiner.onComplete is the equivalent of >> overriding handleComplete previously. This change means that the subclasses >> ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory >> methods on Joiner to get an equivalent Joiner. >> - The join method is changed to return the result or throw >> STS.FailedException, replacing the need for an API in subclasses to obtain >> the outcome. This removes the hazard that was forgetting to call >> throwIfFailed to propagate exceptions. >> - Configuration that was provided with parameters for the constructor is >> changed so that can be provided by a configuration function. >> - joinUntil is replaced by allowing a timeout be configured by the >> configuration function. This allows the timeout to apply the scope rather >> than the join method. >> >> The underlying implementation is unchanged except that ThreadFlock.shutdown >> and wakeup methods are no longer confined. The STS API implementation moves >> to non-public StructuedTaskScopeImpl because STS is now an interface. A >> non-public Joiners class is added with the built-in Joiner implementations. > > Alan Bateman has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 15 commits: > > - Add JEP number, update copyright headers > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - Merge branch 'master' into JDK-8342486 > - Merge branch 'master' into JDK-8342486 > - Fix link > - Merge branch 'master' into JDK-8342486 > - Sync up impl/tests form loom repo > - ... and 5 more: https://git.openjdk.org/jdk/compare/3090e218...418bc3d3 src/java.base/share/classes/java/util/concurrent/Joiners.java line 93: > 91: return (state == Subtask.State.FAILED) > 92: && (firstException == null) > 93: && FIRST_EXCEPTION.compareAndSet(this, null, > subtask.exception()); 1. Should we add the other exceptions as suppressed to the first? 2. If we have stable values, we can use a stable value to racily set the first exception. src/java.base/share/classes/java/util/concurrent/Joiners.java line 190: > 188: * A joiner that returns a stream of all subtasks. > 189: */ > 190: static class AllSubtasks<T> implements Joiner<T, Stream<Subtask<T>>> > { Suggestion: static final class AllSubtasks<T> implements Joiner<T, Stream<Subtask<T>>> { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2043738283 PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2043741615
