More Granular Bridging Functionality in Structured Concurrency

[Alan Bateman]

On 19/08/2025 00:08, Peter Eastham wrote:
> The Thread Local example was more about a situation where wrapping a 
> forked task would be useful.

Okay, the important point here is that you can't coerce a 
non-inheritable thread local to be inheritable.


> Another one I can think of is capturing the parent thread's name and 
> logging the forked thread's name to make it slightly easier to track 
> what threads are starting other threads.

The ThreadFactory is the place to do this. It allows you to hook into 
the thread creation and also allows the code for the subtask to be 
wrapped with before/after hooks. The fork method creates + starts the 
thread to execute the subtask so there isn't any need to distinguish 
create from start.

One other thing to point out is the Observability section in the JEP. 
That shows a jcmd that will generate a thread dump containing the 
hierarchy. This makes it easy to see the parent-child relationships 
without relying on thread names.


>
> That being said I should have let myself wake up more this morning, 
> the answer isn't adjusting the Structured Task Scope API, it's 
> providing the bridge as some type of delegator. Then you get something 
> like this
>
> var delegate = service.capture();
> // then somewhere in the structured task
> var subTaskA = scope.fork(delegate.wrapping(() -> {...}));
>
> This would let me bridge without breaking legacy code at the 
> granularity I was thinking about, without overriding the ThreadFactory.
>
I don't think I understand the aversion to using a ThreadFactory but 
let's see how your experiments go, and how far you can get without 
additional hooks.

-Alan