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

[Adam Warski]

Hello,

>> 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. So the whole point here is to move the logic out of the scope, into a fork, so that it can fork further. Nested scopes here are not a solution (the nested scope has the same problem).

But I can see how it goes against the current idea of a subtask, which is un-joinable - you can only query it after the entire scope has joined. Also, it’s always easier to add the possibility to fork-in-fork, than to remove it (which, once the JEP is final, wouldn’t be possible). Still, the problem I described remains. And yes, the analogy with parents/siblings breaks down, but that’s just an analogy :)

As for the hierarchy, I think it’s still there, it’s just that a fork creates a fork in the scope to which it belongs. You might say, that you limit the "structurefullness" of the approach to the scope, as you then allow to create forks-in-forks which don’t follow the structural properties fully. But it might also be a reasonable tradeoff between flexibility in forking and maintaining structure.

Adam

-- 
Adam Warski

https://warski.org