<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Alan Bateman" <alan.bateman@oracle.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr>, "loom-dev" <loom-dev@openjdk.org><br><b>Sent: </b>Saturday, September 27, 2025 9:33:42 AM<br><b>Subject: </b>Re: Subtask states<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div class="moz-cite-prefix">On 26/09/2025 18:41, Remi Forax wrote:<br>
</div>
<blockquote cite="mid:1920101532.708894.1758908500414.JavaMail.zimbra@univ-eiffel.fr">
<pre class="moz-quote-pre">Currently,
the interface Subtask defines 3 different states, but while the implementation needs 3 states, I believe the interface only need 2.
Currently, having 3 states punished people that are using the API correctly, i.e accessing the state when all the computations are done,
after join() is called, because for them, only two states are visible, but they still need to write a code that takes can of the state
UNINITIALIZED.
I propose that state() can only return SUCCESS or FAILURE and throw an ISE if the internal state is UNINITIALIZED given it means
that the API is not used correctly.
In the past, with the previous iteration of the design using inheritance instead of delegation, the Subtask was not sealed,
so the internal state had to be exposed, but now that only the implementation of STS can create a Subtask, the internal state UNINITIALIZED does not have to be visible.
</pre>
</blockquote>
Subtask has always been sealed. It has always had 3 states, nothing
has changed, and nothing from the implementation has leaked into the
API. So I'm a bit puzzled by your message. There is no outcome to
report when a subtask is executing, was cancelled, or was forked
after the scope was cancelled. The Subtask::state returns
"UNAVAILABLE" for all these cases. It's easy to come up with
examples where join returns a stream of subtasks in each of these
states.</blockquote><div><br></div><div>sorry,</div><div>i forget that case, worst, i think you already explain that to me, again sorry.</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br>
<br>
Is your gripe with the onComplete method when writing a custom
Joiner? That will only be called when the Subtask has completed and
so is guaranteed to be in the SUCCESS or FAILED state?</blockquote><div><br></div><div>yes,</div><div>i think my mistake comes from the fact that for me the subtasks returned by STS.join() should all have been gone through onComplete,</div><div>but this is not the case actually</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br>
<br>
-Alan</blockquote><div><br></div><div>regards,</div><div>Rém</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><br></blockquote></div></div></body></html>