> From: "Alan Bateman" <[email protected]> > To: "Remi Forax" <[email protected]>, "loom-dev" <[email protected]> > Sent: Wednesday, September 24, 2025 7:52:44 PM > Subject: Re: Remark on the StructuredTaskScope API of Java 25
> 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. In a way, i think i want something that the STS is not. I want to be able to run the semantics of onComplete() but without the burden of managing the concurrency part, like if onComplete() was run by the main thread (and yes, i know it has a cost). >> - 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? CompletionService is several things, you can get the subtask as they complete (1), this is run by the main thread (2) and it's a pull API (3). I want (1) and (2), but not necessary (3), so it's still a STS that join as a unit. As said above, what i think i want is a way to opt-in to get onComplete to be run by the main thread when join() is called. > -Alan regards, Rémi
