RFR: Minor changes to `StructuredTaskScope`

Alan Bateman alanb at openjdk.java.net
Tue Apr 12 13:45:59 UTC 2022


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

> 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.

Yes, if the state were comparable then the subclasses could have 1 field instead of 3. I'm just not sure how generally useful having a total ordering of states might be.

The tracking of Future objects is mostly for the case where code is calling Future.get before join rather than after. As join is waiting for all threads to finish then all tasks should be done when it completes, so tracking. But you may be right that it could be improved.
 
> 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.)

Further seat belts are possible, in particular to catch calls to obtain the result/exception from a thread other than the owner, or to call it before join. One of the prototypes that I played with had a protected ensureJoined method but I held off exposing it.  Looking at it now, these methods in the subclasses should at least specify that they are intended to be called after join.


> I presume there is an implicit happens-before edge on `join` that we can make explicit and specify?

Yes, I guess it could be specified.

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

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


More information about the loom-dev mailing list