RFR: Minor changes to `StructuredTaskScope`

Ron Pressler rpressler at openjdk.java.net
Tue Apr 12 08:55:07 UTC 2022


On Mon, 11 Apr 2022 20:52:21 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Some suggested minor changes to `StructuredTaskScope` source while reviewing the code.
> 
> Overall I like how this approach has boiled down to about as simple as it can get while supporting the constraints of structured concurrency (thanks in no small part to `ThreadFlock`).
> 
> I think it should be possible to simplify the subclass implementations if the values of `Future.State` were comparable as in `RUNNING` < `CANCELED` < `FAILED` < `SUCCESS`. Otherwise, introducing that internally could also simplify and avoid the task scopes holding on unnecessarily to futures that are not operated on after join. I was reluctant to make such a change here but could propose as a separate PR.
> 
> I was uncertain if the `ShutdownOnSuccess.result` methods and the various exception returning/operating methods on `ShutdownOnFailure` should be constrained to throw if called before `join` has completed. Otherwise, we should specify that if operated on before `join` has completed then the results are unspecified.
> (There might be a simple way for join to return something other than `this`, thereby avoiding this issue, with some additional complexity, but I suspect you have already thought of that and took the minimal route.)
> 
> I presume there is an implicit happens-before edge on `join` that we can make explicit and specify?

Thank you!
We've explored policies different `join` signatures wrapping the STS class rather than extending it. Ultimately, we favoured a common supertype with a common `join` method that better exposes the similarities between them, and `join` returning `this` is a reasonable compromise between expressing the similarity and a convenient, typesafe API.

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

PR: https://git.openjdk.java.net/loom/pull/142


More information about the loom-dev mailing list