More Granular Bridging Functionality in Structured Concurrency

[Peter Eastham]

The Thread Local example was more about a situation where wrapping a forked
task would be useful. 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.

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'll try playing around with that approach sometime this week/month and
seeing what it feels like.

Thanks,
-Peter


On Mon, Aug 18, 2025, 1:22 PM Alan Bateman <alan.bateman at oracle.com> wrote:

> On 18/08/2025 16:53, Peter Eastham wrote:
> > Hello Loom Team,
> >
> > While reading over the other thread concerning Joiners, I finally
> > loaded in the EA for Java 25 and took a look over the Java Doc. While
> > I'm liking what I'm seeing (and need to play around with it more), I'm
> > struggling to figure out how to bridge older approaches with this.
> >
> > For example, let's say Library A heavily utilizes a ThreadLocal.
> > Because it's a library we can't migrate to a ScopedValue or
> > InheritableThreadLocal. Currently the best bridge I've found is to
> > provide a Configuration with a custom ThreadFactory. This is a little
> > heavy handed, as you're really only wanting to hydrate a ThreadLocal,
> > not manage the entire Thread.
>
> The ThreadLocal value may be mutable and/or otherwise unsafe to access
> from concurrent threads. ThreadLocals that are intended to be
> shared/inherited into other threads must be InheritableThreadLocals.
> InheritableThreadLocal has been mostly shunned by the eco system for a
> number of good reasons (performance being one). At the same
> time, InheritableThreadLocal does do what you want in a structured
> context, albeit with additional overhead when create threads for the
> subtasks, and possible side effects where the ITL is inherited further
> when subtasks happen to execute some code that creates a Thread.
>
> So your opening paragraph on integrating with existing code and
> libraries is important, I don't think it's feasible to be able to treat
> ThreadLocals as inheritable.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20250818/d1715151/attachment.htm>