RFR: 8306647: Implementation of Structured Concurrency (Preview) [v2]

[Paul Sandoz]

On Thu, 25 May 2023 08:21:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of:
>> 
>> - JEP 453: Structured Concurrency (Preview)
>> - JEP 446: Scoped Values (Preview)
>> 
>> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
>> 
>> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
>> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Sync up from loom repo
>  - Remove csm.Threads
>  - Merge
>  - Test should not be in update for main line
>  - Sync with loom repo
>  - Sync up tests frmo loom repo
>  - Sync up with loom repo
>  - Sync update API/impl/tests
>  - Merge
>  - Sync up with loom repo
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/89f2d458...e92ba524

This looks good (both `ScopedValue` and `StructuredTaskScope`).

I recall some discussion on the loom email list noting that `ScopedValue` instances are like capabilities and should be shared carefully (like `MethodHandle`s in some sense). I think it would be useful to follow up on that in the specification.

I am uncertain on the name `Subtask` but cannot think of anything better, perhaps during this round of preview we might find something else.

For a small API `StructureTaskScope` is rather powerful and deftly combines language, library, and platform features (virtual threads). 

I suggest revisiting the constraints on operating on `SubTask` instances. I get the motivation but i wonder if the additional specification and implementation work required to properly describe the behaviour and enforce it is really worth it. Such a restriction tends to feel artificial given there are no side-effects to such operations, and further we cannot enforce such restrictions in the compiler. 
The constraints of `fork`, `join`, `shutdown`, and `close` are key with the idiomatic use with try-with-resources. Just let subtasks be accessible by any thread for all its methods and provide clear documentation on the recommended use.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13932#pullrequestreview-1444622838