Behaviour of fork() after scope closing (was "When should I use onFork?")

[Alan Bateman]

On 24/08/2025 16:06, David Alayachew wrote:
> Thanks for the context Alan and Viktor. I guess since Virtual Threads 
> kick off tasks so fast (due to their throughput), I never had a chance 
> to observe this behaviour.
>
> But I think I get it -- once the scope closes, all future calls to 
> fork() fail, so onFork() simply doesn't get called.

If you stick to try-with-resources and open the STS in the 
resource-specification, e.g. try (var scope = 
StrcuturedTaskScope.open(..)) { }, then the local variable will not be 
in scope in code that follows the try-with-resources statement. This 
makes it hard to even attempt to fork after the STS has been closed. If 
a reference does escape then it just means that calling fork after the 
close will throw IllegalStateException.


>
> That is a very important detail though. Hope you don't mind, but let 
> me change subject to make sure I understand this behaviour.
>
> For example, let's say I use the anySuccessfulOrThrow Joiner. Then, 
> theoretically speaking, if I have enough tasks such that by the time 
> the scope closes, I am still feeding tasks into fork(), then my scope 
> will fail? Am I understanding that correctly?
>
This is cancellation rather than closing. It's okay for the scope to be 
cancelled during the "forking phase". Once cancelled, it just means that 
fork returns a subtask (UNAVAILABLE state) without starting a thread to 
execute it. The StrcuturedTaskScope::isCancelled method can be used to 
avoid doing unnecessary work in a lengthy forking phase (there's an API 
note in the isCancelled method on this).

-Alan.