Carrier threads of Structured Concurrency

[Daniel Schmid]

Hi,

JEP 437 (Structured Concurrency) mentions the following:

 > Every fork runs in its own newly created thread, which by default is 
a virtual thread. The forks' threads are owned by the scope, which in 
turn is owned by its creating thread, thus forming a hierarchy. Any fork 
can create its own nested StructuredTaskScope to fork its own subtasks, 
thus extending the hierarchy. That hierarchy is reflected in the code's 
block structure, which confines the lifetimes of the forks: All of the 
forks' threads are guaranteed to have terminated once the scope is 
closed, and no thread is left behind when the block exits.

So, the forked tasks are running using virtual threads. However, I 
didn't understand which platform threads are chosen as carriers in case 
the owning thread is a platform thread.
Would that use the default virtual thread pool for selecting carrier 
threads? If that were the case, would that block the platform thread 
owning the StructuredTaskScope?
Or would it use the owning platform thread as the carrier thread or 
include that in the selection of carrier threads?

For example, take the following piece of code from JEP 437:

Response handle() throws ExecutionException, InterruptedException {
     try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
         Future<String>  user  = scope.fork(() -> findUser());
         Future<Integer> order = scope.fork(() -> fetchOrder());

         scope.join();           // Join both forks
         scope.throwIfFailed();  // ... and propagate errors

         // Here, both forks have succeeded, so compose their results
         return new Response(user.resultNow(), order.resultNow());
     }
}

If we assume this method is called from a platform thread, which threads 
would be eligible as carrier threads for the tasks created for 
findUser() and fetchOrder()? The platform-thread calling handle, the 
platform threads from the virtual thread pool or both?

Greetings,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230412/a42bb858/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4490 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230412/a42bb858/smime.p7s>