Problem report on the usage of Structured Concurrency (5th preview)

[Pedro Lamarão]

Em qua., 1 de out. de 2025 às 03:38, Adam Warski <adam at warski.org> escreveu:


> >> Well if scope.join() waits until all forks complete, it will only do so
> when there are no forks left, and then nobody can create new forks? So I
> don’t think there’s a race here? In other words, forks can only be created
> from live forks, before they complete.
> > That's right but allowing this (as it was in early previews) creates
> weirdness where a subtask can fork it cannot join. It also messes with the
> mental model of "parent".  Who is my parent when I'm forked by a sibling?
> >
> > If the problem has been arranged so that subtask opens a new scope and
> decomposes into a set of sub-subtasks forked in this scope, thus creating a
> hierarchy, then it becomes simpler to reason about.
>
> Absolutely, if you can correctly solve your problem using nested scopes,
> that’s the way to go! Full agreement here :)
>
> However, the forks-in-forks is one solution or work-around for the problem
> of having complex, or blocking logic in the scope’s body, and wanting that
> logic to participate in the same error handling (interrupt when scope is
> cancelled) as the forks.
>

I fail to understand this; I have not tested STS extensively.
Is it not the case that an inner scope will be cancelled when its parent
scope is cancelled?
The forked subtask would be joining the inner scope; will this inner join
not be cancelled when the outer join is cancelled?
In what sense does an inner scope not participate in the same error
handling as the outer scope?

-- 
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20251002/08c705da/attachment.htm>