Timeouts in structured concurrency

[David Alayachew]

Yeah, I'm not seeing your point here either @Alan Bateman
<Alan.Bateman at oracle.com>.

It almost sounds like you all are saying that, because you don't know which
default joiner you are going to use, that you refuse to give us this
specific convenience method until you find that default. Maybe the logic
behind that train of thought is obvious to you, but not to us. You'll need
to explain it. Because in our eyes, the cost is just changing the return
type of (and a line of code in) 2 methods -- a cheap thing to do for an API
in Preview.

In short, what do you gain by holding off on this until you find the right
default? That's not clear to us.

On Fri, Dec 19, 2025, 6:18 AM Holo The Sage Wolf <holo3146 at gmail.com> wrote:

> 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/f15d1740/attachment-0001.htm>