Naming Things - Task and Subtask

[Eric Kolotyluk]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230518/a5556771/attachment.htm>