Naming Things - Task and Subtask

[Attila Kelemen]

There could be some restrictions which I didn't notice, but STS takes
a `ThreadFactory`, so it is not necessarily related to virtual threads
(though I guess people will use it with virtual threads pretty much
exclusively for performance reasons).

>  ... but it's not clear to me that StructuredTaskScope implies ScopedValue?

Scoped values are captured by STS upon its creation and are propagated
to forked tasks. So, the "Scope" in those names are well justified
(and the normal calls naturally inherit scoped values of course like a
thread local).

As for combining scoped values and STS into a single builder: It
doesn't seem that useful to me, because you don't just want to share
the scoped values with an STS, but normal calls as well usually (at
least the use cases I can think of, you would not immediately start an
STS, but just call a method). However, the part where you don't have
to use try-with-resources is good of course, but it is an easy to
write utility (having the convenience in the JDK would be nice though
of course).

Eric Kolotyluk <eric at kolotyluk.net> ezt írta (időpont: 2023. máj. 19., P, 1:07):
>
> Just some thoughts on Threads, Task, etc... please ignore if you think I am out to lunch...
>
> Originally, Project Loom started with the notion of Fibers, but then change the name to VirtualThreads. I liked "Fibers" but I agree that "VirtualTreads" makes more sense in some ways.
>
> When we talk about "Tasks" we usually think about concurrent things, where a Task is an abstract concept of concurrency and a Thread is an implementation.
>
> Task is what
>
> Thread is how
>
> If we changed the term "VirtualThread" to "Subthread" then there would be better symmetry with "Task" and "Subtask" but it's far too late to change the name "VirtualThread" and I am not sure if I like the term "VirtualTask" but I could live with it.
>
> In a way, we could create a symmetry between Task and Thread, where every Task has a Thread. Maybe this is a useless symmetry, but creating a Task does not mean you have to start the thread, just that it's the root of abstraction on concurrency, where thread is the root of implementation.
>
> Then comes the question of Scope...
>
> I proposed something like this a long time ago, but at the time people claimed this was unnecessary abstraction, and then later came Structured Concurrency... oh well...
>
> I have since seen discussions on StructuredTaskScope and now ScopedValue, but it's not clear to me that StructuredTaskScope implies ScopedValue? It doesn't but it can. Both StructuredTaskScope and ScopedValue are examples of dynamic scope.
>
> Maybe instead of saying
>
>  try (var scope = new StructuredTaskScope<Object>()) {
>
>         Subtask<String> subtask1 = scope.fork(task1);
>         Subtask<Integer> subtask2 = scope.fork(task2);
>
>         scope.join();
>
>         ... process results/exceptions ...
>
>     } // close
>
> we should be saying
>
>  try (var scope = Task.StructuredScope<Object>()) {
>
>         Subtask<String> subtask1 = scope.fork(task1);
>         Subtask<Integer> subtask2 = scope.fork(task2);
>
>         scope.join();
>
>         ... process results/exceptions ...
>
>     } // close
>
> where we have to figure out what we really mean by "Task" and "Subtask"
>
> Given that Subtask is a sub-interface of Supplier<T> , maybe Task should also be a sub-interface of Supplier<C> where C is some Collection class. This might make concurrent collection based coding more elegant, where we state our intention to 'Supply' some collection via get().
>
> Where we have
>
>    private static final ScopedValue<String> USERNAME = ScopedValue.newInstance();
>
>     ScopedValue.runWhere(USERNAME, "duke", () -> {
>         try (var scope = new StructuredTaskScope<String>()) {
>
>             scope.fork(() -> childTask1());
>             scope.fork(() -> childTask2());
>             scope.fork(() -> childTask3());
>
>             ...
>          }
>     });
>
> we might have
>
>    private static final Scope.Value<String> USERNAME = Scope.Value();
>
>     Scope.Value.runWhere(USERNAME, "duke", () -> {
>         try (var scope = new Task.StructuredScope<String>()) {
>
>             scope.fork(() -> childTask1());
>             scope.fork(() -> childTask2());
>             scope.fork(() -> childTask3());
>
>             ...
>          }
>     });
>
> but I want to say something (not well thought out yet) like
>
>     List<String> results = Task.Builder(workers)
>         .scope.value<String>("USERNAME", "duke")
>         .scope.structured<String>( context-> {
>             List<Subtask<T>> subtasks
>                 = workers.stream().map(scope::fork).toList();
>             context.join()
>                 .throwIfFailed();  // Propagate exception if any subtask fails
>             // Here, all tasks have succeeded, so compose their results
>             return subtasks.stream().map(Subtask::get).toList();
>         })
>         .start();
>
> Where the "try" is implicitly there... where it's boilerplate I don't need to see. I am learning to appreciate the Builder Pattern a little more, and wondering if Loom could make better use of it.
>
> Anyway, just thinking out loud, and perhaps these discussions are better shared over beer? I know that the Scala community prefer Scotch, primarily Ardbeg, which is perhaps why Scala Architecture looks different than Java Architecture ;-)
>
> Again
>
> There are only two hard things in Computer Science: cache invalidation and naming things.
>
> -- Phil Karlton
>
>