Timeouts in structured concurrency

[Holo The Sage Wolf]

I don't see how this stops us from adding the overload David suggests.

The current implementation implementation of the 0-args open method is to
delegate into the 2-args open method:

... open() {
    return open(<default joiner>, Function.identity());
}

With the suggested overload we will have:

... open() {
    return open(Function.identity())
}

... open(Function<Configuration, Configuration> confFunc) {
    return open(<default joiner>, confFunc);
}

In both cases, changing the default based on users input will mount to
changing the joiner in a single place

On Fri, 19 Dec 2025, 12:52 Alan Bateman, <alan.bateman at oracle.com> wrote:

>
>
> On 19/12/2025 08:33, David Alayachew wrote:
>
> And maybe it'll help if I clarify what I was saying to @Holo The Sage Wolf
> <holo3146 at gmail.com>.
>
> Holo is saying that they like the default joiner, but adding a timeout to
> it takes more code than necessary. They proposed multiple different
> overloads, but I suggested the following overload instead.
>
> StructuredTaskScope.open(UnaryOperator<StructuredTaskScope.Configuration>
> configOperator)
>
>
> There are two built-in joiners that implement the policy to cancel the
> scope and cause join to throw if any subtask fails. One is suited to
> subtasks that produce results of the same type. It can collect the results
> and have join yield the list of results. The other is suited to subtasks
> that produce results of very different types and where it is more
> convenient to retain the Subtask returned from fork. The feedback to date
> on which would be the better default is inconclusive. The choice influences
> the return from the 1-arg open method is being discussed here, and is why
> it is not included in the current API.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20251219/103aa480/attachment.htm>