Remark on the StructuredTaskScope API of Java 25

[forax at univ-mlv.fr]

> From: "Alan Bateman" <alan.bateman at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "loom-dev" <loom-dev at openjdk.java.net>
> 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20250925/74790ea5/attachment.htm>