Can StructuredTaskScope be generalized?

[Ron Pressler]

A StructuredTaskScope is a local control mechanism meant to be created, destroyed, and typically accessed only from within a single method. For that reason, abstracting it further would yield little benefit.

Indeed, for this reason, STS is presented as being merely the first instance of a structured concurrency construct in the JDK, and others may be added. It is perfectly okay, and even expected, for method foo to use STS for structured concurrency and for method bar to use another, just as foo may use a while loop and bar a for loop, or for foo to use `if` and for bar to use `switch`. This is by design, since we feel that structured concurrency is not yet fully understood.

Furthermore, STS has some semantic features — its interaction with ScopedValues and with the observability of thread trees (represented by the internal ThreadFlock class, which may be exposed directly in the future to be used by other thread-based structured concurrency constructs) — that cannot be naturally offered by non-thread-based structured concurrency.

So while it’s possible that in the future we may add some super-interface that STS implements, my question to you is this: even supposing there is some higher meaningful abstraction to be extracted here (and there probably is), what is the actual use of representing it with a Java interface given that an STS instance should never be shared among methods by storing them in a field or, indeed, should rarely even be passed from one method to another? In other words, supposing structured concurrency constructs for processes were added to the JDK in the future, what practical benefit is there to having them share a common Java interface with STS?

One such benefit I could see is sharing the documentation, and with it the understanding of how all implementations of such an interface should behave. But I think we don’t have sufficient understanding of what’s really required of “structured concurrency” to make a commitment to an actual Java interface just yet. Without better understanding, we may end up with a whole hierarchy of interaces — one requiring only nested lifetimes, another additionally requiring the propagation of errors and cancellation, yet another additionally inheriting ScopedValues etc. — that aren’t practically useful.

— Ron

> On 4 Oct 2024, at 11:10, Mike Hearn <michael.hearn at oracle.com> wrote:
> 
> Hi,
> 
> StructuredTaskScope looks nice but in its current form it might be better named StructuredThreadScope, as the implementation is a class that’s tied to threads by its constructor. There are other situations where it's useful to group concurrent tasks, even without threads getting involved:
> 
> - Processes
> - Raw continuations/fibers if they are ever added
> - Work done on remote systems via RPCs
> 
> For example, an SSH library might want to let you invoke multiple processes on a remote system and join on them completing.
> 
> It might be worth generalizing the API a bit by making StructuredTaskScope an interface and introducing StructuredThreadScope as a class that implements it using threads. StructuredTaskScope would gain another type variable defining what gets submitted:
> 
> /**
> * @param R the result type of tasks executed in the task scope.
> * @param T the type of the tasks themselves.
> */
> interface StructuredTaskScope<R, T> {
>    <U extends R> StructuredTaskScope.Subtask<U> fork(T task);
> }
> 
> … and then the thread based instantiation would take callables as normal.
> 
> class StructuredThreadScope<R> implements StructuredTaskScope<R, Callable<? extends R>> {
>    public StructuredThreadScope(ThreadFactory factory) { … }
> }
> 
> Then if someone wanted to implement the same interface on top of some other concurrent system that can’t accept arbitrary lambdas, they could.
> 
> This is a minor piece of feedback because the interface is quite simple and other concurrent systems can just duplicate it under a different name, but it’d be nice if that wasn’t necessary.
> 
> thanks,
> -mike