Can StructuredTaskScope be generalized?

[Mike Hearn]

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