> If the API allowed Subtask::get to be used > before join then it would be very fragile as it > would be like a "wait-less" Future::get. It > might work sometimes, but if a subtask were > slow then Subtask::get would throw ISE.
Can you explain this in more detail? I don't understand what you are saying here. On Wed, Sep 24, 2025 at 1:52 PM Alan Bateman <[email protected]> wrote: > > > On 24/09/2025 16:37, Remi Forax wrote: > > : > > And now two remarks, > - is there a way to remove the limitation that the main thread (the one that > have created the STS) can not access to SubTask.get(), > because there is at least a case where i know that the task is finished > before join() is called (see below). > > > This restriction is there to ensure that the API is used as intended. > Subtasks are forked individually and then joined as a unit. If the API > allowed Subtask::get to be used before join then it would be very fragile > as it would be like a "wait-less" Future::get. It might work sometimes, > but if a subtask were slow then Subtask::get would throw ISE. > > - is there a way to get a joiner that returns the list of subtask in the > order if their completeness, not in the order of onFork() ? > > > A Joiner can collect in its onComplete method so that will give you > completion order. That said, I suspect you might be asking something > different. Are you thinking about APIs such as CompletionService where you > get a wakeup as subtasks complete rather join as a unit? > > -Alan >
