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
